How a Dust AI agent runs a KYB review, and where your backoffice still decides

Every payments company, marketplace and BNPL provider runs the same check before letting a merchant transact: whether the company exists, who actually owns it, and whether the declared activity matches the register. It is well-defined, high-volume work, done today by an analyst with six tabs open, which makes it an obvious candidate for a Dust AI agent and a dangerous one. Onboarding a merchant is a decision your regulator can ask you to justify two years later.

So the question is not whether the agent can do the research. It can. The question is what has to sit underneath it for its recommendation to become an action you can defend.

Here is a worked example, a reference setup we can walk through end to end. The agent runs in Dust, the register data comes from Topograph, and the process runs in Forest.

How the Dust AI agent investigates beneficial ownership

It pulls the trade register extract and reconstructs the ownership chain, with beneficial owners computed rather than declared and every data point tied back to its source document.

It queries your backoffice in read mode to check whether a beneficial owner, an IBAN or an address already appears in a known file. That is what catches the merchant you rejected last quarter who came back under a new shell. It only sees what the user account behind it is allowed to see, because it connects through the MCP server with that account's permissions.

Then it compares everything against your risk policy and writes up a proposed risk tier, the gaps it found, the documents missing, and a recommended decision.

The agent files its KYB assessment before anything is executed

The agent writes its assessment into the merchant's case: the reasoning, the recommendation, the source documents it cited.

That single call matters more than it looks. The recommendation is recorded and timestamped before any decision is made, and cannot be rewritten afterwards, so you can compare what the agent recommended against what was actually decided, case by case and in aggregate. That comparison is how you widen an agent's autonomy on evidence: you can see how often a human overruled it, and on which kinds of files.

The agent opens the KYB review, then steps out

One more call opens the KYB review.

This is where an agent wired to a process behaves differently from an agent wired to an API. An API call does one thing and ends. The status is written, the response comes back, nothing remains. Opening a review starts something that keeps running after the agent has moved on. The case now has a state, an owner and a route. If a document is missing, it is still there on Monday, still assigned, with the agent's assessment attached.

The agent did not perform an operation. It started one.

The KYB workflow routes the case, and calls the agent back when it needs judgment

Three checks run in order: completeness, consistency between the declaration and the register, then risk tier, scored on the jurisdictions in the chain, its depth, PEP and sanctions hits, and sector. All three are deterministic, and your compliance team configures them in the workflow instead of in a prompt. In the grey zone they can hand a decision to the agent and keep the rest deterministic, one step at a time.

Low risk and a clean file, the workflow executes on its own. Everything else lands in the right Inbox. The analyst opens one screen holding the declaration, the register extract, the ownership graph, the agent's assessment with discrepancies highlighted, and the linked cases. They read instead of searching, which is most of the time saved.

And they can put the agent back to work without leaving the step. Have we rejected a structure like this before? Summarize the three linked cases. The agent answers with its sources, and the answer is written into the case, not into a side conversation the file will never see. Then they decide, with an approval gate before the write when the requested limit crosses a threshold.

Continuous re-KYB: the case outlives the conversation

If a document is missing, the workflow has the agent draft the exact request for information, sends it, and parks the case. When the merchant replies, the agent re-reads only the delta, because its previous assessment sits in the file, not in a context window that expired days ago.

The same review runs again on its own when the register changes, which is the event-driven re-KYB we built with Topograph. Nothing moved, the case closes and timestamps itself. Something moved, the agent is called back. That is how a point-in-time check becomes continuous compliance without anyone maintaining a review calendar.

Where the AI agent comes back in, and where your backoffice decides

The case sits in one place from beginning to end. The agent is called back whenever the process needs judgment or language.

Everything else stays with the process: the deterministic checks, the routing, the queues, the writes, the approvals, the audit trail.

Why not point the AI agent at your own backoffice API?

That is the real question if you already have a backoffice and an agent that works. Point it at your internal API and here is what you get:

• Write access to production, because someone has to actually activate the merchant

• No stored reasoning, so you never know why it proposed what it proposed, or whether it drifted

• No case and no state, so the merchant who owes you a document exists nowhere

• No queue, so the hard files land in a channel and get handled by whoever sees them

• No branch, so the routing logic ends up in a prompt, where it changes without anyone noticing

• An audit trail that is whatever the agent chose to log

The process still runs. It is no longer defensible.

What it takes to set up automated KYB review

Less than teams expect, because none of it is new. The permissions, the thresholds, the routing rules and the audit trail already exist in your backoffice. Exposing them to an agent means deciding which operations it may call and under which account, not rebuilding them.

The work is in the decisions: which checks stay deterministic, where the agent's autonomy stops, who reviews what. Those are compliance decisions, which is exactly why they belong in a configuration your compliance team owns, not in a prompt.

Talk to us to see it on your own process, or start from the MCP server documentation.