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 authorised, relevant and traceable sources that used to need manual analysis, 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. Given the same captured inputs, the same policy and model versions, and the same execution context, it always 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. If an institution cannot reconstruct what information was used, which policy was in force and what determined the outcome, it does not really control the decision.

Pedro Machado, of the ECB Supervisory Board, put it plainly: if a bank cannot explain why a model behaves the way it does, in terms that are useful for making decisions, then it does not control that model.

In Latin America the framework is moving the same way. Argentina's central bank requires documenting objectives, responsibilities, data, metrics, thresholds and validation procedures for the use of AI and machine learning. In Peru, the SBS has a specific model risk regulation covering governance, validation, monitoring and third-party models.

The practical requirement is always the same: being able to 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.

It is not which to choose, it is how to order them

If you made it this far, the conclusion is that the question was framed wrong. You do not choose between an agent and an engine. You put them in the right order, and that order has very concrete consequences for which controls you need and what stands as evidence.

That is what the second part covers: the three layers, the minimum controls a document-reading agent needs, a full end-to-end case and five questions for deciding what goes on each side. It is here: how to integrate AI agents with a decision engine.

And if you would rather see it against your own process, we look at your flow and show you a possible architecture, with evidence, versioning and approval points. Review my decision architecture