Nadia runs operations at a mid-size distributor. (She isn't a real person. She is a composite of conversations I have had over the last two years, and her company is invented. Everything that happens to her has happened to someone.) In month one her agent pilot is the most exciting thing in the building. In month four the steering committee cancels it, and nobody in the room argues.
If you came here asking why AI agent projects fail, here is the short answer. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. Almost none of those causes are about the model. They are governance decisions that were never made: which process, how much autonomy, what budget, what record, who owns it, and when to stop. Make those six decisions in week one and most of the reasons to cancel disappear.
Key takeaways
- Gartner's three reasons for cancellation (cost, unclear value, weak risk controls) are all decisions someone could have made before the build, not discoveries made after it.
- Pilots usually die from a question nobody can answer: what did it cost, what did it do last Tuesday, and who authorised that write?
- Pick a boring, repetitive process with a checkable answer. The most visible process is usually the worst first pilot.
- Start the agent at L1 or L2 and measure agreement with your team per category. A single headline accuracy number hides the category that will hurt you.
- Write down the kill criterion before you start. It sounds pessimistic. It is the thing that makes the project defensible.
What did Gartner actually predict?
The source is a Gartner press release from 25 June 2025. The headline is the 40% figure. The more useful lines are further down.
Anushree Verma, a senior director analyst at Gartner, says most agentic AI projects are "early stage experiments or proof of concepts that are mostly driven by hype and are often misapplied", and that this can "blind organizations to the real cost and complexity of deploying AI agents at scale". Gartner also calls out "agent washing": vendors rebranding chatbots, RPA and AI assistants as agents. It estimates that only about 130 of the thousands of agentic AI vendors are real. And it says plainly that "many use cases positioned as agentic today don't require agentic implementations".
That last sentence is the part most coverage skips. Some of the 40% are not agent failures at all. They are projects where a rule, a script or a scheduled job would have done the work, and somebody bought an agent because agents were what the board wanted to hear about.
Nobody can measure cancellations precisely yet, but later surveys point the same way:
- LangChain's State of Agent Engineering report (1,340 responses, surveyed Nov–Dec 2025) found quality is the top barrier to production, cited by 32%. About 89% have observability for their agents, but only 52% run offline evaluations. Most teams can watch their agent. Far fewer can say whether it is right.
- The Cloud Security Alliance and Token Security found that 65% of organisations had an AI agent security incident in the past year, and 82% discovered an agent that security or IT did not know about.
- OneTrust's 2026 AI-Ready Governance Report found 87% of respondents say their organisation encourages agent use, while only 47% say that use is supported by clear governance, oversight and controls.
Put those together and you get Nadia's company: keen on agents, able to see a dashboard, unable to prove quality.
How does an agent pilot die in month four?
Nadia's pilot was an order desk agent. Customers email orders, amendments and complaints about short shipments. The agent reads the email, checks stock in the ERP, amends the order and, for short shipments, raises a credit note. It was chosen because it was the most visible process in the company. The CEO complains about the order desk every week.
The month-one demo was excellent. The agent read a messy email, found the right order and drafted a sensible amendment. Everyone clapped. Then three things happened.
The bill. Nobody had set a budget per run or per day. Long email threads went into the context in full, a few amendments looped through retries, and the monthly model invoice landed at several times the figure in the business case. Once a number surprises a CFO, every later number is assumed to be wrong too. (Gartner's "escalating costs".)
"What did it do last Tuesday?" A customer rang to say their order had been changed without asking. The account manager asked the obvious question: did the agent do this? Nobody could answer. The vendor dashboard kept chat transcripts for a week. The ERP showed the change against a shared service account. Nothing linked the email, the model's reasoning, the tool call and the record that changed. A system that cannot explain last Tuesday will not be trusted with next Tuesday. (Gartner's "inadequate risk controls".)
The finance lead who won't let it write. Raising credit notes was supposed to be the big saving. The finance lead, reasonably, asked three questions: who approves each credit note, what is the maximum it can raise, and where is the record? There were no answers, so write access stayed off. Without writes the agent was a drafting tool for the order desk, which was nice but not what the business case had promised. (Gartner's "unclear business value".)
In month four the steering committee looked at an unexpected cost, an unexplained incident and a saving that had not arrived, and stopped it. I think they were right to. Notice what was not on the list: the model. Every failure was a decision someone should have made in week one.
What are the governance decisions that keep a project alive?
Here is the list I would hand Nadia if she were starting again. None of it is exotic, and all of it is cheaper to decide before the build than to retrofit in month three.
1. Why should you pick a narrow, repetitive process instead of the most visible one?
The order desk was visible because it was messy, and messy is the worst place to start: "right" is hard to define.
A good first process has three properties. It runs often enough that a few weeks of data mean something. It has an answer two people would agree on most of the time. And getting one case wrong is annoying rather than expensive. Matching supplier invoices to purchase orders and goods received notes is a better first pilot than the order desk, even though no CEO has ever complained about it in a board meeting.
This is also where Gartner's warning about agent washing earns its keep. Before you build an agent, ask whether a rule would do. If the process is "if the invoice matches the PO within tolerance, approve it", you need a rule, not a model. Agents are worth their cost where the input is unstructured and the judgement is real but bounded.
2. Why start at L1 or L2 of the Autonomy Ladder?
At Devs Core we place every agent on a rung of the Autonomy Ladder: L0 Observe, L1 Propose, L2 Approve, L3 Sample, L4 Delegate. A new agent starts at L1 (it drafts, a person acts) or L2 (a named person approves each write). It moves up one rung only with evidence, and it can move down the same way.
The evidence that matters is agreement with your team, measured per category. Run the agent alongside the people who do the job today and compare their answers case by case. Then split the result by case type.
That chart is illustrative, not from a real project, but its shape is typical. The average looks healthy; the credit-note category, the one finance cares about, is well below it. A single accuracy number would have released both. Per category, you release the routine work and keep the risky work in the queue, which is exactly the conversation Nadia's finance lead wanted to have.
The rung is set per operation, not per agent. The same agent can answer stock questions unattended while every credit note still waits for a person. I have written more about building that queue in human-in-the-loop AI agents.
3. Why set budgets and caps from day one?
Because a cap turns a surprise into a decision. Set a budget per run, per day and per month before the first call, and make the system refuse work when it is spent rather than send an email afterwards. In our builds the budget is reserved before a model call is made, not counted up afterwards, so two parallel runs cannot both spend the last of it.
Track cost per completed case, not just per month. "This month cost more" is a complaint; "credit-note cases cost more because the threads are long" is something you can fix.
For the numbers themselves, see our guide to budgeting AI agent development, and for the mechanics of token budgets and rate limits at a gateway, How to Stop Runaway AI Agent Costs.
4. Why must the audit trail exist before go-live?
Because "what did it do last Tuesday?" will be asked, probably in the first month, and it has to be answerable from a record rather than from someone's memory.
The record needs to link the trigger (the email), what the model proposed, which rule allowed or blocked it, who approved it, what was written and the before and after values. It needs to outlive the vendor's seven-day retention. And it must not be editable by the system it is recording.
We got that last point wrong ourselves. In October 2026 we ran 12 independent tests against the governance of Ware, our simulated 3D warehouse with a real AI recovery agent. One finding was that the audit log could be edited or deleted without anyone noticing. It is now append-only and hash-chained, so any change breaks the chain. Another finding: an approval was checked in one transaction and executed in another without a second check, so a change in between went unseen. Neither showed up in a demo. The full results are on our AI governance page, and the sibling post on audit trails for AI agents covers the design.
5. Who is the named owner?
One person, by name, not a committee. They own the agent's rung, its budget and its kill criterion. They are the person the account manager calls when a customer says their order changed.
Nadia's pilot had a sponsor (the CEO), a builder (a vendor) and a lot of interested people. It had no owner, so when the bill arrived everyone assumed someone else had approved the spend.
6. What is a kill criterion, and why write it down first?
A kill criterion is the condition under which you stop, agreed before you start. It is the most underrated document in an AI project, because it protects the project as much as the budget.
Here is the shape of one. This is a template, not output from a tool:
pilot: supplier-invoice-matching
owner: Head of Finance Operations
starting_rung: L1 # agent proposes, a person posts
review_date: week 6
continue_if:
- agreement_rate >= 0.95 in at least two categories, measured on 4+ weeks of live cases
- cost_per_case <= the agreed ceiling
- every write traceable from trigger to record in the audit log
stop_if:
- any category below 0.80 after week 4 with no fix in sight
- spend cap hit twice in one month
- any write that cannot be explained from the log
With a written criterion, month four is a review, not an argument. Either the numbers clear the bar and the project moves up a rung, or you stop with a clear record of why. That is the cheap version of finding out, and very different from being cancelled by a committee that has lost confidence.
How does an Agent Pilot build these decisions in?
Our Agent Pilot is built around these six decisions, because we have seen what happens without them. One process, chosen and signed off in week one with the rules and the threshold for going unattended. Connectors with scoped permissions. Shadow mode first, where the agent produces an answer for every real case and writes nothing. Then a parallel run with a review queue on every write, and an agreement-rate report per category at the end. Cost per run is on a dashboard in your own accounts from the start. It runs four to six weeks from $6,500, and the source code is yours.
A pilot that ends with "stop, and here is why" is not a failure; you keep the connectors, the permission model and the report. If you are not sure which process to start with, the AI readiness audit ranks the candidates before anyone builds anything.
Nadia's agent read emails perfectly well. What killed it was a budget nobody set, a record nobody kept, an approval nobody designed and an owner nobody named. Can you name all six for your own pilot today?
Frequently asked questions
Why do agentic AI projects get cancelled?
Gartner gives three reasons: escalating costs, unclear business value and inadequate risk controls. In practice these show up as an unexpected model bill, an incident nobody can trace, and a finance or risk lead who will not allow the agent to write to live systems. Each is a governance decision that was not made early enough.
What percentage of agentic AI projects fail?
Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027. That is a prediction, not a measured failure rate. Later surveys, such as LangChain's State of Agent Engineering, report quality as the top barrier to production, cited by 32% of respondents.
How do you move an AI pilot to production?
Run the agent alongside your team on live data, measure agreement per case category, and release only the categories that clear a threshold set in advance. Keep a review queue for the rest, cap spending, and make every write traceable before anything goes unattended.
What is agent washing?
Gartner's term for vendors rebranding chatbots, RPA tools and AI assistants as agents without real agentic capability. Gartner estimates only about 130 of the thousands of agentic AI vendors are genuine.
What should a kill criterion for an AI pilot include?
The owner, the review date, the thresholds to continue (agreement rate per category, cost per case, traceability of every write) and the conditions to stop. Agree it before the build, so month four is a review against numbers rather than a debate about feelings.