Strategy
Why most agentic AI projects stall, and how to avoid it
Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. The reasons are predictable, which means they are avoidable.
Key takeaways
- Gartner cites three causes of cancellation: escalating costs, unclear business value and inadequate risk controls.
- Each cause can be addressed in the first weeks of a project, before any system is built.
- Value, unit economics and governance should be designed up front, not retrofitted.
- A short, evidence-led proving ground beats a long, ambitious pilot.
Agentic AI is moving from slideware to software quickly. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025. McKinsey's 2025 survey found that 62% of organizations are at least experimenting with AI agents, though only about 23% are scaling them in any part of the business.
The gap between experimenting and scaling is where most of the value, and most of the disappointment, lives. Gartner has put numbers on it: it expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.
The encouraging part of that finding is that the reasons are specific. Specific problems have specific remedies. Here is how we think about each.
Reason one: unclear business value
Many projects begin with a capability ("let us build an agent for X") rather than with an economic question. Without a clear statement of the value at stake, there is nothing to defend when budgets tighten.
What to do. Before building anything, produce a value map for the workflow: how many people touch it, how many hours it consumes, what it costs per outcome, what errors cost and what revenue it influences. Then decide what share is realistically suited to autonomy. If the economics do not hold, the right answer is to say so and not to build. That discipline alone removes a large share of the projects that would have been cancelled later.
Reason two: escalating costs
Costs escalate when nobody can say what one completed outcome costs. Model usage, integrations, monitoring and human review all add up, and they grow with volume. A demonstration that costs a few dollars per run can become a surprise at scale.
What to do. Treat unit economics as an engineering requirement. Route each step to the most efficient model that can do it well. Cache repeated work. Put caps on spend per run and per day. Measure cost per outcome from the first week, and report it alongside the benefit. When the cost of an outcome is known, bounded and falling, the finance team stops being a risk to the project and becomes a supporter.
Reason three: inadequate risk controls
Systems that act inside your software can do real damage when they are wrong. If risk controls arrive after the system, they arrive as a brake, usually applied by a security or compliance team that is seeing the project for the first time.
What to do. Make governance part of the design. Define the level of authority before launch. Scope permissions per system and per action. Require approval for sensitive actions. Keep a complete, searchable record of everything the system does. Evaluate against real cases before every release and monitor in production afterwards. Our article on autonomy as a dial describes the model we use.
A practical way to start
A long, ambitious pilot is the usual way to run into all three problems at once. A better pattern is a short, evidence-led proving ground:
- Pick one workflow with high volume, clear rules and measurable outcomes.
- Write the value map and agree what success looks like in numbers.
- Define the authority, starting at approval on every action.
- Run it on your own data for a few weeks, with cost per outcome visible throughout.
- Decide with evidence: extend, adjust or stop.
Done this way, even a project that is stopped has produced something valuable: a clear answer, reached cheaply. And a project that continues does so with the economics and the controls already in place.
Sources
Keep reading
More from the lab
Playbook
How to choose the first function to automate
The first function you give to an autonomous system decides how much trust, budget and momentum you have afterwards. A practical way to choose it.
Thinking
Autonomy is a dial, not a switch
Most conversations about AI ask whether to automate something. The better question is how much authority to grant, and how that authority is earned.
Put it to work