Most agent projects will be cancelled. This is why.

Seventy-nine percent of enterprises report adopting AI agents. Eleven percent run them in production.

That sixty-eight point gap is the entire subject. Gartner, polling more than 3,400 organisations actively investing in the technology, forecasts that over 40% of agentic AI projects will be cancelled by the end of 2027. Not descoped, not paused. Cancelled. The stated causes are escalating costs, unclear business value, and inadequate risk controls.

Read that list again, because the most widely repeated interpretation of it is wrong. Not one of the three causes is a model capability problem. The cancellations are not coming because the agents cannot do the work. They are coming because the organisations deploying them did not establish what the work was worth, what it would cost, or who would notice when it went wrong. And the single most common failure underneath all three is that the use case never required an agent in the first place.

This is an account of what actually goes wrong, drawn from the survey evidence rather than from vendor case studies, and written by a party with nothing to sell you.

The shape of the failure

Three independent datasets describe the same pattern from different angles.

Gartner's poll of 3,400-plus organisations produced the 40% figure and its three causes. MIT Sloan Management Review and Boston Consulting Group, surveying over 2,100 organisations in late 2025, found agentic AI reaching 35% adoption within two years, faster than any previous AI wave, with most implementations stuck in what they termed pilot purgatory. Deloitte, in the same period, found 14% of organisations with solutions ready to deploy and 11% actually running agents in production.

The consistent finding across all three is that adoption and deployment have come apart. Organisations are not failing to start. They are failing to finish, and they are failing at a specific point: the transition from a pilot that worked to a system that operates.

One more number gives the transition its shape. In a Deloitte survey of roughly 1,800 executives across Europe and the Middle East, 6% reported achieving payback on AI investment in under a year. The majority put it at two to four years. Against that, a Kyndryl study found 61% of chief executives feeling more pressure to demonstrate AI return than they had twelve months earlier.

A payback horizon of two to four years, meeting an accountability horizon of one, is a cancellation waiting for its budget review.

Where the sixty-eight points actually go

The gap between 79% adopting and 11% deploying is not one obstacle. Projects die at four distinguishable stages, and knowing which one you are approaching changes what you should do about it.

Stage one, the demo that convinced someone. A working prototype on curated inputs. Almost everything reaches here, which is why adoption figures are high and mean little. The failure at this stage is not building it; it is that nobody wrote down what would constitute success before it was built, so the demo becomes its own justification.

Stage two, the integration wall. The agent needs to reach a system of record, and that system has an access model designed for humans and applications rather than for autonomous processes acting on a user's behalf. Legacy integration is the most consistently underestimated part of the work and the point where the largest share of pilots stop. The prototype ran against a copy of the data. Production needs the real thing, with permissions.

Stage three, the reliability floor. The system works and works often enough to be tantalising and not often enough to be trusted. This is where the per-step arithmetic above becomes visible, and where teams discover that the last ten points of reliability cost more than the first ninety.

Stage four, the accountability question. It works, it is affordable, and someone in risk or legal asks who is responsible when it is wrong. If that answer was not designed in, retrofitting it means rebuilding the permission model, and the cost of doing so at this stage frequently exceeds the remaining budget.

The useful implication is that each stage has a different remedy and a different point of no return. Stage two is solved before you start, by checking access rather than assuming it. Stage four is solved before you start, by deciding who owns the output. Stages one and three are engineering. Two of the four are decisions, and they are the two that cancel projects late and expensively.

Cause one: costs that were never modelled

The cost that gets estimated is inference. It is the visible number, the one with a published rate card, and it is usually the smallest component.

Retries and failed runs. An agent that fails at step seven of nine has consumed the tokens for steps one through seven and produced nothing. If the failure rate is 15% and the workflow is long, a substantial share of total spend buys nothing at all. This does not appear in any per-call estimate, because per-call estimates assume calls succeed.

Context growth. In a multi-step workflow, later steps carry the accumulated output of earlier ones. Cost per step therefore rises through the workflow rather than staying flat, and it rises faster than linearly unless something summarises between steps. A ten-step workflow does not cost ten times a one-step workflow.

The orchestrator's own accumulation. In multi-agent architectures the supervising agent accumulates context from every agent it supervises, which is both a cost and, as measured elsewhere, a capability problem: orchestrator steering accuracy falls sharply as agent count rises.

Human review. Almost every production agent has a person checking some proportion of its output. That person's time is the largest line item in many deployments and is almost never in the original business case, because the original business case assumed the agent would replace the person rather than requiring one.

Evaluation and monitoring. Scoring production traffic costs inference. Tracing costs storage. Both are ongoing and neither was in the pilot, where a developer watched the output by hand.

The pattern is that pilot economics and production economics are different problems. A pilot runs on the happy path, at low volume, watched by someone who is invested in it working. Production runs on the real distribution, at scale, watched by nobody in particular. Costs that were rounding errors in the first are the dominant term in the second.

The arithmetic that kills long workflows

One piece of the cost picture deserves its own treatment, because it is the calculation almost nobody performs before committing.

Suppose each step in an agent workflow succeeds 95% of the time. That sounds strong. It is roughly what a well-tuned single step achieves on a task it was designed for.

A three-step workflow completes end to end 86% of the time. A ten-step workflow completes 60% of the time. A twenty-step workflow completes 36% of the time, which means the majority of runs fail somewhere.

Every one of those failed runs consumed tokens up to its failure point. If the failure is uniformly distributed across steps, a twenty-step workflow at 95% per-step reliability spends roughly half its total inference budget on runs that produce nothing.

Two consequences follow. First, the cost per successful completion is substantially higher than the cost per run, and business cases are almost always written against the second. Second, reliability improvements compound in the same direction: moving from 95% to 98% per step takes a twenty-step workflow from 36% to 67% end-to-end, which is a far larger commercial change than the three-point improvement suggests.

This is also the argument for shorter workflows with checkpoints rather than long autonomous runs. A twenty-step workflow broken into four checkpointed segments of five steps each fails less expensively, because a failure discards five steps of work rather than nineteen.

Cause two: value that was never defined

Gartner's analyst put this bluntly: most agentic propositions lack significant value or return, current models do not have the maturity to autonomously achieve complex business goals over time, and many use cases positioned as agentic today do not require agentic implementations.

That last clause is the most important sentence in the entire prediction and it is the one that gets quoted least.

An agent is warranted when a task requires deciding what to do next based on what just happened, repeatedly, in a way that cannot be enumerated in advance. That is a narrower category than it sounds. A great deal of what gets built as an agent is:

A workflow with branches. If the path is knowable in advance, a state machine is cheaper, faster, deterministic, testable, and debuggable. Wrapping it in a model adds cost and non-determinism to something that had neither.

A single model call with tools. One model, a few tools, one context. This is not a multi-agent system and calling it one adds coordination overhead to a problem with no coordination.

A retrieval problem. The task is finding the right document and answering from it. That is a retrieval system, and framing it as an agent introduces autonomy the task does not need.

A chatbot. Which brings us to the vendor problem.

Agent washing

Gartner estimates that of the thousands of vendors marketing themselves as agentic AI companies, roughly 130 sell what they claim. The remainder are rebranding assistants, chatbots and scripted automation without the underlying capability.

This matters for the cancellation rate in a direct way. An organisation that buys a repackaged chatbot on the expectation of autonomous execution has bought a product that cannot do the thing the business case was written around. The project does not fail because agents do not work. It fails because the organisation did not buy one.

The practical detection method is unglamorous. Ask a vendor to walk through what happens when the system encounters a situation not covered by its configuration. A genuine agent decides. A repackaged chatbot escalates or fails, and the answer will change the subject to the model rather than describe the decision.

Cause three: controls that arrive after the incident

The third cause is the one that turns a disappointing project into a cancelled one, because it converts an underperforming system into a liability.

Agents act. That is the entire premise. Acting means credentials, tool access, and the ability to change state in systems that matter. The governance questions that follow are not exotic, and they are routinely deferred until after deployment:

Whose authority is the agent acting under? A service account with broad permissions is operationally convenient and means the agent can do anything that account can, regardless of who asked. Tying permissions to the requesting user is correct and considerably more work.

What happens on failure after side effects? An agent that fails at step seven has already taken actions at steps one through six. Some of those may be irreversible. This is a distributed-systems problem with a long literature, and agent frameworks largely do not address it.

Who notices? If the agent does something wrong and nobody detects it, the incident is only bounded by how long it goes unnoticed. Conventional monitoring will not catch it, because a wrong action and a right action both return successfully.

How fast can it be stopped? Rollback for an agent means both halting it and undoing what it did. Most deployments have the first and not the second.

A useful way to frame the whole category, borrowed from the deployment literature: there is a capability-deployment verification gap, where a pilot demonstrates that the system can do the task while nothing demonstrates that the organisation can operate it. The pilot answers a question about the model. Production asks a question about the institution.

The three questions

The most useful diagnostic in circulation is a short one, and it works because each question has an answer that either exists in writing or does not.

What is the written success metric, and who agreed to it? Not "improve efficiency". A number, a baseline, and a named person who accepted both. If the metric is written after deployment it will be written to describe whatever happened.

What data and tools does the agent need to reach, and does it have that access today? Not whether access is possible in principle. Whether it exists now, with the permissions scoped, in the environment where the agent will run. Integration with existing systems is the most consistently underestimated part of the work, and legacy data access is where pilots that worked in a clean environment die.

When it fails, who notices, who owns the outcome, and how fast can someone roll it back? Three parts, all required. Detection without ownership produces alerts nobody acts on. Ownership without rollback produces a person responsible for something they cannot stop.

If those answers do not exist before the project is funded, funding it anyway is the mechanism by which an organisation becomes part of the 40%.

What the surviving projects do differently

The evidence on what works is thinner than the evidence on what fails, which is normal and worth stating rather than papering over. What follows is the pattern visible in the deployment research, held loosely.

They start where the decision is required. The framing from Gartner's analyst is to use agents where decisions are needed, automation for routine workflows, and assistants for simple retrieval. Most organisations apply agents to all three and are surprised when two of them underperform a cheaper alternative.

They instrument before scaling rather than after. A system you cannot observe cannot be improved, and the point at which observability becomes mandatory is earlier than most teams assume. If you cannot say which component produced a wrong output, you cannot fix it, and you will be arguing about the model when the cause was an assembly bug.

They budget for the human. Not as a temporary measure during rollout, but as a standing cost. The deployments that survive are frequently the ones that never claimed the human would be removed.

They scope narrowly and expand. One workflow, fully instrumented, with a written metric and an owner. The organisations running ten simultaneous pilots are not learning ten times as fast; they are producing ten under-instrumented systems nobody owns.

They separate the pilot question from the production question. The pilot asks whether the capability exists. Production asks whether the organisation can operate it, at cost, with controls, under accountability. Passing the first tells you very little about the second, and treating a successful pilot as evidence of production readiness is the error that produces most of the 40%.

What is unresolved

Whether the 40% figure describes failure or normal attrition. A forecast that four in ten early-stage experiments will be cancelled is not obviously alarming. Most experiments should be cancelled; that is what an experiment is for. The number becomes concerning only if the cancellations cluster in projects that had a real use case and were killed by preventable execution problems rather than by learning something. The survey data does not currently distinguish these, and the distinction matters enormously for what conclusion to draw.

Whether model improvement dissolves the problem. Gartner's stated reason includes that current models lack the maturity to pursue complex goals over time. If that improves substantially, some share of the failures becomes retrospectively a timing problem rather than a governance one. Against that, the cost, value-definition and control failures are organisational and would persist against any model. The honest position is that better models would move some fraction of the 40% and nobody knows which fraction.

Whether the deployment gap is temporary. Every technology wave has a period where adoption outruns operational capability, and most close it. Whether agents close it faster or slower than previous waves is open, and the eighteen months following the surveys were named by the researchers themselves as the period that will determine it.

The counter-argument

Several things should be said against the framing above.

Gartner is a vendor of research and prediction, and dramatic predictions are commercially useful. The 40% figure has circulated far more widely than the methodology behind it, and a poll of organisations self-reporting on projects they are invested in is not a strong instrument. The finding is consistent with two independent studies, which strengthens it considerably, and it remains survey data about intentions rather than measured outcomes.

The failure rate may reflect healthy experimentation. Venture investment in this category surged 265% in a single quarter. A field attracting that much capital will produce a great many experiments, most of which should fail, and a low cancellation rate under those conditions would be more worrying than a high one.

Cancellation is not the only measure. A project cancelled after teaching an organisation what its data access actually looks like may have been worth its cost. The framing of cancellation as failure assumes the only value was the deliverable.

And the direction of travel is not in dispute. Gartner also forecasts that by 2028, 15% of day-to-day work decisions will be made autonomously, from approximately zero in 2024. Both things are true: most current projects will not survive, and the category is not going away. Treating the cancellation rate as evidence that agents do not work would be exactly the wrong lesson.

The short version

Gartner forecasts that over 40% of agentic AI projects will be cancelled by the end of 2027, from a poll of more than 3,400 organisations, citing escalating costs, unclear business value and inadequate risk controls. None of those three is a model capability problem. Two independent studies find the same pattern from different angles: 35% adoption within two years with most implementations in pilot purgatory, and 11% of organisations actually running agents in production against 79% reporting adoption.

Costs fail because pilot economics and production economics are different problems. The estimated cost is inference; the actual cost includes retries on failed runs, context growth through multi-step workflows, orchestrator accumulation, standing human review, and the evaluation and tracing that the pilot did without. Value fails because the business case was written for a system that was never bought or never needed: many use cases positioned as agentic do not require agentic implementations, and of thousands of vendors marketing agentic products, Gartner estimates around 130 sell one. Controls fail because agents act, acting requires credentials and produces side effects, and the questions about authority, rollback and detection are routinely deferred until after an incident.

The diagnostic that works is three questions asked before funding. What is the written success metric and who agreed to it. What data and tools does the agent need to reach, and does it have that access today. When it fails, who notices, who owns it, and how fast can it be stopped.

The framing worth keeping is that a pilot answers a question about the model and production asks a question about the institution. Passing the first tells you almost nothing about the second, and treating a successful pilot as evidence of production readiness is the mechanism that produces most of the 40%.

Common questions

Why do AI agent projects get cancelled? Gartner's poll of over 3,400 organisations attributes cancellations to three causes: escalating costs, unclear business value, and inadequate risk controls. None is a model capability failure. Costs escalate because production economics differ from pilot economics, with retries, context growth, human review and monitoring absent from the original estimate. Value is unclear because the use case frequently never required an agent. Controls are inadequate because governance questions about authority and rollback are deferred until after deployment.

What percentage of AI agent projects fail? Gartner forecasts over 40% cancelled by the end of 2027. Separately, Deloitte found 11% of organisations running agents in production against 79% reporting adoption, and MIT Sloan with BCG found most implementations stuck in pilot stage despite 35% adoption within two years. The figures measure different things, but all three describe the same gap between starting and finishing.

Is the 40% failure rate a technology problem? No, on the evidence. All three stated causes are management and governance failures. The most common underlying issue is that the use case did not require an agent: a workflow with knowable branches is better served by a state machine, a task needing one model and a few tools is not a multi-agent system, and a document-lookup problem is retrieval rather than autonomy. Better models would move some share of the failures and would not touch the cost, value-definition or control problems.

What is agent washing? Vendors rebranding assistants, chatbots and scripted automation as agentic products without the underlying capability. Gartner estimates that of the thousands of vendors marketing agentic AI, roughly 130 sell what they claim. The practical test is to ask what the system does when it encounters a situation not covered by its configuration: a genuine agent decides, a repackaged chatbot escalates or fails.

Why do agent costs exceed estimates? Because the estimate covers inference and inference is usually the smallest component. Failed runs consume tokens and produce nothing. Multi-step workflows carry accumulated context, so later steps cost more than earlier ones and total cost grows faster than linearly. Multi-agent orchestrators accumulate context from every agent they supervise. Human review is a standing cost that rarely appears in the original case. Evaluation and tracing are ongoing and were absent from the pilot, where a developer checked output by hand.

What should I ask before approving an agent project? Three questions, each with an answer that either exists in writing or does not. What is the written success metric, with a number and a baseline, and who agreed to it. What data and tools does the agent need to reach, and does that access exist today with permissions scoped in the environment where it will run. When it fails, who notices, who owns the outcome, and how fast can someone both stop it and undo what it did. If those answers do not exist before funding, funding it anyway is how projects join the 40%.

When does a task actually need an agent? When it requires deciding what to do next based on what just happened, repeatedly, in a way that cannot be enumerated in advance. That is narrower than common usage suggests. If the decision path is knowable ahead of time, a state machine is cheaper, faster, deterministic and testable. If one model with a few tools suffices, that is not a multi-agent system. If the task is finding the right document and answering from it, that is retrieval.

Does a successful pilot mean the project will work in production? It provides very little evidence either way. A pilot demonstrates that the capability exists, running on the common path, at low volume, watched by someone invested in its success. Production asks whether the organisation can operate the system at cost, with controls, under accountability, on the real input distribution, watched by nobody in particular. This is sometimes called the capability-deployment verification gap, and treating the first as evidence of the second is the most common route into the cancellation statistics.