Why Agentic AI Projects Get Cancelled

In June 2025, Gartner predicted that more than 40 per cent of agentic AI projects would be cancelled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. Fifteen months on, that forecast is being quoted again as pilots meet production.

My view is that most of those cancellations will trace back to one design error made before any model was chosen. Teams automate the process as documented. The process as practised contains variation that people handled without writing it down. When the agent replaces the people, that variation has nowhere to go.

This piece is for CTOs, enterprise architects and heads of AI who are funding or reviewing agent projects. It explains why pilots succeed and production fails, and gives two tests to run before the next budget is approved.

The short version

Agentic AI projects fail in production mainly because pilots cover the clean cases while real work is full of undocumented exceptions. Reliability across a multi-step agent multiplies, so small gaps compound. Measure how much real volume the design covers, and check for any zero in readiness, before building.

• Treat the Gartner forecast as a design warning, not a market statistic.
• Sample real transactions before you specify an agent.
• Assume people were absorbing exceptions nobody documented.
• Multiply step reliability, do not average it.
• Refuse to fund agents with a zero on any readiness factor.
• Name who owns the business outcome before approving spend.

This article sits inside the ai and enterprise solutions architecture cluster, where the wider argument is set out in full.

What Gartner actually said

The Gartner forecast was published on 25 June 2025. It gave three reasons for cancellation: escalating costs, unclear business value and inadequate risk controls. Gartner also warned about "agent washing", the relabelling of chatbots and automation tools as agents, and estimated that only about 130 of the thousands of vendors claiming agentic capability were real.

It is worth being precise about what this is. It is a prediction made in mid-2025, not a measured failure rate. Its usefulness is in the reasons, and all three point to the same place. Costs escalate when exceptions appear that nobody planned for. Value becomes unclear when the agent handles less work than promised. Risk controls fail when the agent meets situations nobody specified.

Humans were the loop

The phrase "human in the loop" suggests a person checking an otherwise automated process. In most enterprise processes, that picture is wrong. People were not checking the loop. They were the loop.

A clerk who notices that a supplier always sends invoices with the wrong tax code, and fixes it without comment, is absorbing variation. So is a collections agent who recognises distress in a borrower's voice, or a store manager who knows which delivery always arrives short. None of that appears in the process document the agent was built from.

A copilot keeps those people in place, so the buffer survives. An autonomous agent removes them, and every undocumented exception they handled becomes either an error or a manual queue. That is where the cost and the risk in Gartner's reasons come from.

Should your organisation do this now?

• Yes, if your agent specification was written from process documents alone.
• Not yet, if you have no way to sample real transactions.
• Instead, first: sit with the people doing the work and log exceptions for two weeks.
• Measure it by: number of exception types found that the specification missed.

Reliability multiplies

The second reason pilots mislead is arithmetic. A multi-step agent succeeds only if every step succeeds. Reliability across the chain is the product of the step reliabilities, a principle engineers know as Lusser's law.

Illustrative scenario. An agent completes a ten-step task. Each step works 95 per cent of the time, which sounds good in a demo. Multiply 0.95 by itself ten times and the whole task succeeds only about 60 per cent of the time. Four in ten runs need a person.

The same arithmetic explains why adding steps to "make the agent smarter" often makes it less dependable, and why shortening chains is one of the most effective design changes available. Before approving a design, ask for the number of steps and a measured success rate for each.

Should your organisation do this now?

• Yes, if your agent chains more than a handful of tool calls or decisions.
• Not yet, if you cannot measure success per step.
• Instead, first: instrument each step and log outcomes.
• Measure it by: end-to-end task success rate on real volume.

Measure coverage before you build

The first test I would run is simple to describe and uncomfortable to perform.

The Variant Coverage Ratio is the share of a process's actual transaction volume covered by the paths an automation has been explicitly specified to handle:

[Variant Coverage Ratio](/frameworks/variant-coverage-ratio) = specified path volume ÷ total process volume

Take a random sample of real transactions, not the tidy examples from the pilot. Classify each by the path it actually followed. Count how many follow paths the agent is designed for. That ratio, not the pilot success rate, is the realistic ceiling on what the agent can do alone.

A low ratio is not a reason to cancel. It is a reason to choose a copilot first, or to specify more paths before going autonomous.

Look for zeros before funding

The second test is the four-factor readiness check:

[Autonomy Readiness](/frameworks/autonomy-readiness) = Specification × Exception Coverage × Observability × Reversibility

The multiplication matters. A strong score on three factors does not rescue a zero on the fourth. A process with no way to undo a wrong action, or no way to see what the agent did, is not partly ready for autonomy. It is not ready.

In practice, I would ask four questions at the funding meeting:

• Specification. Are the rules written precisely enough for a machine to follow?
• Exception coverage. Which exceptions are detected and routed, and what share of volume do they represent?
• Observability. Can we see every action the agent took and why, after the fact?
• Reversibility. If the agent is wrong, how do we undo it, and how fast?

Then one more, which matters as much as the four: who owns the business outcome of this agent, and who will prove it to the board?

Should your organisation do this now?

• Yes, if any active agent project cannot answer all four questions.
• Not yet, if the project is still a design exploration with no production intent.
• Instead, first: score the process and publish the weakest factor.
• Measure it by: number of funded agents with no factor scored zero.

Before you approve it

Checklist:

• Real transaction sample collected and classified.
• Variant Coverage Ratio calculated on that sample.
• Readiness scored on all four factors, with no zero.
• Step-level success rates measured and multiplied.
• Named business owner accountable for the outcome.
• Cost model that includes exception handling, not only model usage.
• Decision on copilot versus autonomy recorded with reasons.

Questions to ask:

• Your team: what share of real transactions does the agent's design cover?
• Your team: which exceptions did the people doing this work handle that we did not specify?
• Your vendor: what is the measured success rate per step on our data?
• Your vendor: what does the product do when it leaves a specified path?
• Your CFO: does the business case include the cost of manual exception queues?
• Your board: whose number moves if this works, and who reports it?

How to measure it

• Variant Coverage Ratio. Share of real volume the agent is designed to handle. Baseline: pre-build sample. Owner: process owner. Review: monthly. Leading.
• End-to-end success rate. Share of tasks completed without human help. Baseline: pilot on real sample. Owner: AI product lead. Review: weekly. Leading.
• Exception queue volume. Items routed to people per thousand transactions. Baseline: pre-automation exception log. Owner: operations lead. Review: weekly. Leading.
• Cost per completed task. Total cost including human handling. Baseline: current process cost. Owner: finance partner. Review: monthly. Lagging.
• Undo incidents. Actions that had to be reversed. Baseline: pilot. Owner: risk lead. Review: monthly. Lagging.
• Business outcome metric. The number the business case promised. Baseline: before launch. Owner: named business owner. Review: quarterly. Lagging.

Mistakes that cost the most

Specifying from documents

The documented process is rarely the real one.

• Why it happens: documents are faster than observation.
• Prevention: observe the work and sample real transactions.
• Early warning: frequent "edge cases" in the first production week.

Averaging reliability

Averages hide how failures compound across steps.

• Why it happens: demos report overall impressions, not step metrics.
• Prevention: multiply measured step success rates.
• Early warning: good demos, poor production completion.

Funding on pilot success

Pilots use clean data and friendly cases.

• Why it happens: pilots are designed to show promise.
• Prevention: evaluate on a random sample of real volume.
• Early warning: production volume far below the business case.

Ignoring the cost of exceptions

Exception queues need people, tools and time.

• Why it happens: business cases count model costs only.
• Prevention: cost the exception path explicitly.
• Early warning: new headcount requests for "AI operations".

No business owner

Technology teams cannot prove business value alone.

• Why it happens: AI projects start in IT or innovation teams.
• Prevention: name the owner before funding.
• Early warning: success reported in model metrics only.

Frequently asked questions

What did Gartner predict about agentic AI?

In June 2025, Gartner predicted that over 40 per cent of agentic AI projects would be cancelled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.

What is agent washing?

Gartner's term for rebranding existing products, such as assistants, chatbots or robotic process automation, as agents without substantial agentic capability. Gartner estimated only about 130 of thousands of vendors were real.

Why do AI agents work in pilots but fail in production?

Pilots usually cover clean, common cases. Production contains undocumented exceptions that people handled informally. When the agent meets them, it fails or sends work to a manual queue.

What is Lusser's law?

A reliability principle stating that the reliability of a chain equals the product of its links' reliabilities. For AI agents, small failure rates per step compound into large failure rates per task.

What is the Variant Coverage Ratio?

The share of a process's actual transaction volume covered by the paths an automation has been explicitly specified to handle. It shows how much real work an agent can do alone.

What is Autonomy Readiness?

A four-factor test, Specification × Exception Coverage × Observability × Reversibility, for whether a process can run safely without a human. A zero on any factor makes autonomy unsafe.

Should we start with a copilot instead of an agent?

Where coverage is low or reversibility is poor, yes. A copilot keeps people handling exceptions while producing the data needed to decide on autonomy later.

How do we reduce the risk of cancellation?

Sample real work before specifying, shorten step chains, cost the exception path, check readiness for zeros, and name a business owner who is accountable for the outcome.

What to do next

Before the next agent budget meeting, calculate the Variant Coverage Ratio on a real sample and publish the weakest readiness factor. Then read the Autonomy Readiness framework, and see how the same test applies in lending in AI in collections after RBI's 2027 rules.

Sources

• Gartner, Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027, 25 June 2025. gartner.com
• Forbes, Why 40% of agentic AI projects may be canceled by 2027, 7 July 2026. forbes.com

Last reviewed: 15 September 2026.

Views are my own and do not represent my employer.