88% of AI Agent Pilots Never Reach Production. The Top Blocker Is Not the Model.

Eighty-eight percent of enterprise AI agent pilots never reach production. That figure comes from 2026 research by Forrester and Anaconda, and it is worth sitting with, because the reasons underneath it are not the ones most people assume.

Here are the top three blockers, in order:

• Evaluation gaps, cited in 64% of cases
• Governance friction, 57%
• Model reliability, 51%

Notice what is at the bottom of that list. The thing everyone argues about, whether the model is good enough, is the least common reason pilots die. The thing almost nobody discusses, whether anyone defined what success looks like, is the most common.

The real blocker is that nobody wrote down what "working" means

The usual sequence goes like this. A team builds an agent. They test it on a handful of cases they thought of while building it. They demo it to leadership, who are impressed, because demos are designed to be impressive. And then somebody asks how we will know it is working once it is actually running.

At that point the project stops, because nobody has an answer, and inventing one retrospectively is much harder than it sounds. You are no longer asking "does this work", you are asking "what would have had to be true for us to have known", which is a question that tends to end in a committee.

Every production incident then becomes a crisis handled by hand, rather than an exception somebody anticipated and wrote down. That is exhausting in a way that kills projects quietly, without anyone ever declaring them dead.

Why pilots pass and production fails

A pilot runs on the cases you thought of. Production runs on the cases you did not.

Those are different distributions, and the gap between them is where the long tail of exceptions lives. Every business process has one, and the people who run it have usually stopped noticing it, because they handle those exceptions on instinct. Ask somebody to describe how they process invoices and they will describe the 80%. The other 20% is in their head, and it never makes it into the pilot.

So the pilot works, because it was built against the described process. Production does not, because production is the real one.

What an evaluation criterion actually looks like

This is less work than it sounds. For one process, before anything is built, you need three sentences.

What does done look like. Not "handles support tickets" but "the customer has an answer, the ticket is closed or escalated with a note, and the CRM reflects the outcome." If you cannot write that sentence, the agent cannot reach it either, because you have not described a finish line.

What does good look like, as a number. Eighty percent resolved without a human, or the first response out within ten minutes, or zero refunds issued above the threshold. One number you will actually look at next month, not a dashboard of twelve.

What does wrong look like, and what happens then. Which failures are acceptable and which stop the line. Who hears about it. This is the sentence that converts a production incident from a crisis into a defined exception.

Write those before you build, and you have an evaluation. Write them after, and you have an argument.

Governance friction, the second blocker

Fifty-seven percent, and it usually surfaces at the worst moment: the pilot has proved itself, and now somebody asks what exactly this thing can touch in production.

The answer is often that nobody scoped it, because during the pilot it ran with whatever access made the demo work. Retrofitting permissions onto a system that already works is a thankless job and a slow one, and plenty of projects stall there permanently.

The fix is boring and cheap if you do it first. Which systems may this agent reach. Which actions require a human to say yes. Which actions it may never take. Those three decisions take an afternoon before you build and weeks afterwards.

Model reliability comes third for a reason

It is a real problem, and it is the one that has improved fastest. Models today are dramatically better than the ones most failed pilots were built on, and they will be better again next year, largely on somebody else's budget.

Evaluation gaps and governance friction do not improve on their own. They are organisational work, and no model release will do them for you. That is why they sit above reliability on the list, and why a company waiting for better models to rescue a stalled pilot is usually waiting for the wrong thing.

What the 12% do differently

The pilots that graduate tend to share a shape, and it is unglamorous.

They replace a named process, not a capability. Not "AI for customer service" but "the refund request queue."

That process has a named owner, a person whose week measurably improves, who will notice and complain if the agent gets worse.

Done was defined before the build, which means the question "is this working" has an answer that does not require a meeting.

Scope was decided up front, so the permissions conversation happened when it was cheap.

And they start narrow enough to be boring. One queue, one week, one number. The ambition comes later, after the thing has survived contact with the exceptions nobody mentioned.

The three sentences

If you are about to start an agent project, the highest-value hour available to you is not choosing a model or a platform. It is sitting with the person who currently does the work and writing down what done looks like, what good looks like as a number, and what wrong looks like and who hears about it.

That hour is the difference between the 12% and the 88%. It costs nothing, it requires no technology decision, and almost nobody does it, which is precisely why the failure rate is where it is.

Want to test the most advanced AI employees, on one defined process with scoped permissions and an audit trail? Try it here: https://geta.team