The demo goes well. It always goes well.
Someone from the innovation team walks the room through an agent that reads a ticket, pulls the customer record, checks three internal systems, drafts a resolution, and posts it back. Eleven seconds, start to finish. Somebody in the back asks what happens if the customer record is missing. The presenter says that is a great question and they are handling it in the next iteration.
Six months later, the agent is still in the next iteration.
This is not a rare story. It is, statistically, the normal outcome. And the numbers behind it have gotten specific enough in 2026 that we can stop treating this as anecdote and start treating it as a pattern with named causes.
The Numbers, and What They Actually Say
Three separate pieces of research published between January and March 2026, from Gartner, from McKinsey, and from a cross-sector analysis by the AI Governance Institute, converged on roughly the same figure: between 86 and 89 percent of enterprise AI agent pilots never reach production. Gartner's own number is 89 percent.
That figure lands alongside a set of others that tell the same story from different angles.
Two caveats before anyone quotes these at a board meeting, because I would rather you use them carefully than have them used against you.
These are survey numbers, and surveys measure what people say. "In production" is not a standardized term. For one company it means a system serving external customers with an on-call rotation behind it. For another it means an internal tool that six people use on Fridays. The 12 percent and the 14 percent are probably measuring slightly different things, which is why they are close but not identical.
A lot of this research is vendor-adjacent. The reports that tell you 88 percent of pilots fail are frequently published by companies selling the thing that supposedly fixes it. That does not make the number wrong. Failure this consistent shows up in too many independent places to be manufactured. But treat the 171 percent ROI figure that gets attached to the survivors with real skepticism, because self-reported ROI on a project you personally championed is one of the least reliable measurements in enterprise software.
What survives the skepticism is the shape of the distribution. Almost everyone starts. Almost nobody finishes. And the gap is not narrowing as models get better, which is the part that should tell you something.
The Failure Is Structural, Not Technical
Here is the thing that took me a while to accept: in almost none of these cases is the model the problem.
The frontier models available in 2026 are, for the overwhelming majority of enterprise agent use cases, more than capable enough. They can read the ticket. They can reason about the customer record. They can draft the resolution. The demo works because the model works.
The pilot dies for reasons that have nothing to do with inference quality. It dies because the data it needs lives in a system nobody has API access to. It dies because there is no way to tell whether version 4 of the prompt is better than version 3. It dies because the person who built it moved to another team and nobody inherited it. It dies because someone in security asked one question in month five that nobody had an answer to.
If you have shipped software for a while, none of this will surprise you. It is the same set of reasons ordinary projects die. What is different with agents is the gap between how easy the first 80 percent is and how hard the last 20 percent is. A traditional software prototype that does 80 percent of the job looks like a prototype. An agent prototype that does 80 percent of the job looks finished, and that illusion is expensive.
So let me go through where they actually die, in roughly the order I have seen them die.
Six Places Pilots Die
1. Nobody ever wrote down what "working" means.
This is the most common one and the least discussed, because it does not feel like a technical decision. The pilot gets approved with a goal like "reduce ticket handling time" or "help the sales team with research." Neither of those can be passed or failed. There is no threshold. There is no number that, once reached, triggers a decision to ship.
What happens next is predictable. The agent gets demoed repeatedly, everyone agrees it is impressive, and it stays impressive forever. Without a definition of done, the default outcome is indefinite iteration, and indefinite iteration is indistinguishable from failure after the budget runs out.
The teams that ship write the success criterion before they write the prompt. "Resolves 40 percent of tier-one tickets without human edits, with under 2 percent incorrect resolutions" is a criterion. It can be measured, it can be missed, and it can be passed.
2. There is no evaluation harness, so nobody can tell if changes help.
Once the definition of done exists, you need something to measure it against. Most pilots do not have this. They have a person who tries a few inputs after each change and forms an impression.
That approach holds up for about two weeks. After that, the prompt has grown to 900 tokens, three people have edited it, and nobody can tell whether last Thursday's change improved accuracy on edge cases or quietly broke the thing that was working. Every subsequent change is a coin flip that feels like progress.
I have written about this failure mode at length in why your demo works but production fails, so I will keep it short here: the eval set is not the thing you build after the agent works. It is the thing that tells you whether the agent works. Building it second is the single most common ordering mistake in this entire field.
3. The data was never actually accessible.
The demo ran on a curated folder. Forty documents, hand-picked, clean, current. Production runs on the real corpus: twelve thousand documents, four different vendors' PDF exports, scanned contracts from 2019, three overlapping versions of the same policy where only one is current and none of them say so.
This is where a large share of retrieval-based agents quietly fall apart. The retrieval layer does not throw an error when it feeds the model a chunk from a superseded policy. It just returns a confidently wrong answer, and the failure surfaces weeks later through a user complaint rather than a stack trace. I went through the production-side version of this in RAG in production, and the chunking decisions that make or break it in chunking strategies for RAG.
The organizational version of this problem is worse than the technical one. Frequently the data the agent needs sits behind a system whose owner has no incentive to grant access, no API, and no roadmap slot for building one. The pilot then spends four months negotiating for a database export. That negotiation, not the model, is the critical path.
4. Nobody owns it after the demo.
Pilots are usually built by whoever is most excited: an innovation group, a data science team, one motivated engineer. Production systems are owned by teams with on-call rotations, error budgets, and a headcount plan.
Between those two states there is a handoff, and the handoff is where most pilots stop. The receiving team looks at an unowned system with no tests, no runbook, no cost model, and an unbounded failure mode, and reasonably declines. Nobody says no explicitly. The project just enters a queue and stays there.
If you cannot name the team that will be paged at 3am when the agent starts approving the wrong refunds, you do not have a path to production. You have a demo with a roadmap attached.
5. Nobody did the unit economics.
A pilot processing forty requests a day costs nothing worth measuring. The same agent at forty thousand requests a day is a line item, and the first time anyone calculates that line item is often after the pilot has already been declared a success.
The math is frequently unpleasant, especially for multi-step agents, because a single user-facing "request" can be fifteen model calls with a growing context on each one. If nobody projected the cost at target volume, the project can be killed by a finance review it never saw coming.
This is recoverable, and it is recoverable earlier than most people think. Prompt caching, model routing, and semantic caching can move these numbers substantially, and I go through the mechanics in prompt caching and semantic caching. But you have to run the projection during the pilot, at target volume, not after. A cost model built in week two changes the architecture. A cost model built in month eight cancels the project.
6. Security and compliance arrive at the end, and they arrive with veto power.
The pilot connects to internal systems using someone's personal API key, because that was the fastest way to get it working. It has read access to a share drive that includes HR files, because scoping the permissions properly would have taken a week. It processes text that comes from customers, and it has tools that can act on that text.
That last combination is the one that ends projects. An agent that reads untrusted input and holds the ability to act on internal systems is a live prompt injection target, and there is no configuration setting that makes that go away. The credential problem is nearly as bad: non-human identities already outnumber human ones by roughly 45 to 1 across enterprises, and the majority of organizations say their existing identity tooling cannot handle agents at all.
Add the regulatory layer on top. If you serve EU users, the Article 50 disclosure obligations are enforceable as of this month, and they are not a checkbox you tick at launch. They shape what your agent has to say, in which surface, and in what format.
None of this is unsolvable. All of it is very hard to retrofit onto a system that was built without it, which is why it functions as a veto rather than a work item.
The Reliability Trap Nobody Prices In
The six causes above are organizational. There is a seventh that is purely mathematical, and it explains why agents specifically fail at a higher rate than other LLM applications.
Agents are sequential. A single user request becomes a chain: read the input, choose a tool, call it, interpret the result, choose the next tool, and so on. Each step has an independent chance of going wrong, and the chances multiply.
Read the 95 percent row twice. A component that is right 95 times out of 100 sounds excellent. Any engineer would sign off on it. Chain twenty of them together and the whole task succeeds about a third of the time.
This is why measured end-to-end success rates for production agents cluster in the fifties, and why "the model is really good now" does not translate into "the agent works." Going from 95 to 99 percent per step is a very large amount of engineering work, and it buys you a system that still fails one task in five at twenty steps.
The practical consequence is not "give up on agents." It is that step count is a design parameter you control, and it is the highest-leverage one you have. An agent with four tool calls and a deterministic control flow is a fundamentally different reliability proposition from an agent with twenty and an open-ended plan. Most pilots that fail chose the second shape because it demos better.
What the Ones That Ship Do Differently
Across the teams I have seen get something into production and keep it there, the same handful of choices show up. None of them are clever. All of them are unglamorous.
They constrain the task ruthlessly. Not "an agent that handles support," but "an agent that handles password resets and subscription changes, and routes everything else to a human immediately." Narrow, high-certainty, and boring. The scope creep that makes the demo impressive is the same scope creep that pushes step count into the failure zone.
They build the eval set first. Fifty to two hundred real examples with known-correct outcomes, assembled before any prompt engineering, and treated as the definition of the project. Every subsequent change is measured against it.
They keep a human in the loop where the cost of being wrong is asymmetric. Not a token approval button that people click through in half a second, but a real escalation path with a defined owner, a queue, and a service level. An agent that resolves 40 percent of tickets and cleanly escalates 60 percent is a working system. An agent that attempts 100 percent and is right 70 percent of the time is a liability.
They instrument from day one. Every model call traced, every tool call logged with inputs and outputs, cost attributed per request and per feature. When something breaks in week nine, they can answer "when did this start" in ten minutes rather than reconstructing it from memory.
They measure the baseline before they start. What does the human process cost right now, in minutes and in errors? Without that number, there is no honest way to claim improvement, and the project's value becomes a matter of opinion, which is a bad thing for a project to be when budgets get reviewed.
They give the agent its own scoped identity. Short-lived, task-scoped credentials rather than a borrowed service account with standing access to everything. This is the piece that gets skipped most often in pilots and blocks the most often at the security review.
How to Run a Pilot That Can Actually Graduate
If you are about to start one, or you are eight weeks into one that has been going great and shipping nothing, here is the reordering I would suggest.
Before writing a prompt, write down the success criterion as a number, assemble the evaluation set, and name the team that will own the system in production. If you cannot do the third one, you are building a proof of concept, which is fine, but call it that and set the budget accordingly.
In week one, connect to the real data, not a curated sample. Whatever is ugly about your actual corpus is going to be the hardest part of the project, so find out in week one rather than month four. If access requires a negotiation with another team, start that negotiation before you start building.
In week two, project the cost at target volume and show it to whoever owns the budget. Also count your steps. If the design needs more than about ten sequential model calls to complete a typical task, look hard at whether some of those steps can be deterministic code instead.
In week three, bring in security. Show them the tool permissions, the credential model, and the untrusted input paths. You want their objections while the architecture is still soft.
Throughout, define kill criteria alongside success criteria. "If we are not at 30 percent unassisted resolution by week eight, we stop." Pilots without kill criteria do not fail, they linger, and lingering pilots consume the budget and the credibility that the next attempt would have needed.
The broader organizational version of this sequencing, for teams introducing AI across processes rather than in a single workflow, is something I covered in how to integrate AI into business processes without disrupting everything.
The Honest Summary
The 88 percent number is real enough to plan around, and it is not primarily a story about model quality.
Pilots die because the success criterion was never written down, because there was no eval harness to tell progress from noise, because the real data was messier or less accessible than the demo data, because no team was ever going to own the result, because the unit economics went unexamined until it was too late to change the architecture, and because security and compliance showed up at the end holding a veto.
Underneath all of that sits the compounding arithmetic: reliable components chained together produce an unreliable system, and the fix is fewer steps rather than better steps.
The uncomfortable implication is that the demo, the artifact everyone uses to decide whether to proceed, is measuring almost none of the things that determine whether the project survives. It tests the model on the happy path in front of a friendly audience. It does not test data access, ownership, cost, security posture, or step-count reliability, and those are the five things that kill it.
So if your agent demo went well last week, that is genuinely good news about your model choice, and close to no news at all about your odds of shipping. The real question is the boring one: who owns this in production, what number does it have to hit, and what happens the first time it is confidently wrong?
If you have answers to those three, you are already doing better than most.