Why a cost surprise, not a capability gap, is what gets an agent project canceled

Projects rarely die because the agent could not do the task. They die because the bill arrived larger than the business case, and the value was not clear enough to justify it.

B

Balagei G Nagarajan

4 MIN READ


A budget line and an actual-cost line diverging until the project is marked canceled at the crossover

Key facts.

  • Agent spend can grow approximately quadratically in the number of steps, because each step re-sends the accumulated context, which is how a pilot-based estimate lands well below the production bill (blog.exe.dev, reported). source
  • MIT's NANDA initiative reported about 95% of enterprise GenAI pilots showed no measurable P&L return despite an estimated $30 to $40 billion in investment, the clearest signal that unclear value, not raw capability, is the binding constraint. source
  • METR's RCT measured experienced developers about 19% slower with early-2025 AI tools while believing they were faster, so the productivity gains a business case leans on can fail to appear. source

Why does a cost surprise specifically kill projects?

Because it breaks the deal the project was funded on. A business case is a trade: this much cost for this much value. When the cost lands several multiples above estimate, the trade is no longer the one leadership approved, and the natural response is to stop. The value side does not help, because as the NANDA finding shows, the value is frequently unclear or unmeasured, so there is nothing concrete to weigh against the overrun. A clearly profitable agent survives a cost surprise. A fuzzy one does not, because the cost is now large and certain while the benefit is still small and uncertain.

The reason the surprise happens at all is that the estimate was built on a pilot, and the pilot does not trigger the cost multipliers, the retries, the long context, the oversight, that production does. The METR result adds a second reason: the productivity that was supposed to offset the cost may not materialize, so even the benefit assumption can be optimistic. Put an underestimated cost next to an overestimated benefit and the gap is exactly the space a cancellation lives in.

Crossing-lines chart of estimated cost staying flat while actual cost rises past the value line into the cancellation zone

How do you keep the cost surprise from arriving?

Build the estimate on production reality, not pilot numbers: real volume including peak, real context lengths, and a retry factor from the measured failure rate. Tie the value to an outcome the business counts, so when the cost is questioned there is a concrete benefit to set against it. And do not assume the model upgrade pays for itself, because METR shows AI-assisted productivity is not automatic. The project that survives is the one where the cost was modeled honestly and the value was made legible before the first full invoice, so there is no surprise to trigger the cancellation.

Failure modeLooks likeWhat prevents it
Underestimated costPilot-based budgetProduction volume, context, retry factor
Unclear valueProductivity assumedOutcome the business counts
Optimistic benefitModel upgrade pays for itselfMeasured, not assumed, gains

The Pattern Intelligence Layer is where cost and value become measured properties rather than business-case assumptions. Production volume, the retry factor, and cost per delivered outcome are tracked at the pattern level, so the number leadership sees matches the number the agent produces. Reliability at the pattern level is also the reliability of the business case, which is what keeps the project off the cancellation list.

Frequently asked questions

Would a more capable model have saved the project's economics?
Cancellations judge the business case, not the tech: MIT NANDA found ~95% of pilots with no P&L return and spend growing quadratically (blog.exe.dev). A stronger model won't rescue it; METR clocked devs ~19% slower. (arXiv:2507.09089)

Is the agent being canceled because it cannot do the task?
Usually not. Cancellations cluster around cost overruns and unclear value, not capability gaps, which is what the NANDA finding and the quadratic cost mechanics describe.

Would a clearer value case alone save it?
It helps a lot. A profitable agent survives a cost surprise; a fuzzy one does not, because there is nothing concrete to weigh against the overrun.

Why not count on productivity gains to cover cost?
Because they are not automatic. METR measured experienced devs slower with AI tools, so the offsetting benefit can fail to appear.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.