Gartner predicts 40% of agentic AI projects will be cancelled by 2027. Here are the six failure patterns behind that number, the Klarna lesson, and a checklist to keep your project out of the statistic.
Here is the most useful statistic in the AI industry, and it is not a success story.
Gartner predicts that 40% of agentic AI projects will be cancelled by the end of 2027, citing unclear ROI, poor governance and rushed implementation. Two in five. Serious money, serious teams, serious intentions, cancelled.
Most vendors would rather you did not dwell on that number. We think you should stare at it, because buried inside it is the cheapest education available in AI: every one of those failures follows a small set of recognisable patterns, and every pattern is avoidable at the planning stage, which is the cheapest place to avoid anything.
We have watched these patterns up close, in projects we rescued and, honestly, in early mistakes of our own. Here are the six that account for most of the graveyard, the famous case study that teaches the biggest lesson, and the checklist that keeps you out of the 40%.
First, Why Failure Is This Common
A fair question: if the technology works, why do so many projects die?
Because agentic AI fails differently from normal software. When a workflow automation breaks, it breaks loudly: an error, a halted run, an alert email. When an AI agent fails, it often fails politely and plausibly, producing output that looks right but is not. That single property, plausible failure, sits underneath most of the patterns below. Projects do not usually die in a dramatic crash. They die from a slow leak of trust: a wrong answer here, an odd action there, a manager who quietly goes back to doing it manually, and six months later someone cancels the line item.
The good news hiding in that: failure is rarely about the model. It is about the scaffolding humans did or did not build around it. Scaffolding is fixable.
The Six Failure Patterns
Pattern 1: No baseline, so ROI could never be proven
The most common killer is also the most boring. Teams automate a process without ever measuring what it cost before: how many hours, how many errors, how long customers waited. Twelve months later the CFO asks what the agent achieved, and the honest answer is "we think it helps?" Projects that cannot prove value get cancelled in budget season regardless of whether they were working.
The fix: measure before you build. Two weeks of counting (task volumes, minutes per task, error rates, response times) turns "we think" into "it saved 240 hours a month." Our ROI guide shows exactly which four numbers to capture and how to run the maths a CFO will accept.
Pattern 2: A fuzzy goal instead of a narrow job
"Make an agent that handles customer service" is a wish, not a specification. Agents thrive on narrow, well-bounded workflows: "process return requests under $200 against this policy, escalate everything else." Point an agent at a broad fuzzy goal and it will do something broad and fuzzy with it, and the first embarrassing transcript kills executive confidence.
The fix: scope like you are writing a job description for a very literal new hire. One process, clear inputs, clear outputs, written boundaries, named exceptions. If you cannot describe the task on one page, it is not one task; split it.
Pattern 3: Governance bolted on after launch
Post-mortems of cancelled projects keep finding the same sequence: build fast, demo well, launch, and then discover nobody defined what the agent may touch, who approves risky actions, or how anyone audits what it did. The first incident (a wrong refund, an email to the wrong list) triggers a compliance review the project was never designed to pass, and the review kills it.
The fix: guardrails are part of the build, not the sequel. Least-privilege access, approval gates for high-stakes actions, and an audit trail from day one. This deserves its own article, and it has one: AI Agent Governance.
Pattern 4: Nobody watching the quality
Deterministic software needs uptime monitoring; agents need quality monitoring, because "up" and "correct" are different claims. Teams that only watch uptime discover quality drift months late, through customer complaints, which is the most expensive monitoring system ever invented.
The fix: review transcripts and outcomes weekly, especially in the first quarter. Track a small quality score (answers correct, actions appropriate, escalations sensible) alongside cost per task. Boring, weekly, non-negotiable.
Pattern 5: The data was a mess and the agent learned the mess
An agent grounded in a decade of inconsistent, outdated, duplicated documents will faithfully reproduce the inconsistency at scale. Data preparation is not glamorous, which is why it gets skipped, and cleaning and structuring data typically accounts for 20 to 30% of total AI project cost when done properly.
The fix: fix the handbook before you feed it to anything. Current policies, one version of each document, tribal knowledge written down. Every hour spent here saves ten arguing with confident wrong answers later.
Pattern 6: Humans removed too early
The final pattern is the most human one: the pilot works, enthusiasm surges, and the humans get pulled out entirely to maximise the savings line. Then the edge cases arrive, there is no escalation path, customers notice, and the backlash forces a retreat that discredits the whole programme.
Which brings us to the most instructive case study in the industry.
The Klarna Lesson: Triumph, Walk-Back, and the Real Moral
Klarna's AI assistant became the poster child of agentic AI, reportedly doing the work of around 850 agents with roughly $60M in annual savings by late 2025. Then came the sequel: in May 2025, Klarna began rehiring human agents after customers pushed back on generic answers and poorly handled edge cases, with the CEO admitting the company had cut too far.
The lazy reading is "AI failed." It did not: Klarna kept the AI and rebalanced. The accurate reading is that fully removing humans from judgment-heavy, brand-sensitive work was a step too far, even for a company with world-class engineering. The durable pattern, the one showing up in every successful deployment, is hybrid: agents handle the volume, humans handle the exceptions, and the escalation path between them is designed, not improvised.
Contrast the quiet counter-example: Morgan Stanley's internal code-modernisation agent reviewed over 9 million lines of legacy code and saved an estimated 280,000 developer hours. Internal, unglamorous, high-volume, no customers in the blast radius. That profile, boring and bounded, is where agents shine earliest. The pattern across verified successes is remarkably consistent: customer service automation, contract review, supply chain, code modernisation and fraud detection, each high-volume, measurable, with clear escalation paths, and each started narrow.
How Does Failure Compare Across Project Types?
Not all AI projects carry equal risk, and knowing where yours sits on the ladder is itself protective.
Lowest risk: internal, informational. A grounded assistant answering staff questions from your documents. Mistakes land on colleagues who can spot them. Almost impossible to fail catastrophically; the main risk is quiet abandonment if answers are mediocre (fix: pattern 5).
Medium risk: internal, acting. An agent updating your CRM or processing internal documents. Wrong actions are recoverable but erode trust. Governance and monitoring carry the weight here.
Highest risk: external, acting. Agents touching customers and money: refunds, emails at scale, bookings. Every failure pattern applies simultaneously, which is why these should never be first projects, however tempting the savings look. Earn the trust rungs in order.
A one-line rule that would prevent a remarkable share of the 40%: your first agent should be boring, internal, and measured.
What Do the Survivors Have in Common?
Flip the statistic: 60% of projects make it, and the survivors are strikingly similar. Four traits keep appearing in the post-implementation reviews.
They started embarrassingly small. The successful support agent began as "answer questions about our returns policy," not "handle customer service." Small scopes produce fast feedback, fast fixes, and early wins that buy political capital for expansion. The failed projects mostly tried to boil the ocean in month one.
They kept a human owner, not just a vendor. Every surviving project we have seen had a named internal person who read the transcripts, knew the numbers, and cared whether it worked. Projects owned by "the agency" or "IT generally" drift, because nobody notices the slow leak of trust until budget season.
They celebrated escalations. Failing teams treat every hand-off to a human as the agent falling short, and quietly pressure it (or its builders) to guess more. Surviving teams treat a sensible escalation as the system working exactly as designed. That single cultural difference decides whether edge cases become incidents.
They reported numbers nobody could argue with. Baseline versus actual, monthly, in hours and pounds. When the renewal conversation came, the surviving projects had a one-page answer ready. Provable value is cancellation-proof value.
None of these traits require enterprise budgets. They require the same discipline as any good hire: clear job description, a manager who pays attention, permission to ask questions, and a performance review with real numbers.
The Keep-Out-of-the-40% Checklist
Run this before signing anything, whether building in-house or hiring a partner. (For Further reading)
Before the build:
- Baseline measured: hours, volumes, error rates, response times for the target process
- One narrow process scoped on one page, with boundaries and named exceptions
- Success defined numerically ("deflect 60% of standard requests within 3 months"), with a kill/fix threshold agreed
- Documents and data for the process cleaned and current
- Risk tier identified (internal/informational → external/acting), and matched to your organisation's first-project appetite
In the build contract:
- Least-privilege access per system, written down
- Approval gates for money, contracts, and customer-facing sends
- Audit trail: every action logged, reviewable, attributable
- Quality monitoring included, not just uptime
- Documentation good enough for a different developer to take over
- Maintenance plan with a named owner ("what does month thirteen look like?")
After launch:
- Weekly transcript and outcome reviews for the first quarter
- Humans kept in the loop for exceptions, with a designed escalation path
- Baseline vs actual reported monthly, in CFO-readable numbers
- Expansion only after the first process hits its success number
Sceptics sometimes read this list as overhead. It is the opposite: it is the difference between the 60% and the 40%, and almost every item is cheaper than the failure it prevents.
Frequently Asked Questions
-
Rarely because of the AI model. The recurring causes are organisational: no baseline measurement (so ROI can never be proven), fuzzy goals instead of narrow scopes, governance bolted on after launch, no quality monitoring, messy source data, and removing humans from the loop too early. All six are avoidable at planning stage.
-
No, it is a reason to plan. The same market shows [median ROI around 300% over three years](https://kwestra.com/insights/ai-automation-roi) for well-executed automation, and the winners and casualties are separated by process, not luck. Waiting has its own cost; planning is nearly free.
-
Boring, internal, bounded and measured: a grounded assistant for staff questions, document processing, or internal triage. High volume, low blast radius, clear numbers. External customer-facing agents that move money should be earned, not started with.
-
For a well-scoped first automation, a working version in one to two months and measurable results within a quarter. Benchmarks show [payback of 3 to 6 months for focused workflow automations and 12 to 24 months for enterprise-wide agentic rollouts](https://automationatlas.io/answers/how-to-calculate-automation-roi/). Anything promising transformation in a fortnight is selling, not planning.
-
Klarna's assistant reportedly replaced the work of ~850 support agents and saved ~$60M annually, then the company rehired humans in 2025 after customers rejected generic answers on edge cases. Klarna kept the AI and rebalanced to a hybrid model. Lesson: agents for volume, humans for judgment-heavy exceptions, escalation paths designed from day one.
-
Often, yes, because the failures are usually scaffolding, not model quality. The typical rescue: re-scope to one narrow process, install a baseline retroactively, add guardrails and monitoring, and re-launch with humans in the loop. It is cheaper than starting over and much cheaper than the reputational cost of a public cancellation.
The Takeaway
The 40% is not a verdict on the technology. It is a verdict on skipped homework: unmeasured baselines, fuzzy scopes, absent guardrails, unwatched quality, messy data, and humans removed a step too early.
Which is oddly comforting, because homework is entirely within your control. Measure first, scope narrow, govern from day one, watch quality weekly, clean the data, and keep humans where judgment lives. Do those six things and the scariest statistic in AI quietly stops applying to you.
Bots and Brand Works has rescued enough AI projects to recognise failure patterns by their early symptoms. If you are planning an automation, or watching one wobble, send us the one-page scope (or the wobble), and we will give you an honest read before it becomes a statistic.
Need Help Implementing AI?