The Deterministic-to-Probabilistic Spectrum

Section 6 of Agentic Banking Architecture: A Practitioner's Guide

The most common objection to this series has been: you can't run a bank on non-deterministic systems.

It's a reasonable concern. Banking depends on precision. A payment instruction that processes differently each time it runs isn't a feature — it's a defect. Regulatory reporting that produces different numbers depending on how the model is feeling today is a compliance failure. Interest calculations that vary by a fraction of a basis point are audit findings.

My short answer is: you're right. And you don't have to.

Not everything in an agentic architecture needs to reason at runtime. A payment instruction that processes identically every time — debit A, credit B, update ledger — doesn't benefit from an agent reasoning about it. It benefits from deterministic code that runs fast and predictably. But writing and maintaining that code is exactly where agents add value.

This suggests a spectrum of different process types.

Three Modes

Predictable — Agent generates code

At the deterministic end of the spectrum, agents write and maintain code. The code runs millions of times without agent involvement. When rules change, the agent regenerates the code. The agent is the author, not the operator — it's not present at runtime.

This is a crucial distinction. An agent that generates a payment processing function produces deterministic output. The function runs the same way every time, with the same inputs producing the same outputs. It can be tested, verified, audited, and performance-benchmarked exactly like any other piece of production code. The non-determinism exists only at authoring time — and that non-determinism is governed by the same review and testing processes that apply to human-authored code.

Banking examples: interest calculation, payment processing, regulatory reporting, fee computation, end-of-day batch processing, account statement generation. High volume, rule-based, zero tolerance for variation.

Balanced — Code for the standard path, agent for exceptions

In the middle of the spectrum, agents generate deterministic code for the standard processing path but handle exceptions and edge cases through runtime reasoning.

A payment that fits standard parameters runs as code — fast, deterministic, auditable. A payment that triggers unusual patterns — an unusually large amount, an unfamiliar beneficiary, a country that recently changed its sanctions status — gets routed to an agent for judgement. The agent assesses the context, applies policies, and either approves, escalates, or blocks.

The boundary between "standard path" and "exception" is itself a design decision that needs governance. Set it too narrow and too many transactions go to agents, adding latency and cost. Set it too wide and genuine risks slip through as standard processing.

Banking examples: trade execution (standard orders as code, complex or unusual orders to agents), account onboarding (standard applications as code, edge cases to agents), transaction monitoring (rule-based screening as code, contextual assessment of flagged items to agents).

Adaptive — Agent reasons at runtime

At the non-deterministic end, agents reason about every case at runtime. Each case is genuinely different. The agent assesses context, weighs factors, exercises judgement, and makes a decision — or recommends one for human approval.

These are the processes where non-determinism is a feature, not a bug. A credit assessment that considers the specific circumstances of each applicant — their income trajectory, their industry's outlook, the macroeconomic context — should produce different outcomes for different applicants. An agent that gave the same answer regardless of context would be worse than useless.

Banking examples: credit assessment, fraud investigation, customer advisory, complex complaint resolution, portfolio rebalancing, relationship management recommendations.

Why the Spectrum Matters

For migration sequencing

The spectrum provides a practical answer to "where do we start?" that complements the phased approach in Section 5. Start at the predictable end. Deploy agents that generate and maintain deterministic code for high-volume, rule-based processes. The governance requirements are lightest — the output is testable, deterministic code. The value is immediate — faster code generation, instant adaptation when rules change, fewer manual errors.

Move to balanced once the platform, governance framework, and organisational confidence are established. The governance requirements increase — you now need runtime monitoring for the exception-handling path, not just code review for the generated code.

Tackle adaptive last. This is where the full governance apparatus from Section 3 is needed: the observation bus, the assurance agents, the three lines of defence operating in real time. Don't attempt this without the foundation built through predictable and balanced deployments.

For governance design

Each mode requires different governance mechanisms.

Predictable needs code review, testing, and deployment governance — essentially the same controls applied to human-authored code, with additional validation that the agent-generated output meets specifications. The policy codification pipeline from Section 3 governs the prompts and policies that instruct the agent what code to generate. The generated code itself goes through standard CI/CD with automated testing.

Balanced needs everything predictable needs, plus runtime governance for the exception path. When transactions are routed to agents for judgement, the observation bus must capture the reasoning, the assurance agents must validate against policy baselines, and escalation paths must be defined for decisions the agent isn't confident about.

Adaptive needs the full governance framework. Every decision is a runtime reasoning event. The observation bus captures everything. Second line assurance validates continuously. Third line audits for gaps and drift. Hard circuit breakers prevent catastrophic outcomes regardless of agent reasoning. This is expensive — and it should be, because these are the processes where the consequences of poor judgement are highest.

The non-determinism debate

Instead of "can you run a bank on non-deterministic systems?" the question should be: "which processes benefit from runtime reasoning, and which benefit from agent-generated deterministic code?" We will need both, applied to different domains. The skill is knowing where the boundary sits for each process — and having the governance framework to manage both modes.

Drawing the Lines

Where a specific process sits on the spectrum is not always obvious, and it can shift over time. A process that starts as adaptive (requiring runtime judgement because the rules aren't well-defined) may move towards balanced as patterns emerge, and eventually towards predictable as the rules become fully codified.

Conversely, a process that has been predictable for decades may need to move towards adaptive as the environment changes. Sanctions screening was largely rule-based until geopolitical complexity made the rules insufficient — context-dependent judgement is increasingly required.

The lines should be drawn by the people who understand the process best — the domain experts — in collaboration with the architects who understand the governance implications of each mode. The spectrum is a tool for facilitating that conversation, not a formula that produces answers automatically.

This section expands on ideas first published in Part 6 of the LinkedIn series on agentic banking architecture. The concept of the spectrum emerged from recurring questions across the series about how to reconcile non-deterministic agent behaviour with banking's need for precision and auditability.