Three Weeks to Build. Three Months Before Anyone Trusted It.

I spent 17 and 18 September in Amsterdam at AGNTCon and MCPCon Europe, run by the Agentic AI Foundation under the Linux Foundation. Two thousand people from more than a thousand companies. A hundred speakers across five tracks. A room that was, by any reasonable measure, the concentrated centre of gravity for agentic AI in Europe right now.

I went expecting arguments about models. Which one, how big, how much. That is what most of the noise in this market is about, and it is what most of my clients ask about first.

That is not what happened. Across two days and dozens of sessions, model choice barely came up, and when it did it was usually to say it mattered less than people think. The rooms that filled up were about governance, review loops and trust. The Foundation's own member survey, shown from the stage, said 81 percent of members are in production with agentic AI, up from roughly 40 percent in April, and 51 percent are at production scale. That is a community that is past the question of whether this works. What they came to talk about was what happens after it works.

One talk named the problem so precisely that I have been repeating it to clients ever since.

The three week agent that took three months

Milos Mandic is a forward deployed engineer at FDE Hub. He told a story about a wholesaler whose sales orders arrive by email in every format a customer can invent. PDFs. Spreadsheets. Photographs of handwritten notes. A team of four read them, checked them, and keyed them into the ERP, all day, every day.

It was close to a perfect project. The customer was communicative. Mailbox and ERP access came through in days. They built an eval set of more than a hundred real orders, and the agent passed all of them. Working agent in three weeks. Into production. Everyone happy.

Then the operators found the wrong orders. And after that, they checked everything by hand.

Three weeks to build. Three months before anyone trusted it. The build was never the hard part.

Why the gap exists

Mandic gave four reasons, and not one of them is technical.

• It is probabilistic software. It does what it thinks you meant, and people feel that. Deterministic software that is wrong is broken. Probabilistic software that is wrong is unsettling in a different way, and the difference registers before anyone can articulate it.
• Operators have years of intuition invested. They want to watch the thing survive the edge cases they know about. That is not obstruction. It is the exact expertise you hired them for, applied to a new colleague.
• There is no upside for the person in the loop. If the agent succeeds, the most optimistic reading of their situation is that their job changed. Nobody reviews carefully on behalf of a system they suspect is there to replace them.
• The 100 percent illusion. "We don't make mistakes." Human error in the existing process is invisible because it has been normalised for years. One AI error is visible, novel, and proves the point everyone was already half expecting.

You cannot engineer around any of those with a better prompt. They are properties of the people the system lands on, which means they need to be in the plan from week one rather than discovered in month two.

The thing your evals cannot catch

This was the sharpest slide of the two days, and it is the one I would put in front of anyone about to sign off on an agent going live.

The agent does not say "not sure". It says "done", and it proceeds. That is the whole problem in one sentence.

The eval set had more than a hundred real orders and the agent scored 100 percent. Production runs about 200 orders a day. The evals cannot cover that, and more importantly, there is no way to know which production orders fell outside what the evals covered without a human reading the original document.

After-the-fact checking does not close this. You can check totals. You can check dates. You can check whether the customer is one you know. None of those check completeness, because completeness is a property of the source document, and the source document is the thing you were trying to stop reading.

I have seen this exact failure in client work and never had language for it. A validation layer that looks thorough, passes everything, and is structurally incapable of detecting the one class of error that matters. Every check you can run cheaply is a check on what the agent produced. The error you care about is in what it silently left out.

This is not one company having bad luck

I would have filed that story under unlucky if the rest of the conference had not kept producing the same shape from completely different directions.

Janosch Woschitz, a senior cloud and AI architect at BARMER, opened his session on running agents inside German statutory health insurance with a Gartner figure from May 2026: 40 percent of enterprises will demote or decommission autonomous AI agents by 2027, because of governance gaps discovered only after a production incident. Not because the agents failed to work. Because nobody could prove what they had done.

Jigyasa Grover of Uber and Rishabh Misra of Atlassian gave a talk called "When NOT To Use an Agent" and put two numbers on the board that should be in every board pack on this subject. 54 percent of deployed agents had a security incident in the last 12 months. And more than 40 percent of agentic AI projects are forecast to be cancelled by the end of 2027, on cost and unclear value. Seshu Tolety of Siemens, in a different room on a different day, reported 51 percent of organisations already seeing production incidents.

Read those together and the picture is not that agents do not work. It is that a large share of the programs that do work will be switched off anyway, by organisations that could not build enough confidence in them fast enough to keep them.

A ladder, with numbers on it

The useful half of Mandic's talk was what he does now. Four stages, and every one of them has a gate you can actually measure rather than a feeling you have to wait for.

Note stage three. "Escalation path exercised, not just documented" is doing an enormous amount of work in that table. Everyone writes the escalation path. Almost nobody runs it before they need it.

Their own mistake, in the model's own terms, was that they shipped at stage three. The operators had never seen stages one and two, so the first time they encountered the agent's judgement was the day it started booking orders. The recovery was to step back to stage two, not to zero, and to close the loop by continuously comparing released orders against what the agent had proposed. His warning on that: you get one chance, maybe two.

The reframe underneath the whole model is the part I keep coming back to.

Autonomy is a permission set, not a model setting. The stage is which tools are in the agent's set: reads only, then a draft write, then a booked write. The gate is what sits on the write call: a human release, then deterministic checks with a human queue, then monitoring. Whether you connect it with MCP, plain APIs or a mix is an implementation detail. None of it is a slider you turn up when the model gets better.

The question to ask in week one

Different processes deserve different ladder speeds, and there is a way to work out which you are on before you start.

This is the question I now open agent conversations with, ahead of anything about architecture. It tells you how much governance the use case can carry before the governance costs more than the automation saves, and it is a conversation the business can have without a technical translator in the room.

Three rooms, one conclusion

What convinced me this is a pattern rather than a talk was watching three unrelated speakers arrive at the same place from three different starting points.

BARMER, from regulation. Woschitz runs agents inside a statutory health insurer with 8.3 million insured people and more than 14,000 employees, under GDPR, the EU AI Act and German social code simultaneously. His architecture is deterministic first, with agents invoked only where reasoning genuinely adds value. He keeps two separate records on purpose: a technical audit log answering how it happened, which ran to more than 80,000 lines for a single insurance case, and a business decision record answering what happened. His line was that the challenge is not making agents intelligent enough, it is making their autonomy governable. Regulation is an input to the architecture, not a wrapper you put around it afterwards.

Project Lions, from team adoption. Thomas Schöne walked through taking a team of four from open scepticism to productive agentic workflows in 90 days. His governance answer was to give autonomy a risk budget: low impact and easy rollback earns more freedom, high impact and hard rollback earns more approval. Every experiment gets one of three verdicts. Stop, rework, or standardize. Not every experiment deserves to become infrastructure. He also named a trap I have walked into myself, which is that if a prototype looks finished, people assume it is finished, and plausible is not the same as correct.

Datadog, from one engineer's queue. Vincent Ysmal described running eight agents and becoming, in his words, eight very fast coworkers and one extremely slow QA department. His fix was not to prompt better. He filed the problem as a bug against his own system, with the component listed as "my system, not the agent", and moved verification into the agent's entry requirement for opening a pull request rather than leaving it in his review.

Regulation, adoption, and one person's review queue. Three different problems. The same answer every time: define what earns the next increment of trust, in advance, in terms somebody can check.

Going live is not the end of it

One more thing from Mandic's talk that almost nobody plans for. The business keeps moving. Prices change, customers change, rules change. The agent keeps acting on the version of the world that existed the day it shipped.

So changes to what the agent believes have to go through the same gate as changes to what it does. Proposed rule, evidence, diff, confirmation. Someone has to own what the agent knows, and decide what is still true. That is a standing role, not a launch task, and in my experience it is the single most reliably unassigned job in an agent program.

The gap is the point

If you are planning agent work this year, the schedule risk is not in the build. Three weeks is realistic for a well-scoped agent against a clean process. The part that is not in your plan is the months between the thing working and the people relying on it, and the 40 percent Gartner expects to switch their agents off are mostly organisations that never budgeted for those months.

The fix is not more autonomy sooner. It is writing down, before you build, what each increment of autonomy has to earn, and who checks. Stages are the plan, not the recovery. Operators in from the first call. A reaction to every action.

Mandic's closing line was the one that stayed with me, and it is a better way to think about this than treating the delay as friction to be minimised. The trust gap is not a bug. It makes you earn the right to remove the human from the loop, instead of assuming it.