The 88% Agent Pilot Failure Rate Has No Source. These Six Failure Modes Do.

The figure everyone quotes for agent pilot failure is 88%, and it has no primary source. The numbers that do have one are smaller and more useful. S&P Global measured 46% of AI proofs of concept scrapped before production. Deloitte found 11% of organisations running agents in production. Neither failure is about model quality.

The numbers you can actually check

Start with what a stated sample supports. Three sources carry one, and they disagree with the headline everyone repeats.

The 46% with a sample behind it

S&P Global Market Intelligence surveyed more than 1,000 respondents in North America and Europe. The average organisation scrapped 46% of its AI proofs of concept before they reached production. The share of businesses scrapping most of their AI work rose to 42%, up from 17% the year before. Alongside that, two-thirds admitted they could not transition pilots into production.

That last clause is the one to keep. It is a self-reported admission of an organisational limit, not a verdict on the technology.

What Deloitte's 11% actually counts

Deloitte's 2025 Emerging Technology Trends study found 30% of organisations exploring agentic options, 38% piloting, 14% with something ready to deploy and 11% actively using agents in production. These are shares of surveyed organisations at each stage. They are not one cohort moving through a funnel.

Subtract 11 from 100 and you get 89. That subtraction is where most of the circulating failure rates come from, and it is invalid. A company at the exploring stage has not failed a pilot. It has not run one.

Six restatements is still one source

The 88% figure is usually attributed to Anaconda and Forrester research. Searching for that underlying document returns only other posts making the same attribution. No sample size, no fielding window, no methodology page.

There is one traceable number in the high eighties. The MAST paper from Berkeley and collaborators reports a 41% to 86.7% failure rate across seven open-source multi-agent systems on benchmark tasks. That is software failing tasks in a lab. It is not an enterprise failing to deploy, and the two have been quietly merged.

My position is blunt. Any vendor deck that opens with 88% and no citation should be treated as marketing, and a buyer is entitled to ask for the sample before reading page two. The same discipline applies to the wider return question covered in the piece on where measurable AI return has actually shown up.

The last row is not an accusation that the number is false. It is a statement that nobody publishing it has shown where it came from, which is the same thing as unusable.

Failure mode 1: nobody wrote down the number that ends the pilot

Gartner attributes the coming cancellations to escalating costs, unclear business value and inadequate risk controls. Anushree Verma, the senior director analyst behind the forecast, put it directly: most agentic projects are hype-driven experiments or proofs of concept.

An experiment without a threshold cannot conclude. It can only continue or be defunded, and defunding gets recorded as failure. That is how a pilot that worked fine ends up in the abandonment statistics.

The pattern is consistent. Someone demos an agent, the room agrees it is impressive, and the pilot proceeds with a goal like improving efficiency. Six weeks later there is no baseline to compare against, because nobody recorded one before the agent existed.

The design constraint. Write three things before any code runs: the metric, its value in the 30 days before the pilot, and the number below which you stop. Put a date on the third. A pilot with a kill number produces a decision either way, and a pilot without one produces an argument. Cost belongs in that number too, which is why the arithmetic of per-conversation agent pricing should be settled before the pilot, not after the invoice.

Failure mode 2: the agent has no owner after the demo

Pilots are usually built by whoever was curious. That works until the thing needs to run on a Tuesday morning when its author is on leave.

IBM's Institute for Business Value, with Oxford Economics, surveyed 2,000 senior technology executives across 33 geographies and 19 industries between January and April 2026. It found 67% of CIOs and CTOs accountable for AI systems they do not fully control. A further 70% reported that business teams deploy faster than IT can track.

That is a specific organisational shape, not general disorder. Accountability sits with technology leadership. Deployment sits with the business. The gap between them is where a working pilot goes to die, because no single person can both approve the production spend and answer for the outcome.

The design constraint. Name one accountable owner before the pilot starts, with a budget line and an on-call obligation. If nobody will take it, that answer arrived cheaply and you have saved the build. I would treat an unclaimed pilot as a failed pilot on day one rather than week twelve.

Failure mode 3: access is a permissions project wearing an API costume

The demo reads a sample file. Production reads the actual system of record, which has owners, retention rules and an access review committee.

Deloitte's data on this is unglamorous and decisive. Among surveyed organisations, 48% cited searchability of data as a challenge and 47% cited reusability. Those are not model problems. They describe an archive nobody has curated for machine consumption.

The Cloud Security Alliance surveyed 228 IT and security professionals in January 2026 and found how agents are actually identified in these systems. 43% run on shared or generic service accounts, only 36% get a dedicated identity, and 31% operate under a human user's identity. A further 43% said standing up authentication takes 1 to 10 days of engineering effort, and 32% did not know.

The design constraint. Give the agent its own identity, scoped to the data it needs, on the first day of the pilot. A pilot running on a borrowed human login is not a small version of production. It is a different system that will have to be rebuilt. The interoperability question sits next to this one, and is covered in the analysis of what MCP does and does not standardise.

Failure mode 4: the evaluation was built for the demo

Most pilots are judged by watching. A person runs 20 prompts, likes 17 of them, and calls the result promising. That is a review, not an evaluation, and it cannot detect the failure that matters, which is the rare wrong answer delivered confidently at 2am.

The research points the same way. In the MAST taxonomy, task verification is its own failure category, holding 3 of the 14 documented failure modes. Verification is not a stage bolted on at the end. It is a place where systems break.

EnterpriseClawBench, published in June 2026, makes the argument harder. Its authors built 852 reproducible tasks from real workplace agent sessions. They concluded that enterprise agent evaluation must report harness and model combinations, artifact delivery, cost, runtime and skill transfer. Collapsing all of that into one score hides the thing you needed to see.

The design constraint. Build the evaluation set from real sessions before the pilot, with rubrics written by the people who do the work. Score cost and runtime alongside correctness. If your evaluation cannot fail the agent, it is not measuring anything, and orchestration tooling will not save it either, as the survey of agent orchestration tools sets out.

Failure mode 5: the task is longer than the agent's reliable horizon

This is the one failure mode where model capability genuinely is the constraint, and it is narrower than the discourse suggests.

TheAgentCompany benchmark from Carnegie Mellon puts agents inside a simulated small software company with internal sites, colleagues and data. The finding, published at NeurIPS 2025, is that the most competitive agent completed 30% of tasks autonomously. The authors are precise about the shape of the result: simpler tasks solve well, and longer-horizon tasks remain beyond current systems.

EnterpriseClawBench, on tasks recovered from real sessions rather than a simulation, reports a best configuration score of 0.663. Different scale, same message. Bounded work succeeds and unbounded work does not.

The design constraint. Cut every agent task at the last point a human can verify in under a minute. Three verified handoffs beat one unverified end-to-end run, even though the demo looks worse. Scoping to the checkpoint is also what makes the build-versus-buy question answerable, which is the subject of the piece on building against buying coding agents.

Failure mode 6: the incident bill arrives at a team that never approved the work

Pilots are usually evaluated on upside. The cost that kills them is the incident, and it is now measurable.

IBM's 2026 study found an average of 54 AI agent incidents per organisation over the prior year. Of those, 17% were high severity and took more than 4 hours to contain, 37% resulted in data exposure or a breach, 33% caused cascading system failures and 17% triggered compliance issues.

The same study found 77% of respondents saying AI adoption outpaces their governance capability, and 59% naming security and compliance as the top barrier to scaling. Only 11% believed they were fully prepared for the agent volume they expect.

Read that against the Cloud Security Alliance finding that 81% agree prompt manipulation could expose credentials. A security team that sees those two numbers together will block promotion to production, and it will be right to.

The design constraint. Ship the rollback before the capability. A duty engineer who has never met the builder must be able to stop the agent, revoke its credentials and confirm what it touched, using a written runbook. Organisations that embedded control into the system rather than bolting it on reported 25% fewer incidents.

Where this argument is weakest

Three things in this post are softer than the confident tone implies.

Almost every number here is self-reported

S&P Global, Deloitte, IBM and the Cloud Security Alliance all asked people what happened. Nobody observed the deployments. Executives systematically misremember why a project died, usually in a direction that flatters the teller. Incident counts depend entirely on what an organisation bothers to classify as an incident.

Pilots are supposed to die

This is the strongest counter-argument and it deserves more space than it usually gets. A 46% scrap rate would be unremarkable for research spending, and a portfolio where every experiment ships is a portfolio that was not experimenting. Amanda Luther of BCG made this point to CIO Dive, arguing that celebrating some of these failures matters.

The honest version is that failure rate alone tells you nothing. What matters is whether the failures were cheap and fast. A pilot killed in three weeks on a written threshold is a good outcome. The same pilot killed in month nine after a steering committee is a bad one, and both land in the same statistic.

The benchmarks are not measuring your pilot

TheAgentCompany runs on a simulated company. MAST measures open-source frameworks. EnterpriseClawBench does not release its data, so nobody can reproduce it independently. All three are the best public evidence available on agent capability, and none of them tested the tool your vendor sold you.

Frequently asked questions

Where to start this week

Pick the agent pilot currently furthest along in your organisation and answer two questions about it in writing.

First, what identity does it run under. If the answer is a shared service account or a person's login, you have found the reason it will not be promoted, and the fix is a ticket rather than a research project.

Second, what number ends it. If nobody can name a threshold and a date, set both this week and backdate the baseline using whatever record you already have. An imperfect baseline recorded now beats a perfect one nobody will ever construct.

Both answers take an afternoon. Neither requires a vendor, a budget or a new tool. That is the point, because the six modes above are organisational, and organisational problems are the cheap ones to fix early.

Related reading