DBS gave 1,500 employees AI agents. The interesting part is what had to exist first

Singapore’s DBS is rolling out specialist AI agents to 1,500 employees, per Finextra’s report from August 21. Not a chatbot in the corner of the intranet. Agents. Software that takes an objective, works through steps, touches systems, and hands back a result.

The headline number is 1,500 people. That’s not the story. The story is that a bank did this. A bank regulated by the Monetary Authority of Singapore, one of the strictest financial supervisors on the planet, decided it was comfortable letting autonomous software act on behalf of its staff at scale.

Banks do not get comfortable by accident. Somewhere behind that announcement is a mountain of unglamorous work: permission scoping, data boundaries, audit trails, escalation paths, and a clear answer to the question “who is accountable when the agent gets it wrong?” DBS has been building its internal AI machinery for the better part of a decade. The agents are the visible tip. The governance is the iceberg.

Specialist beats general, and that’s a governance choice

Notice the word Finextra used: specialist. Not one giant do-everything assistant. Narrow agents with defined jobs.

That’s not a product limitation. It’s a control decision, and it’s the right one. A specialist agent has a scope you can write down. You can enumerate the systems it touches, the data it reads, the actions it’s allowed to take, and the point at which it must stop and ask a human. You can log every step against that scope and review the logs. Try doing any of that with a general agent that has broad access “to be helpful.” You can’t, and neither can your compliance team, and neither can your regulator.

The specialist model is how you make agents auditable. DBS understood that. Most firms rushing into agent pilots right now do not.

How the pilot usually goes at everyone else

Here’s the pattern we keep seeing in mid-market firms, especially regulated ones. Somebody in operations wires up an agent using a SaaS platform’s shiny new agent builder. It works. It’s genuinely useful. Word spreads. Three months later there are eleven agents nobody centrally tracks, four of them have credentials to systems holding client data, and one of them has been quietly emailing summaries of internal documents through a third-party API in another jurisdiction.

Then someone asks the questions that should have come first. What data can these agents see? Where do their logs live? Who approved their permissions? Can we prove to an examiner what any of them did on a given Tuesday in March?

Bolting oversight onto that mess after the fact is miserable work. You’re reverse-engineering scope from behavior, revoking access people now depend on, and rebuilding trust with a compliance team that just found out about the whole thing. Baked in beats bolted on every single time, and the cost difference is not close.

What baked-in actually looks like

This is the design philosophy behind AgentWorks, Modular’s agent framework for regulated firms, and honestly it’s less about clever AI and more about boring, deliberate plumbing.

Every agent gets a written charter before it runs: job, systems, data classes, action limits. If it’s not in the charter, the agent can’t do it. Permissions are scoped and enforced at the infrastructure layer, not politely requested in a prompt, so an agent that shouldn’t see client PII physically cannot query it. Every action lands in an immutable log tied to the agent, the task, and the human who owns that agent. When an examiner asks what happened, you pull the record instead of pulling an all-nighter.

High-consequence actions route through human approval gates. The agent drafts, a person authorizes. Low-stakes steps run autonomously, and anything with real consequences waits for a human signature. And the whole thing runs on infrastructure the client controls, on US soil, at a fixed price. No metered surprise when an agent gets busy, and no wondering which country your audit trail lives in.

And because Modular is model-agnostic, the agent that fits the job gets the model that fits the job. Swap it later if something better ships. The governance layer doesn’t care which model is underneath, which is exactly how it should be.

Your data, your rules. And that includes the AI working on it: your AI, your rules. An agent is just software acting with your authority, so the rules that govern your data have to govern the agent too. Same jurisdiction, same access controls, same audit standard. If your agent platform can’t inherit those rules, you don’t have a governance problem waiting to happen. You already have one. You just haven’t logged it yet, because nothing is logging it.

DBS earned this. You can too, faster

DBS spent years and a small army of engineers building the machinery that makes 1,500 agents defensible. A 200-person wealth manager or a regional insurer doesn’t have that army and doesn’t need it. The pattern is now known. Specialist agents, written charters, enforced scopes, human gates, logs you’d be happy to show a regulator. That’s a buildable package, and it’s a lot cheaper to build it before your first agent ships than after your eleventh.

The firms that get this right in the next eighteen months won’t be the ones with the most agents. They’ll be the ones who can answer, in one meeting, exactly what every agent they run is allowed to do and prove it did only that.

Here’s my honest question for anyone at a regulated firm reading this: if your regulator asked tomorrow for a list of every AI agent operating in your environment and what each one can touch, how long would that list take to produce? An hour, or a very uncomfortable silence? Tell me where you’d land. I suspect the answers are worse than most leadership teams think, and I’d genuinely like to be wrong.