AI agents and credit decision engines: why they work together in a bank

The question keeps coming up in almost every meeting I have lately, and always in the same shape: if an AI agent reasons, uses tools, reads documents and follows instructions, why keep a decision engine at all?

It is a fair question. And it deserves something better than «because that is how it has always been done».

The difference is not intelligence versus rigidity. It is function and control. An agent copes well with what arrives messy; an engine makes sure the final decision answers to a policy that was published, approved and can be reconstructed. They are not competing for the same seat: they are two layers of the same architecture.

And the confusion is not an academic problem. It is the difference between being able to show your auditor why you declined an application in March, and not being able to.

What an agent is good at

An agent is a language model you hand an objective, a set of tools and the freedom to chain steps until it gets there. Where it shines is work with no fixed shape: reasoning about a case no prior rule anticipated, reading a financial statement or a contract and pulling out what matters, cross-checking sources nobody thought to cross-check, drafting the committee memo, pushing along a back-office process that today depends on someone remembering the next step.

The price of that flexibility is that the agent is probabilistic. Two runs on the same input can take different paths and land on different wording. That is not a flaw: it is precisely the property that makes it useful against the unforeseen. But it is also, exactly, the property you do not want in a credit approval.

This is where the argument tends to get overstated, so it is worth being careful. A well-governed agent can version its entire configuration: the model, the instructions, the tools, the sources, the memory, the permissions. And it does leave a trace of every run. What it cannot promise you is that two years from now it will walk the same path and reach the same result, especially if the model or a source changed along the way. Being able to version the configuration and being able to reproduce the decision are not the same thing, and for a supervised institution that distinction is everything.

And what an engine does

An engine is the system that makes the decision and records it: it takes the application, queries the sources the policy calls for, applies rules and models, and returns a result with a limit, conditions and a reason.

What defines it is not that it automates. It is that it automates in a way you can prove. The same information produces the same decision, and if it changes it is because somebody published a new version of the policy, with a name and a date. Rules and models are versioned, with role-based permissions, approvals, parallel testing and rollback. Every transaction leaves reconstructible what was queried, what was evaluated, which version was in force and what determined the outcome. It integrates with the core and the bureaus without replacing the system of record, runs in milliseconds at scale, and respects the separation of duties that the three lines of defence call for.

An engine is not built to think creatively. It is built to apply the risk policy in a controlled way, at volume, and to leave that proven.

Where they split, and why they need each other

If I had to sum it up: the agent returns reasoning, analysis and proposals; the engine returns a decision with its limit and its reason. The agent takes seconds or minutes per case; the engine resolves thousands per minute. The agent is changed by whoever administers its configuration; the engine is changed by risk, under change control.

The most important difference is the one that gets named least: what stands as the unit of governance. For the agent it is its whole configuration, a moving set of model, instructions, tools, sources, memory and guardrails. For the engine it is a published policy, with a version number and someone who approved it. The first is audited by looking at how the system is put together. The second is audited by looking at the decision.

And both carry risk, just of different kinds. The agent's is deciding alone in a regulated environment, with no reconstructible evidence. The engine's is propagating a wrong policy at scale, which can ruin thousands of applications in minutes. The engine's advantage is not that it carries little risk: it is that its risk gets simulated first, approved, versioned, monitored and reversed.

But listing differences falls short, because the interesting part is not that they differ: it is that each one solves exactly what the other lacks. The engine is precise and blind. It applies an impeccable policy, but only over data that already arrived clean and structured; faced with a PDF or an odd case, it sits there waiting for a person. The agent is the opposite: it moves well through mess, but it cannot promise you it will decide tomorrow the way it decided today.

Put side by side, those two limitations cancel out. The agent gives the engine what was never reaching it, and the engine gives the agent something it does not have on its own: a place where its work turns into a decision that holds up. Each one makes the other more useful than it was alone. Which is why the question is not which to choose.

Reasoning is not the problem

«If it reasons well, let it decide» sounds reasonable and it is not. There are three reasons, and none of them is philosophical.

The supervisor does not care how clever it is

What they care about is the evidence. And that requirement is old and fairly stable, even as the technological wrapper changes. In the United States, the interagency model risk management guidance of April 2026, which the Federal Reserve implemented through SR 26-2, insists on a proportional approach of inventory, documentation, validation, monitoring and model governance. It expressly replaces SR 11-7, the reference for more than a decade.

And the obligation to give specific reasons for a denial does not live in guidance but in the law: ECOA and Regulation B. Worth spelling out, because plenty of teams get it wrong: the CFPB withdrew its circulars on adverse action notices with complex algorithms in May 2025, but withdrawing guidance does not repeal the underlying legal obligation.

In Europe, the AI Act classifies creditworthiness assessment of individuals as a high-risk system. The Digital Omnibus pushed the implementation deadlines to December 2027, while the transparency obligations have applied since August 2026. More time to implement, not less to comply with.

The supervisory message is explicit too. Pedro Machado, of the ECB Supervisory Board, put it in February 2026: AI does not dilute responsibility, if anything it raises the bar. And he added what I think is the best summary of the whole matter: if a bank cannot explain why a model behaves the way it does, in terms that are useful for deciding, then it does not control that model. In the UK the FCA went the same way, applying the senior managers regime and the Consumer Duty to AI deployments rather than creating a separate regime.

None of that is satisfied by «the agent looked at it and thought it was fine».

Latin America is heading the same way

The regional framework points in the same direction. Argentina's central bank requires documenting objectives, responsibilities, models, data, metrics, thresholds and validation procedures when AI and machine learning are used, and in its own reports flags bias, explainability and privacy as the specific risks of AI applied to credit. In Peru, the SBS has its own model risk regulation covering governance, validation, monitoring and third-party models as well.

The practical reading is identical across all four frameworks: what gets audited is not how intelligent the system was, but whether you can reconstruct the decision and show which policy it was made under.

Without consistency you cannot measure anything

Two applicants with the same profile have to get the same treatment, unless an explicit policy says otherwise. If the decision depends on the path the model happened to take that time, you lose the ability to measure. And if you cannot measure, you cannot calibrate: you do not know whether delinquency rose because of the policy, the market, or a variation in the system itself.

That is the quiet point in all of this. An engine lets you attribute the outcome to a policy decision. An agent deciding on its own turns your portfolio into an experiment with no control group.

And then there is scale

An engine resolves thousands of decisions per minute at a stable, predictable cost per decision. An agent burns variable time and compute on every case. In high-volume origination that difference stops being technical fairly quickly and becomes economic.

Using an agent as a decision engine is like putting a brilliant senior analyst in charge of deciding every loan by hand. It works at low volume and on hard cases. It collapses once volume and the regulator show up.

How I would order it

The right move is not to choose. It is to order. And once you put them in the right order, what I said earlier shows more clearly: the work passes from one layer to the next without either invading the other.

Before deciding: interpret and prepare

This is the agent's shift. It reads the documentation that does not arrive through an API, extracts the data and leaves it available as variables for the rules within the same transaction. It normalises and validates what comes in inconsistent across sources. It assembles the file on the complex case so the human review starts with the work already done.

There is one control that tends to get skipped and that I think matters most of all: if the agent pulls a figure out of a financial statement and that figure goes into the decision, then the extraction is evidence too. It is not enough for the number to be right. You have to be able to show where it came from. Six minimum controls:

• Which document and which fragment produced each variable.
• What confidence level it was extracted with, stored alongside the value.
• Format and consistency validations before the value touches a rule.
• Mandatory human review when confidence falls below the threshold.
• Protection against instructions injected inside the document itself.
• And a hard rule: if the data is not in the document, it is not inferred.

The moment of deciding

Here, and only here, approve, decline or refer gets resolved, with a limit and conditions. Deterministic, versioned, with evidence per transaction and a published policy under change control. Machine learning outputs enter as governed variables inside that policy, which is what defines thresholds, exceptions and limits, always under an identifiable version.

Afterwards: explain, watch and propose

The agent comes back, with a different job. It writes in plain language what was queried, which rules applied and what determined the outcome, for the analyst, the committee and the audit. It monitors drift and behavioural deviations in the portfolio, and raises a flag. It reviews borderline declines and proposes policy changes. It simulates a new policy before it reaches production, and audits the execution order to suggest improvements.

With one explicit limit: the explanation is not free writing. The agent translates into plain language what is already recorded, the executed rules, the reason codes, the evidence, and nothing else. It cannot invent or reinterpret why the outcome was what it was.

The rule that orders everything is simple: the agent proposes and explains; the engine decides and leaves evidence. The agent never writes straight into production. It hands over a proposal that goes through the same approval circuit as any other policy change.

A case, so you can see it

A small business asks for a credit line increase. The agent reads the financial statement, extracts revenue, debt and cash flow, and flags that declared revenue does not reconcile with the attached invoices, recording which document each figure came from and with what confidence. The engine queries the bureau, computes the financial ratios, applies the policy in force and, because of that inconsistency, refers the case for review with an explicit reason. Then another agent drafts the committee memo, using only the recorded evidence and reasons.

None of the three pieces does the others' work, none of them could have resolved the case alone, and the decision ends up proven end to end.

And I want to say this plainly: this is not theory, and the three layers are ours. The agents I describe in this piece are part of the product, not an integration you have to go and solve on your own. In the first layer there is an agent that reads commercial documentation. Inside the editor, another one builds conditions from an instruction in plain language, so writing a rule does not depend on writing code. And in the last layer there is one that audits the policy and another that drafts the explanation for every transaction. In the middle, the engine stays deterministic.

Paper, which is where everything stalls

Of everything an agent can do around the decision, reading documents is what gives back the most time. It is the point where the process still stops to wait for a person, and it is also the best example of the two layers working together: without the agent the engine has nothing to decide on, and without the engine what the agent read turns into nothing.

Because not all information arrives through an API. When the data lives in a payslip, a financial statement, a bank statement, an invoice, a tax return or an identity document, the agent reads it and leaves its values available to the rules within the same decision, with no manual step in between. It works for individuals and for companies.

And it does not stop at extraction, which is where an OCR tool plants itself. Those values combine with each other, and with bureau data and your own sources; derived values get calculated; and the rules decide on them. An extractor hands you fields. Here the document enters as one more variable of the policy. That is the difference between reading a document and being able to decide with it.

With the six controls from a moment ago applied to every extraction, which is what lets a figure pulled from a PDF hold up in an audit the same way one pulled from a bureau does. More detail in credit document analysis.

Want to work out which parts of your origination can run on agents and which have to stay under a controlled policy? We look at your flow and show you a possible architecture, with evidence, versioning and approval points. Review my decision architecture

Five questions before moving anything

Before handing a step to an agent, I would run it through these five. If you answer yes to any of them, that step belongs to the engine.

1. Is the outcome a credit decision that affects the customer?
2. Do I need to reproduce this exact outcome two years from now?
3. Do I need to compare it against the previous policy's outcome?
4. Can somebody outside ask me for the specific reason?
5. Does this run thousands of times a day under a committed SLA?

And a sixth for the other side: does the step require interpreting something unstructured, or reasoning about a case the policy did not anticipate? Then yes, that is agent work.

What I would take from all this

Agents are among the most powerful tools to appear in years, and there is real work only they do well. But they do not replace the engine, the same way a team of brilliant analysts does not replace the banking core. It can look clever in the short term; in the medium term it leaves inconsistency, regulatory risk and operational debt.

Put to work together, on the other hand, each one covers the other's gap: the agent understands what arrives messy, the engine guarantees the decision is always the same and ends up proven. That sum is considerably better than either one alone, and it is what can be built today.

So the question is not «does the agent replace the engine?». It is how to design the architecture so each layer does what it knows how to do and the decision ends up proven. If that is where you are, it is also worth looking at build or buy.

We look at how you decide today, which steps are agent work and which have to live in the policy, and show you how it gets solved in the engine with your sources and your rules. Review my decision architecture