Why 40% of Agentic AI Projects Get Canceled, and What the Survivors Did Differently

Gartner's number is that more than 40% of agentic AI projects will be canceled by the end of 2027, for escalating costs, unclear business value, or inadequate risk controls. That prediction is now a year old and, from where I sit, looks conservative.

What I find more interesting than the number is how predictable the individual deaths are. I have been in the room for a handful of these, some as the vendor, some cleaning up after one. The postmortems are remarkably similar, and almost none of them are about the model being bad at its job.

Nobody wrote down the number

This is the big one. It accounts for more cancellations than everything else combined.

A project starts because agentic AI is on the roadmap. Somebody picks a process that seems automatable. A team builds something. Six months later a VP asks what it saved, and the honest answer is that nobody measured what it cost before, so nobody can say.

At that point the project does not get defended, because there is nothing to defend it with. It gets quietly descoped in the next planning cycle and the engineers move to something else.

The fix is genuinely a single afternoon of work, done before any building starts. Pick the process. Measure how many times it happens per month, how long each instance takes, who does it, and what a mistake costs when it happens. Write those four numbers on a page. That page is the entire business case, and it is also the thing that will save the project when the budget conversation comes.

I have started refusing to scope agent work without it. Not out of principle. Because the projects without it get canceled and I would rather not spend six months on something that dies.

The second-order benefit is that the exercise kills bad ideas early. About a third of the time, doing the arithmetic reveals the process happens forty times a month and takes eight minutes. That is five hours a month. No agent is worth five hours a month, and finding that out in an afternoon is a win.

The pilot ran on the good data

Here is a pattern I see so often it is almost a rule. The pilot is built against a curated sample: fifty clean invoices, a hundred well-formed tickets, documents somebody already checked. It hits 94% accuracy. Everyone is thrilled.

Then it meets the real queue, where 20% of the inputs are scanned at an angle, half the tickets are three unrelated questions in one message, and there is a category of edge case that the business handles by walking over to Priya's desk and asking her.

Accuracy drops to 60-something. Trust collapses immediately, and trust is much harder to rebuild than accuracy. The project does not usually get canceled at that moment. It goes into a long remediation phase, burns another quarter, and gets canceled later with more money spent.

Run the pilot on the ugly queue. Take a genuinely random sample from the last month, including everything that was escalated, and build against that. Your day-one number will be embarrassing and that is exactly the point, because you will spend your effort on the failure modes that matter instead of polishing the happy path.

The cost model was per-request and the workload was per-task

Agent economics do not behave like API economics, and a lot of budgets get set by someone who has only ever priced a chat feature.

A single agent run is not one call. It is a loop, and the loop re-sends accumulated context on every iteration. Then failures happen and runs restart, so you pay for the same task more than once. Then the model gets more capable, the team gives the agent longer tasks, and the token count per task grows even though the per-token price fell.

The number that matters is cost per completed task, including the failed attempts that preceded the success. Teams that track cost per API call get a nasty surprise around month three, and cost surprises are one of the three reasons Gartner lists.

None of this makes agents expensive in absolute terms. It makes them expensive relative to a forecast built on the wrong unit. The projects that die from cost are usually the ones where finance was told a number that was wrong by a factor of five, which destroys credibility even if the real number is still good.

It automated a process that had no owner

Cross-functional processes are the most tempting agent targets and the most dangerous. They are painful precisely because they span teams, which is also why they have no single owner, which is why nobody will fight for the project when it needs a decision.

The agent needs access to a system controlled by another department. That request sits for three weeks. It needs someone to define what a correct output looks like, and two teams disagree. It needs someone to approve going live, and the approval requires a meeting that keeps getting rescheduled.

None of these are technical problems. All of them are fatal at sufficient volume, because the project loses momentum and momentum is what keeps funding attached.

The agents that survive tend to be narrower and to have a named person whose week gets better. That person becomes the advocate. When someone asks whether to keep funding it, there is a human who says yes with specifics.

I would rather ship a small agent for one team that loves it than an ambitious one for a process that belongs to nobody. The small one gets renewed and then gets extended. The ambitious one gets a slide in a retrospective.

The risk controls were an afterthought

The third of Gartner's reasons is inadequate risk controls, and this one kills projects in a distinctive way. The build finishes. It works. Then it hits security review, or legal, or a compliance function, and it does not get through.

The questions are always the same. What data can it reach. What can it write to. What happens if it is manipulated into doing something it should not. Who is accountable when it is wrong. How do we prove what it did.

If those answers were designed in, the review takes two weeks. If they were not, the honest answer to several of them is "it can reach everything the service account can reach", and now you are rearchitecting under time pressure with an internal reputation problem.

Given that most organisations running agents in production have had at least one security incident tied to them, these reviews have gotten sharper over the last year, and they should have. The teams sailing through are the ones who showed up with a scoped credential per agent, an explicit allowlist of write operations, human approval on anything irreversible, and a complete log. That is a week of design work at the start. It is a quarter of rework at the end.

Agent washing made the whole category harder

There is an external factor worth naming. A large share of what is marketed as agentic is a rebranded chatbot, an RPA script with a language model on the front, or a workflow tool with new labels. Gartner's estimate is that only around 130 of the thousands of vendors claiming agentic capability are the real thing.

This matters to your project even if you build in-house, because it shapes what your executives expect. They have sat through demos of things that appear to reason and act, which were actually following a fixed script with a natural language veneer. Those demos never fail, because they cannot. Then your genuinely agentic system fails on 8% of runs the way real ones do, and it looks worse than the fake, which is a hard conversation to have honestly.

The counter is to set the expectation early and in writing. Real agents have a failure rate. The plan handles it with retries, fallbacks, and human escalation. A system with no failure rate is either trivial or not doing what you were told it does.

What the survivors have in common

Pulling this together from the projects I have watched live rather than die.

They started from a process with a number attached, and the number was big enough to matter but small enough to be one team's problem.

They built against real inputs from the first week, so the accuracy curve went up over the project rather than falling off a cliff at launch.

They tracked cost per completed task from the beginning, so the finance conversation was boring.

They had one person who wanted it, by name, and that person had time to answer questions.

They designed the permission model before the prompt. Every one of them. It sounds like a coincidence and I no longer think it is, because deciding what an agent is allowed to do forces you to be precise about what it is for, and precision is the whole game.

They shipped something narrow into production in weeks, not a broad thing in quarters. The narrow thing generated a real number, and the real number bought the next phase.

None of that is exotic. It is mostly the discipline of knowing what you are doing and why before you start, which is the same discipline that makes any project work. Agents just punish its absence faster, because they cost more per unit of vagueness.

If you are mid-project and worried

There is a short diagnostic I run when someone asks me to look at a wobbling agent build.

Can you state, in one sentence with a number in it, what this agent is supposed to change. Can you point at the person whose job it makes better. Do you know what a run costs today. Do you know what it does when it fails. Has anyone outside the build team used it on real work.

Five questions. If you get five yes answers, the project is probably fine and needs patience. Three or fewer, and the cancellation is coming whether or not anyone has scheduled it yet. The good news is that all five are recoverable in a couple of weeks if you stop building and go fix them.

We spend a fair amount of our time doing exactly this, either scoping agent work so it survives contact with a budget review, or picking up builds that stalled. If either sounds familiar, let's talk through it.