Agentic AI Architecture for Banking: Getting From Pilot to Production

Agentic AI architecture for banking requires five things that general-purpose agent frameworks leave out: a deterministic policy layer that validates every proposed action in code before it executes, per-action autonomy tiers assigned by how reversible the action is, decision-level audit capture recording inputs, retrieved context, tool calls, policy results and the model, prompt and policy versions in force, pinned model versions promoted through a release process, and an evaluation set built from historical cases including the ones a human got wrong. Orchestration stays in code wherever the sequence is known, and the model gets only the judgment-heavy steps inside it. Reasoning quality is rarely the constraint; those five are what turn a working demo into something that can be operated, audited and defended.

Agentic pilots in financial services rarely fail on capability. They fail at the point where someone asks what happens when the agent is wrong, and the honest answer is that nobody can reconstruct what it did.

Most of the published material on this topic stops at use cases. The use cases are not the hard part and haven't been for a while. What follows is about the architecture that determines whether a working pilot can be operated, audited and defended in a regulated environment.

Put the policy in the execution layer, not the prompt

The most common structural mistake is encoding the rules an agent must follow into its instructions. Don't exceed this limit, always check that, never touch these accounts. It works in testing. It works most of the time in production, which is the problem.

Instructions shape behavior probabilistically. Controls need to hold every time. Any constraint that matters belongs in the layer that executes the action, not the layer that decides to take it, so that a violation is impossible rather than unlikely.

In practice this means the agent proposes an action and a separate deterministic component validates it against policy before anything happens. Limits, entitlements, account restrictions, and cutoff windows are evaluated in code. The agent can be wrong and the transaction still doesn't go through.

The structural requirement is that the policy layer is the only path to the systems of record. If the agent holds credentials for the payment or ledger API directly, the policy layer is advisory however well it's written, and one tool misconfiguration routes around it. Give the agent credentials for the proposal endpoint only and let the policy service hold the ones that move money, which also leaves you a single choke point to rate-limit, kill-switch and replay.

Design the deny path as carefully as the allow path. Rejections should carry structured reason codes rather than free text, so the agent can revise a correctable proposal and so the reasons aggregate into something a control owner can review. Denials clustering on one rule usually mean the rule is wrong, the agent has been given work outside its remit, or the data is stale — three different problems that look identical in an undifferentiated error log. Cap the revision attempts, or a model that has misread the situation will keep proposing variants until it finds one the rule doesn't cover.

Actions also need idempotency keys, generated at proposal time and enforced at execution. Agents retry and orchestrators retry, and without a key that survives both, a timeout on a submitted payment becomes a duplicate payment.

This has a secondary benefit that matters for audit. When policy is in code, you can show a reviewer the rule, its version history, and the record of every time it fired. When policy is in a prompt, you're asking them to accept that a language model was told to be careful.

Tier autonomy by reversibility

Autonomy shouldn't be a single setting for the system. It should be per action, and the axis that matters is how hard the action is to undo.

A workable split for most financial services deployments:

"Read and analyze" is where most genuine value shows up early, and it's undersold internally because it doesn't sound like automation. It's also where read scope quietly becomes the risk: an agent that can query every customer record to answer a question about one of them has an entitlement problem, not a capability problem. Scope reads to the case in hand.

"Act with approval" degrades on its own if you don't watch it. Approval is a real control only while the reviewer has the time and context to reject. Set a target for how long a reviewer should plausibly spend on one decision, multiply by the daily volume in that queue, and if the result exceeds what the team has, the control is already decorative. Then watch the rejection rate. A queue running near zero rejections for a sustained period means either the action belongs in a lower-friction tier with monitoring instead, or the reviewers have stopped reading — distinguishable by sampling approvals and re-reviewing them independently.

The mistake to avoid is letting the tiering follow technical convenience rather than risk. Whether something is easy to automate has no relationship to whether it should be. Reversibility is also not a property of the action alone: an internal adjustment caught the same business day is cheap to undo, and the identical adjustment becomes expensive once it has been reported externally or a customer has been notified. Tier on the blast radius, including who sees the result before you can retract it.

Design for reconstruction from the start

After an incident you need to answer, precisely, what the system did and why. Not approximately. Not from logs that were built for debugging.

That means capturing, per decision:

• The inputs the agent saw — the request, the case data, and anything injected from session or user state
• The retrieved context — the documents or records returned, with their identifiers and versions, not just the query that fetched them
• The tools called and what they returned, in order, including calls that failed
• The action proposed, in the structured form the policy layer received it
• Which policy checks ran and their results, including checks that passed
• Who approved, if anyone did, and what they were shown at the time
• The versions in force — model, prompt, tool definitions, policy set, and the sampling parameters used

Two of these get skipped most often. The first is retrieved context: teams log the query and assume the corpus is stable, but the corpus is a live system of record, and the document that explains a decision may have been superseded twice since. If the source can't give you a version, store the retrieved text itself.

The second is version capture, and it's the one that hurts most. Six months later, investigating something that happened in March, the model has been upgraded twice and the prompt has been edited a dozen times. Without knowing which versions were live, you can't reproduce the behavior and you can't explain it. Content-hash the prompt and tool definitions at build time and write the hash into every decision record, rather than relying on anyone to bump a version string.

Hold these records separately from application logs, append-only, on a retention schedule set by the business rather than by observability cost. Evidence that shares a lifecycle with debug logs gets rotated away at the default retention window, which is roughly when you start needing it.

Build this before you need it. Retrofitting decision-level audit onto a running agent means changing the execution path of a system already in production.

Treat model changes as a release event

Providers deprecate versions and ship new ones on their own timeline. Behavior changes between releases, sometimes subtly, occasionally in ways that alter which actions your agent proposes.

So pin versions explicitly rather than pointing at a floating alias. Then treat a model change like any other production change: run it against your evaluation set, compare against the current baseline, review the differences, promote deliberately.

The comparison worth running is a diff, not a pass rate: which cases changed outcome, in which direction, and whether the newly-failing ones share a cause. A release can improve the aggregate score while breaking one category of edge case, and the aggregate hides it.

The pin has to cover the whole stack, not just the reasoning model. Embedding models are the ones teams forget: change the embedding model and every vector in the index is in a different space, so retrieval silently degrades until the index is rebuilt. That's a migration, not a config change.

Plan for forced upgrades. Deprecation dates are set by the provider, not by your release calendar, so keep a current-generation candidate continuously evaluated against the baseline and a deprecation becomes a promotion you have already tested.

That requires an evaluation set to exist. Which brings us to the thing most pilots don't have.

Build the evaluation set before the agent

An evaluation set is a collection of cases with known-correct outcomes that you run the system against on a schedule. Without one, you cannot tell whether a change improved the system or moved the errors somewhere you weren't looking.

For financial services the set needs to cover more than the happy path:

• Ambiguous cases where the correct outcome is to escalate rather than decide
• Incomplete-data cases where the right behavior is to ask rather than infer
• Adversarial cases designed to trip the policy layer, so you can confirm it holds
• Historical cases where a human decision was later found to be wrong — the most valuable and the hardest to assemble

Score by category and set the bar per category. Escalation cases should run close to perfect, because a missed escalation has the worst tail. The adversarial category is absolute: one policy bypass blocks the release, whatever the rest of the set did. Judgment-heavy categories can carry a lower bar if the errors are the conservative kind.

Because the system is stochastic, a single run of a case is not a result. Run the set several times per candidate and treat a case that flips between runs as its own finding: instability on a decision that matters usually points at under-specified instructions or a missing deterministic check.

Building this is unglamorous and is usually the longest pole in getting to production. Teams that leave it until after the pilot works spend the following quarter discovering they can't safely change anything.

Keep the orchestration deterministic

There's an architectural choice about how much of the control flow the model decides. At one end, the model chooses which tools to call and in what order. At the other, the sequence is defined in code and the model handles the judgment-heavy steps inside it.

For regulated workflows, keep the orchestration in code wherever the sequence is known. It's testable, it's explainable to a reviewer, and its failure modes are the ordinary ones your team already knows how to handle. Give the model the steps that require judgment.

The practical payoff is in failure handling. A coded workflow has explicit states, so a timeout mid-sequence leaves the case somewhere known with a defined recovery, and a retried step is a retried step rather than a fresh round of reasoning that may reach a different conclusion. Where you do hand control flow to the model, bound it: a ceiling on steps, tool calls and elapsed time, and on hitting it, escalate with everything captured rather than return a partial answer that looks complete.

Model-directed control flow is more flexible and appropriate for open-ended work. It's also considerably harder to constrain, evaluate and explain, which makes it a poor default for anything touching money or customer outcomes.

The realistic sequence

Pilots that reach production tend to follow roughly this order. Pick a workflow where being wrong is survivable and the current process is well understood. Build the evaluation set from historical cases. Implement the policy layer in code. Run the agent in shadow mode against live traffic, comparing its proposals to what people actually did, and keep going until the disagreements are explicable. Then move it to recommend-with-human-decision. Only then discuss autonomy, per action, on the evidence you've accumulated.

Shadow mode needs exit criteria written down before it starts, or it ends on someone's confidence. The useful criterion is not an agreement rate. It's that every disagreement has been classified — agent wrong, human wrong, or genuinely ambiguous — and that the agent-wrong category has no unexplained cases left in it. Run it long enough to cover the workflow's real variation, including period-end and the seasonal peak, because those are the conditions under which a process is least like its documentation.

It's slower than the pilot suggested it would be. The compression usually happens by skipping the evaluation set and the audit design, which is also the reason the second year is spent unable to change anything safely.

If you're weighing where your own pilot sits on this path, it's worth mapping your current architecture against these five requirements before the next model deprecation forces the question — and we're always glad to compare notes with teams working through it.