Gartner put a number on a feeling a lot of teams already had. In a note published in June 2025, the firm said it expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and it named three culprits: costs that got away from people, business value nobody could point to, and risk controls that were mostly aspirational.
Read as a headline, that sounds like a verdict on the technology. Spend a week inside one of these projects and it reads differently. The agents that get cut are rarely the ones that could not do the job. They are the ones where, when someone finally asked "what is this costing us, is it working, and how would we know if it broke", the honest answer was a shrug. All three of Gartner's reasons are the same missing thing seen from three sides. You cannot see what the agent is actually doing once it is in production.
That is oddly reassuring, because a visibility gap you can close in an afternoon, whereas "the technology does not work" you cannot. So rather than relitigate whether agents are overhyped (some plainly are), it is more useful to walk through how each of the three reasons actually plays out, and where the part you control sits.
The bill nobody could explain
Cost is the reason that arrives with a receipt, which is why it tends to be first to sink a project.
The shape is almost always identical. Several agents share one provider key. Spend drifts up for a couple of months while the company grows, so nobody looks twice. Then one agent ships with a retry loop that has no cap, and on the small slice of inputs it cannot handle it retries ten or fifteen times, dragging the full conversation history along on every attempt. The month closes and the token line has quadrupled. Because everything bills to the same key, the provider dashboard shows one rising line and no way to tell which agent did it, so reconstructing the answer from raw logs burns three engineer-days. I pulled one of these apart run by run in Anatomy of an $8,900 token bill. The short version is that a per-agent view of daily spend would have named the culprit on day two instead of day thirty-three.
None of that is fixed by a cheaper model. It is fixed by knowing cost per agent per day, so the number is something you watch rather than something you autopsy. Once each run carries its own cost, "the bill doubled" becomes "this agent doubled overnight, here is the run that did it", and a runaway turns into a thirty-second diagnosis.
"Unclear value" usually means "no honest denominator"
This is the reason that kills projects quietly, in a budget review, and it is the one most worth understanding, because it is so rarely about the agent being bad.
An agent can be doing genuinely useful work and still get cancelled if the only number anyone can produce for it is total spend. Total spend is all cost and no benefit, which makes it easy to cut. Nobody was ever reprimanded for deleting a line item they could not connect to an outcome. The number that survives that conversation is cost per successful run: spend divided by the runs that actually did their job. It reads like unit economics because it is unit economics, and unit economics is a language the person holding the budget already speaks.
Getting there needs two facts on every run: what it cost, and whether it worked. The first is attribution. The second is a definition of "worked", which for most agents is a cheap deterministic check on the output shape plus a sampled quality score for the judgment calls a regex cannot make. Put them side by side and you can say something like "this agent costs eleven cents per good answer, down from nineteen last month, quality flat". That one sentence is the difference between renewed and wound down, and it is worth a great deal more than a slicker demo. If the metric is new to you, the unit-economics piece goes deeper on how to define "successful" without kidding yourself.
Agents fail politely
The third reason gets underrated because agents break in a shape traditional monitoring was never built to see.
A normal service fails loud. It throws, returns a 500, trips a health check, pages someone. An agent tends to fail polite. It runs, returns well-formed JSON, the queue drains, every dashboard stays green, and the output is quietly wrong the entire time. There is no exception to catch, because nothing technically errored. The support-triage agent that started routing billing tickets to the wrong queue after a silent provider model upgrade did not crash. It just got worse, for eleven days, until a customer asked why nobody had replied. That failure and its two cousins are laid out in three blind spots when running AI agents in production.
Strip the boardroom phrasing off "inadequate risk controls" and it is simply the monitoring that makes those failures loud again. A scheduled agent that goes silent should page someone within minutes, not surface as a support ticket next week. A spend spike should trip an alert the morning it starts. A drop in output quality should appear as a falling line on a chart with a deploy marker beside it, not as a slow rise in "you misunderstood me" replies. That is three alarms sitting on top of one honest record per run. It is engineering, not governance, and it is a weekend of work rather than a quarter.
Not all of the 40% is failure
One line in Gartner's note is worth sitting with before you take the number too literally. The firm calls out "agent washing", the habit of rebranding old chatbots, RPA scripts, and assistants as agents, and reckons only around 130 of the thousands of self-styled agentic vendors are building anything genuinely agentic.
That reframes the cancellation figure. Some of those scrapped projects were never real agents, so there was never any agentic value to find, and those deaths are the market cleaning itself up. The waste is in the other group: real agents doing real work, cut anyway because nobody instrumented them well enough to defend them when the question came. The first group is healthy. The second is avoidable, and what avoids it is not more model. It is more visibility, applied early enough that the evidence already exists by the time anyone asks.
Underneath all of it sits the pilot trap. A demo runs a handful of hand-picked inputs and looks like magic. Production runs the thousands of ugly ones the demo never saw, and that is exactly where the uncapped retry, the silent drift, and the one looping agent live. Instrumentation is the thing that carries a project across the gap between "demoed well" and "operates well". Skip it, and the project turns up to its first real budget review holding anecdotes where it needed numbers.
Boil the whole post down and the agents that outlast 2027 are the ones that can answer three questions on demand, per agent: what did this cost, did it work, and will we know when it stops. That happens to be most of the production-readiness checklist for agents too, which is not a coincidence. Production-ready and cancellation-proof turn out to be the same property. Engineering calls it observability and finance calls it defensibility.
AgentPing is the version of this we are building, because we kept watching that second group of projects die for want of a single defensible number. One event per run gives you the cost attribution, the freshness alerting, and the quality scoring, with no eval pipeline to stand up first. If an agent of yours is heading for a budget review, the useful thing to bring is not a better demo but a number you can stand behind, and you can start building one for free on whichever agent you would least like to lose.