Why AI agents do not reach production: the data problem

You have built an agent that can read a trade register, walk through your KYB process and propose a decision and yet it is still not in production. The results it returns are not up to your expectations. The cause sits upstream of the model and the prompt. It was settled at design time.

Most agents that fail to reach production often share one common origin, the process they aim to automate is not documented enough.

• What are the steps of the process and are they followed in the same way by every team?

• What data do the teams need and is that data any good?

• What are the third party costs in my project and what is their weight in the total cost of the process?

Without a precisely documented process, you cannot automate a uniform process or calibrate the agent's decisions. Without a complete map of the data and of its quality, the agent decides without the information it needs. Finally, without a cost study, the agent ends up more expensive than a team of 10 operators.

The know-how of your teams is often neglected, for lack of time. Pinning it down is now essential. Without it, your agent will never reach production.

Case 4812, a KYB onboarding received at 03:02, runs through this article as an illustration, and it is a reference setup, not a client file.

Map the data the decision needs, not the tools where it lives

A connector gives access to a system, nothing more. Inside that system, the data lives in tables and columns, and each process requires a different and potentially changing context. Wiring up the CRM therefore says nothing about the data your agent will really need to take a defensible decision.

The first step in putting an agent on your process is to map the fields your operator uses for each decision they make. The data they open, the data they check, the data they ignore. That list is the read scope, the set of data your AI agent will need to run the process.

Without it, either you grant your AI agent too little visibility on the data, and it answers you anyway, without flagging that a deciding field was missing. Or you grant the whole schema and you can no longer guarantee that your AI agent has not reached data it was not meant to use. In a regulated entity, that is a level of exposure your compliance teams and your Secops will not accept.

Your operators have an experience and an ability to adapt that your agents know nothing of and that is hard to reproduce if it is not documented. That creates a wider gap than teams expect, between the results your operators deliver and what your AI agent delivers.

A read scope you cannot justify field by field stays a default setting.

Map the process, then check that your own team follows it

Every process has holes your teams have got used to crossing on a daily basis. The exceptions, the edge cases, the step everyone has their own way of handling. Your team applies know-how it has acquired: it knows which field stopped being maintained, it knows who to ask, it knows that this shape of file goes up a level. It is not documented and yet it is stable. That is exactly why the process runs despite the hole in the map.

An agent is probabilistic, and facing the same zone it fills it in a plausible way, differently on each run. That improvisation is not tolerated in the case of a regulated process. Whether the hit rate is good or bad, a decision you cannot reproduce cannot be justified, yet that is exactly what your regulator will ask you for during an audit.

Sometimes despite a documented process, execution diverges. Take the same case and give it to three of your operators, then look at how many paths you get. Three different paths point to a process that is not mature enough.

If each operator follows their own process and if the decisions that follow are too different from one another, that has the consequence of limiting what your agent will be able to learn from how past situations were handled.

One of the crucial steps for your AI agent to work in production is the phase of analysing cases already handled and whose decision was validated. You replay the agent on them and you measure where its decision diverges from the one your team recorded. You run it in shadow alongside your analyst, then as a copilot, and every human review grows the reference set. For that mechanism to work, it assumes the decisions were taken in the same way. If three analysts settled the same case differently, you cannot automate your process.

Fields abandoned after a migration, categories that meant something else two years ago, entries filled differently by each team for years. Your senior analyst works with that, and they know which field stopped being maintained. They also know that a case marked verified in March did not pass the same checks as a case marked verified in September, and they know it without documentation. They hold an experience your AI agent will only acquire by watching the decisions taken all along the process.

Without consistency in past decisions, there is no calibration possible, and your AI agent will never leave its sandbox.

What an agent costs is decided by the first two maps

The invoice is directly driven by the way you designed your AI agent. The fields you never listed turn into round trips, and those get billed. A badly built MCP server makes several calls for one piece of information.

The unit price is not constant either, and it changes with the jurisdiction. A register call for a KYB in France and the same check in Luxembourg do not cost the same. The registers, their coverage and the pricing change with the country, or with the access mode, leading to a factor of twenty to thirty on the pricing.

One rule comes out of all this, and it is simple to apply. Only give search tools to your AI agent when you know precisely what data you want to fetch and how to reach it.

Knowing which of the two cases you are in assumes the mapping is done. An access design left to chance shows on the invoice before it shows anywhere else, and it brings you back to the first question.

Keeping control while you move a process to agents

You already have the permissions, the thresholds and the audit trail in your backoffice. Forest is the operational layer that brings operators and AI agents into one tool. It runs on your own database, live and writable, with no ETL.

One door, where your ops team, your BPO, or a third party AI agent receive exactly the fields and the scopes the process requires and that their roles and permissions give them access to. A record level audit trail behind every read and every write logs each decision taken by an operator or an AI agent.

The Forest backoffice lets you keep control over your operations. You move your processes to agents at your own pace, without touching the rest of your operations. On each process, you start in shadow, then as a copilot, then you widen the autonomy.

Documenting and mapping your processes goes well beyond the agentic question. Your teams line up on a single process, instead of three versions coexisting without anyone having decided so. They save time before a single AI agent is in production. Start with the process your operators know best: its map is already half done.

Level up your ops game. Book a demo.

Forest is the operational infrastructure for regulated fintechs. Compliance, ops, and support teams work on your systems alongside your AI agents, under one permission model and one audit trail. On your own infrastructure. Learn more at forest.app.