Gartner Says 40% of Agent Projects Will Be Canceled by 2027. Here's How Yours Survives.

Key Takeaways

• Gartner named three causes, and all three are build decisions. Escalating costs, unclear business value and inadequate risk controls are what it expects to kill over 40% of agentic AI projects by the end of 2027.
• Most canceled agents never left the demo stage. A demo proves the model can do the task once. Production proves it can do the task every day, at a known cost, without doing damage.
• Value has to be written down before the first prompt. One workflow, one owner, one outcome. If you can't name them, the project is already on the cancel list.
• Quality is the quiet killer. Builders say quality is their top barrier, yet only about half run evals. You can't defend an agent you never measured.
• Pass the month-three test. When someone asks what the agent costs, what it produced and what could go wrong, answer all three with data.

Gartner put a number on something a lot of people building agents already suspected. In a June 2025 forecast, it predicted that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.

The number got the headlines. I'd spend more time on the three reasons.

Read them again. None of them says "the model wasn't smart enough." Cost, value and risk are all things a team decides, on purpose or by accident, while it builds. Which means most of that 40% is avoidable, and the projects that get canceled will mostly be the ones that skipped the boring parts.

The same release has a line I keep thinking about. Gartner's Anushree Verma says most agentic projects today are "early stage experiments or proof of concepts that are mostly driven by hype." That matches what we see. A team gets a demo working in a week, everyone gets excited, and then the project sits in a strange limbo. It works. Sort of. Nobody is sure what it costs at scale, nobody has signed off on what it's allowed to touch, and nobody can say what it has saved.

That limbo is where cancellations come from. So here's the question I'd ask about any agent project, including ours: if a CFO walked in three months after launch and asked what this thing costs, what it produced, and what could go wrong, could you answer all three with data? I call that the month-three test. The rest of this post is about passing it.

Most Canceled Agents Died at the Demo

A demo and a production agent look identical for about a week.

The demo runs on clean inputs, one happy path, and a person watching every step. Production runs on whatever your systems throw at it: the scanned PDF, the half-filled CRM record, the customer who changes their mind three times. The gap between those two is where most of the engineering lives, and it's the part that rarely gets scoped.

I think teams underestimate this gap because the model is the impressive part. You watch Claude read a contract and draft a summary, and it feels done. What's missing is everything around the model: how it gets the right data, what it's allowed to do with it, how you know when it's wrong, and what happens when it fails at 2 a.m.

Write down what "production" means before you build

Agree on the bar up front. What inputs will it see? What output counts as correct? Who reviews it, and when? What's the cost ceiling per run? What happens when it hits something it can't handle? If those answers don't exist on day one, the demo will get mistaken for the product, and the gap will show up later as a cancellation.

Value Has to Be Named Before the First Prompt

"Unclear business value" sounds like a strategy problem. In practice it's usually a scoping problem.

The agents that struggle to justify themselves tend to start broad. An assistant for the finance team. An agent for operations. Those aren't workflows. Nobody can measure them, so nobody can defend them when budget season comes around.

Gartner makes a related point that I think gets skipped. Verma says "many use cases positioned as agentic today don't require agentic implementations," and the firm recommends using agents when decisions are needed, automation for routine workflows, and assistants for simple retrieval. Anthropic says something similar in its guide to building effective agents: find the simplest solution possible, and only add complexity when needed, which might mean not building an agent at all.

I agree with both. Some of the projects on track for cancellation are good automation ideas wearing an agent costume. (Gartner also estimates only about 130 of the thousands of vendors selling "agentic AI" are the real thing, so the costume problem isn't limited to internal projects.)

Scope to one workflow, one owner, one outcome

Pick a single process that a named person owns today. Write down how long it takes, how often it happens, and what good output looks like. Then decide whether it needs an agent's judgment or just a reliable script. If it needs judgment, build the agent around that one workflow, and make the owner the person who signs off on whether it worked.

Costs Escalate in the Runs Nobody Counted

Agent costs rarely blow up in one dramatic moment. They creep.

An agent is a loop. It plans, calls a tool, reads the result, and decides what to do next. Each pass is another model call. A workflow that retries on bad inputs, carries a huge context into every step, or uses the biggest model for trivial work can cost many times what it should. And because the output still shows up, nobody notices until the invoice does.

The fix isn't exotic. Measure the cost of a single run during the pilot, before anyone scales it. Cap retries. Route the simple steps to cheaper models. Track spend by workflow, not just by API key. If you want to go deeper on the cost side, PressW's Token Optimization work is built around exactly this: lowering cost per task without losing quality.

Put a ceiling on every run

Every agent should have a known expected cost per run and a hard limit it can't exceed. When it hits the limit, it stops and tells someone. That one guardrail turns a surprise bill into a log entry.

Risk Controls Belong Inside the Build

The third cause on Gartner's list is the one I'd worry about most in regulated businesses, and it's the one most often handled with a policy document instead of engineering.

A policy that says "the agent must not send money without approval" means nothing if the agent has the permission to send money. Risk controls have to live in the system itself: what credentials the agent holds, which actions require a person to approve them, what gets logged, and how it hands off when it's out of its depth.

That last part matters more than people expect. When we built an AI booking agent that schedules and cancels appointments through live API integrations, one of the core features was recognizing customer frustration and handing the conversation to a person. Knowing when to stop is part of the design.

Gate anything you can't undo

Sort every action the agent can take into three buckets: things it can do alone, things it drafts for a person to approve, and things it never touches. Enforce those buckets with permissions, scoped by role. Log every action with enough detail that someone could reconstruct what happened. Approval gates feel slow at first. They're also the reason a compliance team says yes.

Quality Is What Kills Agents After Launch

Gartner's three causes cover why projects get canceled. There's a fourth problem that feeds all three, and it shows up clearly when you ask the people building agents.

In LangChain's State of Agent Engineering survey of 1,340 respondents, 57% say they have agents in production, and quality is the most-cited barrier, named by 32%. Nearly 89% have observability on their agents. Only 52% run evals. (LangChain sells agent tooling, so its audience skews toward teams already building. I'd still trust the shape of the answer.)

That gap between watching and testing is the part I'd fix first. Observability tells you what the agent did. Evals tell you whether it was right. Without evals, every model update, prompt change or new data source is a guess, and the first sign of a quality problem is a user who stops trusting the output.

Build the eval set before the agent

Collect 20 to 50 real examples of the workflow, with the output a good human would produce. Write down the grading criteria. Run the agent against that set before launch and after every change. It's the least glamorous part of the build and the part that makes everything else defensible. It's also how we build at PressW: every custom Claude agent we ship comes with grading criteria and telemetry, so it gets measured before launch and after each update.

The Month-Three Test, in Five Questions

Here's the checklist I'd run before greenlighting an agent, and again three months after launch.

• What does one run cost? A real number from the pilot, plus a ceiling the agent can't cross.
• What did it produce? Tasks finished, hours returned, errors caught, measured against the baseline the owner wrote down before the build.
• Who owns it? One named person who signs off on whether it's working and decides what changes next.
• What can it touch? A written list of what it does alone, what needs approval, and what it never does, enforced in permissions.
• How do you know it's right? An eval set it passes before launch and after every update.

If you can answer all five, your agent is very hard to cancel. If you can't answer two or more, I'd fix that before adding a single new feature.

Someone Has to Own the Agent After Launch

Agents decay in a way that normal software doesn't. The model gets updated. The upstream system changes a field name. The team changes how it does the work. None of that throws an error. The output just gets a little worse, then a little worse again.

So the build is only half the cost. Somebody has to watch the telemetry, rerun the evals when a new model ships, tune the prompts, and decide which workflow comes next. If no one owns that, the agent that passed the month-three test will fail the month-nine one.

Budget for month nine as well as month one

When you scope an agent, scope its upkeep too: who monitors it, how often it gets re-tested, and how much time goes to tuning. That's why PressW's Custom Claude Agent Development practice includes ongoing tuning and support from a shared backlog. Agents that stay useful are the ones somebody keeps working on.

Most of the 40% Is a Choice

I'm bullish on agents. Gartner is too, in the same release: it expects at least 15% of day-to-day work decisions to be made autonomously by agentic AI by 2028, up from 0% in 2024. The cancellations and the growth will happen at the same time.

I don't know which of today's use cases will hold up. Some workflows that look like great agent candidates will turn out to be better as plain automation. Some will need models a generation better than what we have. And the tooling for evals, permissions and cost tracking is still rough in places. Nobody has this fully figured out, us included.

What I'm confident about is the pattern. The agents that survive will be scoped to a real workflow, measured from the first pilot, fenced in by real controls, and owned by someone after launch. Those are all decisions you make in the first few weeks.

If you have an agent stuck between demo and production, run the five questions above on it this week. If two or more come back blank, that's where to start, and if you'd like a second set of eyes on it, Book a Discovery Call.

FAQ