Fifteen years ago I helped build a system that ran a bank's structured products through their lifecycle. Every trade that entered it generated work items as its life unfolded, from barrier checks and payment events through to the cash flows due on the back of an exercise or an expiry. Work items we had automation for were actioned by code. The rest were routed to the department that owned them, whose users worked their queues inside our system. When an automated step failed, the failure itself became a work item for the support team. Once they resolved it, the product's flow carried on with the next item as if nothing had happened. For any product, you could pull the full trace of everything that had ever happened to it, from booking to expiry and whatever came after.
I have been thinking about that system a lot this year, because in hindsight it was almost agentic. It had the anatomy the current wave of AI agents is rediscovering. Work generated by events. A mix of automated and human interaction. Escalation on failure. Resumption after resolution. An audit trail behind every step. The automation covered what it could, and the intelligence to handle a deviation lived only in people. The code saw only the fields it was written to see and never learned from an outcome, so every deviation became a work item on someone’s queue.
Intelligence for the deviations is what AI agents actually offer banking operations. Most pitches lead with the model and the documents it can retrieve, and neither is where trust comes from. I wrote recently about agentic coding, and the law that emerged there was simple. An agent working autonomously is a loop, and a loop is only as trustworthy as the signal it verifies against. Verify against a real ground truth and the loop converges on what you wanted. Verify against the agent’s own output and you get an echo, confident and fluent and attached to nothing. In coding, the ground truth had to be built, a specification pinned down deliberately before the loop could close against it. Operational banking is different in a way that still surprises me. The loop already exists, and so does the ground truth. Decades of regulation forced banks to write their intent down as policies, thresholds, tolerances and approval rules. The industry that complains loudest about its compliance burden is the best-specified environment an agent could hope to land in.
One work item, two loops
Take one of those deviations that used to land on a human queue. A salesperson agrees a derivatives trade and books it. A little later they spot a mistyped detail and amend it. The amendment takes its time flowing through the chain of systems, and meanwhile the original booking has already travelled ahead. Downstream, the reconciliation platform that compares trades with their confirmations finds these two no longer line up. Quantities agree, but the settlement amounts differ. Operations call that a break. In the old system, no automation covered it, so it sat in a department queue until someone with the rules in their head picked it up. Two kinds of agent are on offer for a case like this. Both do no more than suggest, a closure or an escalation, with a person actioning either. They differ in one thing, what they verify against.
Run it through the first kind, the kind most deployments already look like. The agent reads the break, pulls some context, retrieves the bank’s reconciliation policy, and writes a fluent paragraph. The counterparty has a long history of clean settlement, the difference is small, similar breaks self-resolved last week, and the policy permits closure within tolerance, recommend closure, confidence 0.91. It queues the suggestion for an analyst and moves to the next break. When the number is low it suggests escalation instead, a gate it sets for itself. Everything in that paragraph is plausible and even carries citations, and an analyst pressed for time will click confirm. But what was the recommendation verified against? The model’s own reading. The tolerance was quoted, not checked. The rule was retrieved, not executed. The person in the loop is real, but everything they see was assembled by the thing they are checking, and the confidence number came from the same place. If an auditor later asks why this break was closed, the answer on file is a click on a narrative the model felt good about. In the coding context I called this an echo. In a bank, such an echo can break the bank’s own rules without anyone noticing.
Now run the same break through the second kind. Same context, same retrieval, one structural difference. Code owns the verdict. The tolerance policy is no longer just a document the model reads but configuration that runs. When the agent needs to know whether the difference is acceptable, it does not reason its way to an answer. It makes a tool call, passing the break’s identifier and nothing else. The tool is ordinary software, written and tested in advance and owned by the bank. The model never writes its own. It looks up the break record the reconciliation platform raised, takes the two amounts from there, loads the tolerance configured for this product and break type, and compares. What comes back is structured. It says within band or breach, names the rule that fired, the threshold it applied, and the policy version it ran under. The agent cannot override the verdict, and not as a matter of etiquette. The action of proposing a closure is itself gated on it, so a proposal that contradicts the check cannot even be submitted. The agent brings the case to the check, never the figures, and takes back a fact, never an opinion.
The model owns the context. The written rules name what matters for a break like this, and the agent goes looking. Is an amendment in flight upstream? Did the counterparty confirm on the previous version? Does this account have an open dispute? The answers can veto the proposal. Context that stays troubling sends the case to a person even inside the band. Here it does the opposite. The amendment has finished flowing, it explains the difference that remains, and the counterparty has confirmed the corrected terms. The agent drafts the same kind of narrative, but every claim in it now points at a source. This figure from the booking system. This tolerance from the policy. This precedent from case history. The check has already placed the break inside the band where policy permits agent-proposed closure, so the agent proposes exactly that, evidence attached, and the analyst confirms it in one click. The click, the evidence, and the rule that fired join the same kind of trace my old system kept, the full history of the case.
The person owns the decision. Had the difference breached the tolerance, the agent would not have proposed anything. It would have escalated, handing over the case and everything it had gathered, with no recommendation attached. Inside the tolerance band, the person confirms what the agent proposes. Past the line, the agent offers no recommendation, and the decision belongs to a person. In both paths a person stays in the loop. The agent closes nothing on its own yet. That autonomy has to be earned first.
Same model in both loops, and the same click at the end. The difference is entirely in what they closed against. The first checked its answer against its own reading of the rules. The second checked it against the bank’s own written intent. Both leave a trail on file. The first files a well-written story. The second files the rule that fired, the version it ran under and the verdict it returned, the kind of trail an auditor will actually accept.
Closes against its own reading
Closes against written policy
Compare that with the system I opened with. The machinery is the same. Work items are still generated and routed, failures still escalate, flows still resume, and every step still lands in the trace. What changed is the boundary of the automated set. In our system, that boundary was wherever we had written code, and everything beyond it was human by default. An agent that verifies against written policy moves the boundary into the cases that need judgment about context, while keeping the property that made the old system trustworthy. Every action traces to a rule, and every deviation reaches a person.
The pattern is not specific to post-trade, the work that follows once a trade is agreed, either. Consider the lending side of a bank. An approved credit facility carries terms that live on after the approval. Documents must arrive by a due date, the borrower must keep meeting obligations while the facility runs, and collateral coverage must hold through market moves. Somebody has to watch those terms for the life of the facility and raise the work they demand when reality drifts from them. That is the machine I described at the start, built for loans instead of structured trades.
The verification signal itself sometimes needs designing with adversaries in mind. On the market risk platform where I later spent a decade, we checked intraday risk limits across trading desks at randomised times during the day. When a limit was breached, the trader got a note and middle office, the control function that polices the desks, got a report. The randomisation was the point. A check that runs on a schedule is a check a trader can plan around. Carry big risk through the day, book a few offsetting trades just before the close, and the picture the check sees comes out clean. A verification signal is only worth something if it cannot be gamed. Banks learned that about humans long before anyone applied it to agents.
This is also why the last attempt to push the automation boundary disappointed. Robotic process automation is a fixed sequence of steps, finished when the steps run out. It automated the mechanical middle of processes and had no answer for deviation except failure. In operations, deviation is daily reality. Straight-through processing, the older push to have trades flow end to end with no human touch, taught the same lesson earlier. The exception handling we built in that first system caught what the pipeline dropped, and it was never short of work. The work was always loop-shaped, and the systems I built ran that loop with humans as the reasoning component inside it. Agents are the first tooling that can take on part of the reasoning itself. The only open question is what they verify against, and for banks that question was answered years ago, by an unlikely author.
Regulators wrote the design principles first
Banking’s controls go back centuries, to double-entry bookkeeping and the maker-checker rule, where the person who prepares a transaction is never the person who approves it. But the regime that matters here is recent, and written intent was never even its goal. The Basel accords, the international banking rules that began in 1988, are at heart about a cushion. A bank must hold enough of its own capital that when loans go bad or markets fall, it absorbs the loss instead of collapsing. Nothing in that demands writing intent down. The documentation arrived through a side door. Later versions of the rules let banks calculate the size of their own cushion using their own risk models. A regulator who permits that will demand to see how the model works, what data feeds it, who may change it, who checked it, etc.
Then came 2008. Banks that looked comfortable on paper nearly went under. When a major counterparty collapsed, some needed days to answer the most basic question of all. How much do we stand to lose here? The answer lived scattered across systems that had never been made to agree. The rulebook written after the crisis went after exactly those gaps. Much of my career has been spent inside the systems it produced, and read with today’s eyes, it is a curious document.
The Federal Reserve’s SR 11-7 guidance on model risk, the risk of a financial model itself being wrong or misused, from 2011, sets the expectation that models are validated independently of the people who built them. The validators, in its own words, “do not have a stake in whether a model is determined to be valid”. That is maker-checker applied to software, or, in the language of agent design, nobody marks their own homework. Its definition of a model, incidentally, comfortably covers the agent itself. BCBS 239, from 2013, answers the aggregation failure directly. It requires the world’s systemically important banks to demonstrate the lineage of their risk data, the traceability of a number from its origin to its final use. Agent builders call the same idea provenance, and treat it as an advanced feature. Escalation matrices and approval authorities define, in writing, which decisions may be delegated and which must reach a person.
None of this was written with AI in mind. Read it today and it is difficult to see it as anything other than a design document for trustworthy agent loops. The verifier must be independent of the doer, every number must trace to its source, and the decisions that remain human are named in writing. Regulators specified the architecture fifteen years ago, and banks have been running it with people inside it ever since. Agents are the first new kind of worker that can take those seats. A bank adopting agents already has a governance philosophy. The work is noticing that, and wiring the loop into it.
One engineering consequence hides in that sentence. If the ground truth is the bank’s written policy, the policy must be legible to the system. Thresholds, taxonomies and templates belong in configuration the bank’s own experts can change, not in prose the model merely reads, whether buried in a prompt or fetched by retrieval, and not in rules hard-coded by a vendor. This is where a fair objection lands. Much of that policy lives today as prose in documents, and making it legible is real work, the same in kind as writing any specification. In coding, the ground truth had to be discovered. In a bank, the intent has already been argued over, approved and versioned. What remains is transcription, not discovery. The institution is not deciding what it means. It is moving what it means into a form a loop can check against.
None of this is new to banks. Keeping the rules in the hands of the business is why rules engines took root years before anyone said “agent”. Systems got built in a way so that the business could change production behaviour themselves, in some cases even offering an impact preview before those changes were applied to the live system. The policy an agent verifies against needs the same treatment. It must be declarative enough that a machine can check two rules for contradiction, versioned like code, and testable against history before going live. What form that policy should actually take, what the tools that check it look like, how its changes are governed, and how the agent invokes it all case by case, are questions that warrant a post of their own. The deterministic layer owns the thresholds and the taxonomy, and the model owns what models are good at, reading messy context, drafting the narrative, noticing that this case rhymes with an earlier one. Tangle those concerns and every policy change becomes a vendor change request. Banks have been burnt by that kind of lock-in before, and they have long memories.
How you would know it is working
A fair challenge to the coding piece applies here with double force. Trust is earned by evidence, not by a convincing design. Any given deployment is a hypothesis until measured. The useful news is that operational loops are unusually measurable.
Three signals do most of the work, the agreement rate, the override reasons, and the escalation curve. Agreement rate means how often the human confirms what the agent proposed, tracked per event type so drift in any category shows early. It can also be inflated by its own convenience. An analyst under volume pressure will click confirm all day. The metric needs its own audit. A sample of confirmed cases goes to a second analyst, who reworks each one from the evidence without seeing the first decision, the way banks have always audited human queues.
Override reasons matter because when analysts reject a proposal, the reasons are structured data. Clusters of them point at either a weak agent or, just as often, a policy that no longer says what the institution means.
The escalation curve is the third signal, and the one that earns its keep twice. Every human-resolved escalation should be captured as a regression case, one the loop consults before it next proposes an action on that pattern. The resolved-case library becomes institutional memory that can be audited and pruned, instead of tacit knowledge living in whichever analyst handled the original case. That is key-person risk by another name. And the escalation rate itself becomes the trust metric. A falling curve is the system visibly absorbing the institution’s judgment.
The same evidence is what earns wider autonomy. Nothing in the design requires the confirm click forever. When the agreement rate has held, category by category, at levels the institution accepts, policy can lift the click for the narrowest, best-evidenced case types first. Even then the sampling does not stop. A fully automated flow still sends a slice of its closures for blind re-review, and known cases can be replayed against the loop at randomised times, the same instinct as the intraday limit checks, to prove the machinery is still intact. Automation changes who clicks. It does not retire the audit.
All three signals assume the loop itself is healthy. If the agent quietly stalls, or a feed goes stale and the loop keeps narrating around the gap, the green dashboard is worse than no dashboard. I spent years building and running the observability stack for a risk system spanning six data centres. The failures that hurt were never the loud ones. What hurt most was quiet degradation, often of a kind we had insufficient metrics for until it had already happened in production and we went digging. No amount of experience lets you enumerate every single one of those failure modes in advance. Some of them you only meet by letting the system run. So the metrics kept evolving. Each incident showed us where to measure deeper as we learned how the system was actually being used.
Continuous operation needs boringly durable machinery underneath. Runs fire on schedule, state survives a crash, a failed step resumes instead of starting over, and the loop reports “I could not verify” as loudly as it reports a breach. It also watches its own health, because slower is a failure mode too. My old lifecycle system got this right with no intelligence at all. A failed step became a work item, a human resolved it, and the flow resumed. An agentic system that cannot clear that bar has no business adding intelligence on top.
The questions worth asking
If your institution is evaluating agentic systems this year, the model demos will all look impressive, because the models are genuinely impressive. The separation happens on questions the demo does not answer. What does the agent verify against, and can you trace a specific decision back to a specific rule and data point? When a proposal says the tolerance was checked, did code execute that check or did the model write that sentence? Is the component that judges “done” independent of the one that did the work? What can our own experts change without a code release? What happens when the system degrades quietly, and how would we know? And what will you measure from day one, so that six months in, trust is a curve on a chart rather than a feeling?
Banks are in a stronger position to ask these questions than they tend to believe, because the hard asset is already theirs. The AI models will keep improving on their own schedule, and they are the interchangeable part. The written intent is the part nobody else has, the policies, thresholds, tolerances and approval rules that took decades of regulatory pressure to accumulate. Treat that archive as the ground truth your agents close against. Much of it is prose today, and moving it into a form a loop can check is real work, but it is transcription, not discovery. The intent has been sitting in the policy repository all along, waiting for something that could run it.
