Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. A separate Gartner projection is that by 2027, 40% of enterprises will demote or decommission autonomous agents after a governance gap surfaces following a production incident.
We build these systems. Publishing the failure data is not against our interest — it is the most useful thing we can tell you, because the failures are consistent, well understood and largely preventable.
Almost none of them are the model’s fault.
The seven failure modes
1. The objective was never measurable
What it looks like: the project was “explore AI” or “we need an AI strategy”. Six months later nobody can say whether it worked, so it gets cut in the next budget round.
Why it happens: AI projects are frequently commissioned for board-level reasons rather than operational ones. The sponsor wants to be doing AI. That is a real motivation and a poor specification.
How to avoid it: before anything is built, write one sentence with a number in it. “Invoice processing drops from 40 minutes to under 5, with an exception rate below 10%.” If you cannot write that sentence, you are not ready to build.
2. Costs scaled invisibly
What it looks like: the pilot cost £80 a month. At full volume the bill is £2,400 a month and nobody budgeted for it.
Why it happens: every step an agent takes is a paid model call. A task needing eight steps costs eight calls. Add a retry loop and it is twenty-four. Pilots run on small volumes and short tasks; production runs on neither.
How to avoid it: model the per-task cost before building, multiply by realistic volume, and add a margin for retries. Insist on hard step limits and spend caps in the system itself. Ask any supplier for the expected monthly run cost in writing — if they have not calculated it, they have not finished designing.
3. Governance arrived after the incident
This is the specific failure Gartner projects will cause 40% of enterprises to decommission agents by 2027.
What it looks like: the agent does something nobody anticipated. There is no audit log showing why. There is no clear boundary it violated, because no boundaries were written down. The organisation’s response is to switch it off entirely, because partial trust is harder to justify than none.
How to avoid it: audit logging of every action from day one, explicit written authority boundaries, a kill switch a non-technical person can operate, and a named owner. All of this is cheap before launch and impossible to retrofit after an incident.
4. The data was not ready
Gartner expects 60% of AI projects unsupported by AI-ready data to be abandoned through 2026.
What it looks like: the agent works perfectly on the test set and produces confident nonsense in production, because the real data has duplicates, contradictions and fields used for three different purposes.
How to avoid it: run feasibility on your real data, including the messy parts, before committing to a build. If the data needs fixing, that is a separate project and it comes first. An agent reading bad data produces wrong answers faster than a person would.
5. The pilot could never have become production
What it looks like: an impressive demo. No error handling, no logging, no retry logic, no escalation path, no monitoring. It works until the first real edge case and then fails in a way nobody can diagnose.
Why it happens: demos are built to persuade and production systems are built to survive. These are different jobs and the first does not become the second by extension.
How to avoid it: decide upfront whether you are buying a proof of concept or a production system, and price accordingly. A feasibility sprint should end in a measured accuracy number and a go/no-go — not a demo that creates an expectation it cannot meet.
6. It was an automation problem all along
What it looks like: significant money spent on an agentic system for a process that never actually varies. It works, it costs more than it should, and it is less reliable than the deterministic version would have been.
Why it happens: agents are what people want to buy right now, and suppliers sell what people want to buy.
How to avoid it: apply the flowchart test. If you can draw the process as a flowchart that never changes, build the flowchart. It will be cheaper, faster and more reliable. Agents earn their cost only when the route to the goal genuinely varies.
7. Nobody owned it
What it looks like: it launches, works, and degrades quietly over six months as models update and your data shifts. One day someone notices the exception rate has tripled. By then nobody remembers how it was configured.
How to avoid it: name an owner before launch. Keep an evaluation suite and re-run it on a schedule. Treat accuracy as a number that gets reported, not an impression.
The pattern
Read those seven again. Six are commissioning and management failures. One — data readiness — is a prerequisite problem.
None of them is “the AI was not good enough.”
That is the genuinely useful finding. The technology is mostly adequate for the tasks businesses point it at. The failure rate comes from how projects are specified, measured and governed.
Which means it is controllable.
Five things to get right before you build
Settle these and the failure modes above mostly disappear.
Decide where the human stays in the loop. For decisions requiring formal justification to a regulator or auditor, design the agent to do the work and surface a recommendation, with a person making the call. You get the throughput without the compliance exposure.
Set the confidence threshold deliberately. Payments, clinical data and anything irreversible need uncertain cases routed to a human automatically. That is a design decision, not a limitation — it is how you capture the saving on the 95% without carrying risk on the rest.
Get the data ready first. Worth doing in its own right, and it has standalone value whether or not the agent follows.
Check the volume. Count the annual hours before quoting. High-volume document and exception handling is where agents repay fastest, and the payback is usually quicker than people expect.
Name the owner. One person accountable, with the evaluation suite handed over so the system keeps performing rather than drifting.
The failure nobody describes: it worked and nobody used it
A category missing from most analyses because it does not look like a technical failure at all.
What happens: the agent performs well. Accuracy is good, the cost model holds, governance is in place. Six months later, usage is a fraction of forecast, because the people whose work it was supposed to change route around it.
Why:
They were not consulted. The process was described by a manager and built to that description. The people performing it know fifteen things that were never written down, and the agent handles none of them.
It broke once, early. Confidence in an automated system is asymmetric — one visible error early costs more trust than fifty correct outcomes rebuild. This is why shadow running matters: errors found there cost nothing in trust.
The escalation path was worse than doing it manually. If handling an exception takes longer than processing the whole thing by hand, people stop sending work to the agent.
Nobody told them what it was for. In the absence of an explanation, an unannounced automation project reads as a redundancy exercise, and cooperation evaporates.
How to avoid it: involve the operators from feasibility onward, run shadow mode long enough that the first real errors happen with no consequences, make the exception path genuinely fast, and say plainly what the system is for and what it means for people’s jobs.
What a well-governed agent has
A checklist you can hold any supplier to:
- A written objective with a number in it
- Measured accuracy on real data, before build
- An expected monthly run cost, in writing
- Hard step limits and spend caps in the code
- Audit logging of every action taken
- Explicit authority boundaries — what it may never do
- Confidence thresholds routing uncertain cases to a human
- A kill switch a non-technical person can operate
- A shadow-running period before it has authority
- An evaluation suite, re-run on a schedule
- A named owner
- Documentation and source code you hold
Any supplier who cannot speak to most of these has not built a production agent before.
The warning signs, by project week
Most of these are visible well before the money is gone.
Weeks 1–2 — during scoping
- Nobody can state the objective with a number in it
- The supplier has not asked to see your real data
- There is no expected monthly run cost in the proposal
- The proposal is mostly about the model and light on integration, evaluation and governance
Weeks 3–6 — during build
- The demo runs on examples someone selected
- Accuracy is described as “good” rather than measured
- No audit logging in the design
- Scope has grown twice already
Weeks 7–10 — approaching launch
- No shadow-running period in the plan
- No kill switch, or one only a developer can operate
- No named owner on your side
- Nobody has agreed what exception rate is acceptable
After launch
- Nobody is looking at the exception rate weekly
- The monthly model bill is larger than forecast and nobody has investigated
- There is no evaluation suite to re-run
- The person who understood the configuration has moved on
Three or more at any stage warrants a conversation. These compound, and the cost of addressing them rises sharply once the system has authority.
Recovering a failing agent project
Stop expanding scope immediately. The instinct when something underperforms is to add capability. It makes diagnosis harder and the problem worse.
Measure properly, against a baseline. Most projects judged as failing have never been compared with the humans doing the work. Teams routinely make errors at rates that surprise them. An agent at 92% against a human baseline of 94% is a tuning problem, not a failure.
Narrow it. Take the agent back to the subset of cases it handles well, let it run there, and escalate everything else. A system handling 60% of volume reliably is worth considerably more than one attempting 100% unreliably.
Check the data, not the model. Where accuracy is poor, the input is the cause far more often than the model is. Inconsistent records, contradictory sources, fields used for several purposes.
Add the governance you skipped. Audit logging and boundaries are retrofittable with effort — and without them, one surprising action ends the project regardless of how well it performs the rest of the time.
Re-run the arithmetic. Sometimes the honest answer is that the volume never justified it. Finding that out and stopping is a better outcome than continuing to spend.
How to read a proposal for these risks
Six things to look for in writing, before signing.
A measurable objective with a number in it. If the proposal describes capability rather than outcome, nobody will be able to judge the result.
Feasibility on your real data, as a separate priced stage. Its absence means the first time anyone sees your actual records is after you have committed to a build.
An expected monthly run cost, with the calculation. Steps per task × cost per step × retry factor × volume. If this is missing, ask. If it cannot be produced, the design is not finished.
Governance named explicitly — audit logging, authority boundaries, confidence thresholds, kill switch. These should appear as deliverables, not as reassurances in a meeting.
A shadow-running period in the plan. Its absence is the clearest signal that what is being proposed is a demo that will be promoted to production.
An evaluation suite you keep. The test set and measurement harness are the most durable thing the project produces, and they should be yours.
A proposal weighted toward the model and light on integration, evaluation and governance is a proposal for a prototype. Prototypes do not become production systems by extension — they get rebuilt, and you pay twice.
Frequently asked questions
Why do agentic AI projects fail?
Overwhelmingly for non-technical reasons: no measurable objective, costs that scaled invisibly, governance added after an incident, data that was not ready, pilots that could never become production, automation problems dressed as agent problems, and no named owner.
What percentage of AI agent projects fail?
Gartner expects over 40% of agentic AI projects to be cancelled by end of 2027. Other figures circulate — MIT found most generative AI pilots showed no six-month P&L return; RAND reports over 80% of AI projects fail to deliver intended business value. These measure different things and are not directly comparable.
Is agentic AI safe for business use?
With governance, yes. Without it, the risk is that the agent takes an action nobody sanctioned and nobody can reconstruct. The controls — audit logs, authority boundaries, confidence thresholds, kill switch — are cheap before launch and cannot be retrofitted after an incident.
How do I know if my process suits an agent or simple automation?
If you can draw it as a flowchart that never changes, use automation. Agents are worth their cost only when the route to the goal genuinely varies — different formats, different exceptions, different paths to the same outcome.
What is the biggest hidden cost?
Model usage. Every step is a paid call, retries multiply it, and pilots run at volumes that hide it. Get the expected monthly run cost in writing before committing.
Can we start small?
Yes, and you should. A two-to-three week feasibility sprint on your real data costs £6,000–£12,000 and ends in a measured accuracy figure and a go/no-go decision. That is a far cheaper way to discover a project will not work than a build.
Written by Jas Singh, Founder. Last updated 8 October 2026.
Figures from Gartner forecasts on agentic AI project cancellation, agent decommissioning after governance gaps, and AI projects unsupported by AI-ready data; MIT Project NANDA (August 2025); RAND on AI project outcomes. Reported via secondary sources and cited as directional — they measure different things and are not interchangeable.
