Part of a series on building cz-agents → under the hood
What 2026 asks of AML agents
Read what regulators and industry sources are writing about AI in compliance this year and one word shows up more than the rest: explainability. Explainable AI, XAI for short. In the world of anti-money-laundering and knowing your customer, it translates into a very concrete demand: it is not enough for a model to return a risk score. You have to be able to show why that score came out the way it did — what chain of reasoning led to it, which sources it drew on, and where in that chain a human decided rather than a machine.
Several requirements that look separate at first all point at the same spot. Behind every decision the agent makes, there should be a recorded trail — with the confidence the model assigned and the data it leaned on. Before deployment there should be documentation: which cases the agent may be used for and which it may not (scope), how risk is classified, who is named as accountable, what test records the tool has passed, what its confidence thresholds are, what fallback rules apply when it is unsure, and what triggers a human review. And the final say belongs to a person — an analyst who has to be able to demonstrate why something was flagged. The industry has even started using the term "Know Your Agent" for this new outline: from now on you may need to vet not only the customer, but the software agent deciding on your behalf.
Read this as someone who runs such a tool and the natural first reaction is a sigh. It looks like a pile of new paperwork you will have to bolt, painfully, onto a finished product. I want to show that for a certain kind of architecture it is not — and why.
Why a black box is a problem in compliance
Picture a model that takes a company or a person as input and returns a number: risk 82 out of 100. Inside is an opaque network with no explanation leading out of it. Such a tool may well decide correctly. But it can say nothing about its decision that would survive scrutiny.
And that is exactly what the rules reject. Compliance is not an accuracy contest; it is a craft in which you must be able to defend your decision — before internal audit, before a supervisor, possibly before a court. "That's how it came out" is not a defence. When an analyst marks a payment or a client as risky and all they hold is a score from a black box, they have nothing to show that they acted on specific facts rather than on an invisible correlation they themselves do not understand. A high score without a defensible "why" is, in this field, more of a liability than an asset.
Here is the core of the problem the regulation names: an opaque model can give an answer, but it cannot give evidence. And in compliance, evidence is the whole point.
The architectural turn: an agent that doesn't decide, it calls tools
There is a way to build an agent so the problem dissolves on its own. It is not about adding an explanation module to the black box. It is about not building a black box at all.
The difference is in where the deciding happens. In the opaque approach the model swallows everything and resolves everything inside itself. In the approach called tool-based — an agent built as a set of tools — the model does not decide the facts. Instead it calls tools: one pulls the registry entry, another screens the sanctions lists, a third checks insolvency, a fourth traces links in the ownership structure. Each tool has a clearly defined input, a clearly named source, and a clearly bounded output. The model is there to sequence those tool calls and turn their results into a readable conclusion — not to invent facts from memory.
Now the crucial part. When an agent works this way, the reasoning chain is nothing but the sequence of those calls. "Why did you flag this company?" has a concrete answer: because the sanctions tool returned a match from this list on this date, because the ownership tool found this link to this person, because the insolvency tool returned this record. None of it is an after-the-fact reconstruction. It is simply what actually happened, in the order it happened.
And because every tool call is, by its nature, logged — what it asked, which source it drew from, and when — that audit trail comes into being on its own. Not as a feature someone wrote to satisfy a regulator. As a by-product of the agent being assembled from bounded, traceable steps. Deterministic, in plain language, with a source cited for each claim.
Where the human stands in this
The requirement that a human has the final say fits the same architecture just as naturally. When a tool merely presents evidence — here is the match, here is the source, here is the date — and only then does the analyst decide on that basis, the two roles are separated by design. The machine gathers and presents; the person weighs and decides.
This is not a compromise you force yourself into for the regulator's sake. It is a healthier division of labour in its own right. An analyst handed a documented chain — not a verdict, but the material for a verdict — decides better than one handed a bare score they have to trust. Explainability does not serve only the auditor after the fact; above all it serves the person deciding now.
Why it isn't extra work
Let's return to that list of requirements that looked like a pile of paperwork at the start: documented scope, recorded data sources, confidence on each claim, fallback rules, human-review triggers. Look at where they come from in a tool-based agent.
- Scope — the set of tools is the scope. The agent can do exactly what its tools can do, and nothing beyond that. What is not a tool, the agent does not do; the boundary of use is given, not written up.
- Data sources — each tool has its source fixed. An answer therefore knows where it came from, without anyone having to reconstruct it afterwards.
- Confidence and fallback — when a tool finds nothing, or the source is momentarily down, it returns that as a result, not as a confident fabrication. The difference between "I found nothing" and "I found that there is nothing" is decisive in compliance, and in a tool-based design it is legible.
- Audit trail and review triggers — they fall out of the call log that exists anyway, because without it the tool could be neither run nor debugged.
I am not claiming any of this as finished work — deploying a compliance tool is never-ending maintenance and there is always something left to tighten. I am claiming something more modest and more precise: a well-designed tool-based architecture turns these requirements from a separate project into a by-product. Whoever built the agent as a black box, by contrast, chases the same things after the fact and painfully — bolting a layer of explanation onto an opaque core that never had one, and hoping it holds up.
I write this from practice, not theory. I run due-diligence tools of exactly this kind — assembled from bounded queries over specific sources — and the fact that a traceable chain of calls sits behind every answer was not a response to regulation. It was the only way to build and keep such a tool running in the first place.
What I take from it
The usual thing said about AI is that it outruns regulation — the technology races and the rules gasp for breath. Here it is the other way round for once. Regulation is not outrunning the technology; it is catching up with good architecture. What it now asks of AML agents — explainability, a defensible reasoning chain, cited sources, a human with the final say — is not a foreign demand grafted on from outside. It is a description of what such a tool looks like when it is built honestly.
Soberly put: I am not saying that whoever builds from tools is done. I am saying the right architectural choice makes a compliance requirement a by-product rather than a standalone project glued on from the outside to something that was never built for it. Whoever built compliance-grade tools from the start as a set of traceable steps has the reasoning chain regulation is now calling for — because otherwise the tool would not have worked at all. And that is the rare case where a new rule means not more work, but confirmation that the earlier work was done right.
Wrestling with explainability and auditability of AI at your firm? → AI consulting