How to integrate AI agents with a credit decision engine

In the previous piece we looked at why an AI agent and a decision engine do not replace each other: each one solves exactly what the other lacks. Now for the how.

Because the hard part is not understanding the difference. It is deciding which step goes in which layer, which controls belong in between, and what stands as evidence when a figure came out of a PDF instead of arriving through an API.

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 autonomously publishes policy changes to 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.

All the document reading this piece talks about is done by uFlow, with agents. Financial statements, invoices, receipts, payslips, bank statements, tax returns and identity documents, for individuals and companies. It is not that the engine accepts data somebody else extracted: the extraction is ours, it happens inside the same transaction and it is logged with the decision. It is all in automated credit document analysis, with the detail of what it reads for each type of operation.

Inside the editor, another agent 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

It is the best example of the two layers together: without the agent the engine has nothing to decide on, and without the engine what the agent read turns into nothing.

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. It works for individuals and 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 and first-party data; 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.

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 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 has to sit inside a governed layer: usually the engine, or a controlled human flow.

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