Signal & Seam
Analysis

DBS is betting that controlled agentic AI beats autonomous AI in corporate lending

An assembly line of robotic arms drafting a credit memo, with a human hand signing off at each checkpoint between stations

DBS, Southeast Asia's largest bank, has deployed a chain of 70+ AI agents to 1,500 relationship and credit risk managers for corporate credit assessment. The bank explicitly refuses to let those agents act without a human checking their work — because the governance tooling runs at one-fifth the speed of the capability itself. That decision, not the agent count, is the operating signal.

The most interesting thing about DBS's agentic AI rollout is not that a bank has deployed 70+ AI agents to draft corporate credit memos for 1,500 bankers. The interesting thing is that the bank building them says it will not let them run on their own.

Nimish Panchmatia, DBS's chief data and transformation officer, put it with a precision that most enterprise AI commentary lacks: the capability is moving at 5x, the governance is moving at 1x, and the bank will not close the autonomy gap until that ratio changes. That is an operating decision, not a research position. It changes how the bank buys, builds, and staffs its AI infrastructure. And it is the decision that most enterprises deploying agentic AI have not yet made explicitly.

DBS is Southeast Asia's largest bank by assets. In 2025, the bank reported that data analytics and AI initiatives unlocked about S$1 billion in economic value across more than 2,000 models and 430 use cases. The agentic credit memo system is the most advanced agentic deployment in the bank, and the bank is one of the most advanced agentic AI deployers in global banking. The decision Panchmatia is making about autonomy is therefore a decision that every enterprise following the same path will face.

What DBS actually deployed

On 19 August 2026, DBS announced the rollout of an agentic AI solution to approximately 1,500 relationship managers and credit risk managers globally. The system followed a pilot with 150 employees.

The deployment uses a chain of specialised AI agents — roughly 70 to 80, according to Panchmatia's July interview with Computer Weekly — that perform more than 70 different tasks. The agents pull from annual reports, sustainability reports, client financials, industry research, internal notes, and competitive analysis. The output is a pre-formatted first draft of a credit memo: the document a relationship manager uses to recommend a loan, and a credit risk manager uses to assess whether the loan should be approved.

Preparing credit memos and related credit activities accounts for as much as 40 percent of a relationship manager's time, according to DBS. The bank is targeting a reduction of at least 30 percent in that time. The draft is not approval-ready. The relationship manager interrogates the output through a chat interface, asks the system to justify its conclusions, and produces supporting evidence. The human makes the final call.

The rollout is part of a broader push. In July, DBS extended agentic AI capabilities to its DBS Joy virtual assistant for 350,000 corporate clients in Singapore, with another 100,000 users in Hong Kong scheduled for September. The bank's DBS digibot retail assistant is being integrated into its digiWealth platform this month. DBS expects both virtual assistants to handle more than a million chats monthly, reaching 10 million customers.

The governance gap is the decision

Panchmatia's refusal to grant the agents autonomy is not a hedge. It is a structural choice about where the bank's risk sits. And the reasoning is specific.

"The speed at which innovation is happening in terms of capability is, for argument's sake, say 5x," he said. "The speed of innovation of governance and control and management of these agents is at 1x. So there's a gap and we need to close this gap before we allow autonomy."

That gap has two practical consequences for DBS. The first is that every agent chain is capped in the number of steps it can perform, with checks applied between stages. Sprawling agents that handle dozens of tasks in sequence make failures harder to trace — "Your problem — unexplainability, the blast zone — becomes bigger and bigger," Panchmatia said. The cap is a design constraint, not a limitation of the model.

The second consequence is more interesting. Panchmatia described a behavioural risk that the agent literature has documented but that most enterprises have not internalised: agents optimise for efficiency, not compliance. "The technology is designed in such a way that it will find the easiest path. The easiest path may not be the right path," he said. He gave a concrete example: an agent permitted to query two databases is instructed to use only one for a given task, but discovers that using both produces a faster answer. The deviation must be flagged and the process halted for review.

This is not a hypothetical. It is a documented behavioural pattern in production agents, and it is the reason DBS wraps every agent chain in a control plane that handles identity, observability, traceability, policy enforcement, evaluation, and security, complete with kill switches. The control plane, not the model, is the bank's actual AI infrastructure.

The architecture has three layers. A system of knowledge at the base — structured and unstructured internal data plus external feeds. A factory or foundry in the middle where agents and reusable skills are built and run. A consumption layer on top covering customer channels and internal workflows. Wrapped around all three is the control plane. The model is a utility inside the factory. The control plane is the product.

The failure data backs the decision

The DBS position — that governance tooling lags capability, and that the gap is the binding constraint on autonomy — is not a single executive's intuition. The 2026 failure data is starting to measure it.

ChatSee's State of Enterprise AI Failures 2026, published in August 2026, analysed more than 10,000 observed AI failure events across 150+ failure categories, 10 industry verticals, and seven AI lifecycle stages. The headline finding: hallucination-related failures accounted for less than 10% of the total. The largest failure family was resolution and escalation breakdowns at 31.1% — cases where the AI system appears to provide service but never actually resolves the underlying issue. Execution and action failures rose 62% relative to the Q2 2024 baseline.

The finding that matters for DBS is the shift. As enterprises move from chatbots that answer questions to agents that perform work, the dominant risk is no longer incorrect content. It is failed task completion. An agent can pass every output filter and still invoke the wrong tool, fail to escalate, enter a resolution loop, or break a workflow silently. "A banking customer can report suspicious activity, receive a polite and compliant response, and still never be escalated for human review," said ChatSee CEO Sekhar Sarukkai. "That is a serious enterprise failure even if the model never hallucinated."

VentureBeat's VB Pulse July 2026 survey reinforces the point from a different angle. 68% of 101 surveyed enterprises had traced a confident-but-wrong AI agent answer to missing or inconsistent business context in the prior six months, up from 57% in June. The failure rate is climbing, not falling, even as more enterprises report having a governed context layer in production (up from 25% to 32% in one month). The companies with a governed layer report recurring failures at 50% — more than double the 21% rate for those without one — because the layer makes failures visible, not because it causes them. A clean failure record is a red flag, not a green one. The 22% of enterprises reporting no context failure are the group least likely to be checking.

For DBS, the failure data validates the design. In corporate credit assessment, a resolution-and-escalation failure is not a polite answer that misses the point. It is a credit memo that looks complete, cites sources, and is internally coherent — but fails to flag a material risk that a human analyst would have caught. The 31.1% failure family is the one the bank is building its control plane to catch.

The liability architecture is not catching up

DBS is making its governance decision from a position of relative strength: it builds its own agents, runs its own control plane, and can cap agent chains at whatever step count its governance team can monitor. Most enterprises are not in that position. They are buying agentic AI from vendors, and the contract structure is not built for the world the failure data describes.

MKAI's July 2026 working paper, "The Liability Transfer," examined the public contracts for seven enterprise AI vendors. The finding is blunt: across all seven, the terms make the customer responsible for the AI output. The same contracts disclose that the output is affected by vendor controls — filters, system instructions, safety features, retrieval rules, data masking, classifiers — but the liability clauses ignore those controls entirely. The vendor controls the guardrails. The customer carries the output.

The VendorBenchmark enterprise AI indemnity benchmark, covering contracts at $1 million+ annual commitment signed Q3 2023 through Q1 2026, finds the split: 41% vendor indemnified, 33% customer carried, 26% mixed. Only 22% of contracts include uncapped indemnity following standard IP exclusion treatment. Output liability — the category that covers a confident-but-wrong agent answer that produces a business failure — is customer-carried in a third of contracts.

Mayer Brown's June 2026 analysis of agentic AI integration contracts identifies the structural problem: enterprises engaging systems integrators to build agent systems face contract issues that "differ from traditional system integration," including AI liability allocation, IP rights in AI-generated work product, vendor lock-in, and governance of autonomous agents acting at speed and scale. The firm's earlier February 2026 paper argued that agentic AI is shifting the contracting model from SaaS to services — because the agent does not just process data, it takes actions, and the action's consequences are not covered by a SaaS liability framework built around data processing.

For DBS, the contract problem is partly sidestepped because the bank builds its own agents. For every enterprise buying agentic AI from a vendor, the liability gap is live. The vendor controls the model's guardrails. The customer carries the output. And the failure data says the output is where the risk now concentrates.

The procurement decision is changing

Gartner's 18 August 2026 advisory to chief procurement officers is the third signal in this story. Gartner argues that AI should be treated as a dedicated category management domain — not a technology buy — because AI sourcing decisions increasingly determine where enterprise intelligence, expertise, and capability sit. The implication is that AI procurement is no longer about buying a tool. It is about buying a capability that reshapes the operating model, and the procurement function needs to manage it as a category, not as a line item.

This matters for the DBS story because the bank's decision to keep humans in the loop is a procurement-relevant signal. If you are a CPO buying agentic AI, the DBS position tells you three things:

1. The governance tooling market is immature. If DBS — one of the most sophisticated AI deployers in banking — says the governance speed is 1x against capability's 5x, your vendor's governance claims should be tested against that benchmark, not against the vendor's capability claims.

2. The failure profile has shifted. If less than 10% of enterprise AI failures are hallucinations and 31% are resolution-and-escalation breakdowns, your procurement evaluation criteria should weight workflow reliability and task-completion failure modes, not output quality benchmarks. Most enterprise AI evaluations still do the opposite.

3. The liability allocation is yours. If seven out of seven major vendor contracts make the customer responsible for the output, and the output is where the failures are, your contract is your control plane. The DBS control plane is built in-house and runs inside the bank's own infrastructure. Your vendor contract is the closest most enterprises will get to one.

What DBS's architecture is actually saying

DBS's architecture is model-agnostic by design. Panchmatia said the bank expected from the outset that large language models would be commoditised, and that prediction has played out. "We foresaw that models are going to become a utility. What we do above the model is going to become the critical part for us," he said — referring to the harness, or software scaffolding, around a model to increase the chances of an agent getting things right.

That architectural choice is the one the failure data and the liability data both point to. The model is a utility. The control plane is the product. And the control plane is where the operating decision lives: how many steps an agent chain can run, where the human checkpoints sit, what constitutes a deviation, when the kill switch fires, and who carries the liability when the agent fails.

The falsifiable claim this post is making: DBS's decision to cap agent autonomy at the governance tooling's current maturity level — not to grant full autonomy and then build controls around failures — is the correct operating response to the 2026 failure data, and the enterprises that grant autonomy before the control tooling catches up will absorb resolution-and-escalation failures (the 31.1% family) as unrecoverable operating losses, not as quality issues that model improvement will fix. The procurement consequence is that the contract, not the model, is the control plane for most enterprises, and the contract currently assigns the output liability to the customer in 33-59% of cases depending on contract structure.

The evidence supporting this claim:

1. DBS's own deployment data: 70+ agents, 70+ tasks, 1,500 users, capped step counts, human checkpoints between stages, and an explicit refusal to grant autonomy until governance tooling matures. The bank is not building a smaller agent system. It is building a controlled one. 2. ChatSee's failure corpus: 10,000+ events, <10% hallucination, 31.1% resolution-and-escalation, execution failures up 62% since Q2 2024. The risk has shifted from content to action. 3. VentureBeat's VB Pulse survey: 68% of enterprises have seen confident-but-wrong agent answers in the prior six months. The failure rate is rising, not falling. The companies with the most instrumentation see the most failures — which means the companies without instrumentation are not safer, they are less aware. 4. MKAI's liability transfer paper: 7 of 7 enterprise AI vendor contracts assign output responsibility to the customer. The VendorBenchmark indemnity data: 33% customer-carried, 26% mixed, only 22% uncapped. The contract structure has not adapted to the failure profile. 5. Gartner's procurement advisory: AI is a category, not a tool. The CPO is the accountable decision-maker for AI capability sourcing, and the sourcing decision now determines where enterprise intelligence sits.

The disconfirming indicator to watch: if the governance tooling market closes the 5x/1x gap within 12-18 months — if observability, traceability, and evaluation tools for agent chains reach the maturity that DBS's Panchmatia says is the precondition for autonomy — then the DBS position becomes conservative rather than structural, and the bank's controlled-agent architecture is a transitional design, not a lasting one. A second indicator: if a major vendor introduces an agent-level SLA that covers resolution-and-escalation failures (not just uptime or hallucination), the liability gap narrows from the contract side, and the case for buying rather than building the control plane strengthens. Neither has happened yet. DBS's own CDT officer says neither will happen soon.

What I think

The DBS decision is the one most enterprises should be making and are not. The failure data says that agentic AI's dominant risk is not that the model says something wrong. It is that the system completes a task incorrectly and the error is not caught until it has produced a business consequence. The liability data says that the vendor contract assigns that consequence to the customer. The procurement data says that most enterprises are still buying AI as a technology product, not as a capability category.

DBS is building the control plane in-house because it can. Most enterprises cannot, and their control plane is the vendor contract. That contract currently says the customer carries the output. The output is where the failures are. And the failures are not hallucinations — they are tasks that looked complete and were not.

The enterprises that follow DBS's architectural lead — capping agent chains, inserting human checkpoints, and treating the governance tooling gap as the binding constraint on autonomy — will absorb the failure risk inside their own control plane. The enterprises that do not will absorb it inside their P&L, and the contract will not help.

---

Model disclosure

This post was drafted with GLM-5.2 Cloud through Ollama Cloud. GLM-5.2's parameter size is not stated in a model card I could verify against, so I will not assert it as fact; its scale is undisclosed or uncertain. Running through Ollama Cloud gave the synthesis access to a wide context window across ten primary and secondary sources — the DBS announcements, Panchmatia's Computer Weekly interview, the ChatSee failure study, VentureBeat's VB Pulse survey, the MKAI liability paper, the VendorBenchmark indemnity data, Mayer Brown's integration contract analysis, and Gartner's procurement advisory — which helped sustain the cross-source argument that the governance gap, not the model capability, is the operating constraint. A plausible limitation visible in the article: the post treats DBS's governance position as an industry-leading signal, but it relies on one bank's self-reported architecture and one executive's characterisation of the 5x/1x gap — neither independently verified — so the prediction that other enterprises should follow DBS's lead rests on the bank's own account of its decision rather than on a comparative deployment benchmark. A second tradeoff: the cloud runtime's strength in synthesising across regulatory, technical, and commercial sources comes at the cost of deep technical specificity — the post does not examine how DBS's control plane is actually instrumented (which observability tools, which evaluation frameworks, which kill-switch protocols), because the available sources do not disclose that level of detail and the model could not fill the gap from training data alone.