Back

Half of GenAI Projects Will Blow Their Budget by 2028. Gartner Is Blaming the Wrong Layer.

Gartner says poor architectural choices will push half of GenAI projects over budget through 2028. Its own August research points somewhere else, at agentic workflows costing five times more per task because agents run longer and retry more. Scope drives the bill, and a spec is what bounds it.

3 min readBy SpecPilot Team
ai-budgetsagentic-aispec-driven-developmentengineering-leadershipai-governance
Half of GenAI Projects Will Blow Their Budget by 2028. Gartner Is Blaming the Wrong Layer.

Gartner's forecast is circulating again: through 2028, at least half of GenAI projects will overrun their budgeted costs because of poor architectural choices and thin operational know-how. The number looks right. The diagnosis points at the wrong layer.

Gartner published something on August 17 that complicates its own framing. Inference cost per agentic workflow will rise more than fivefold through 2028. They call it the Inference Paradox. Unit prices fall, so teams reach for bigger models and longer chains, and total spend climbs faster than efficiency pulls it down. Routing a single task to an agentic reasoning model already costs at least 5x a chatbot turn, and more as the task gets messier.

That curve is set by how many times the agent runs and how long it goes before somebody decides it is finished. Your vector store choice barely registers against it.

Ranked by how much they take out of the budget.

  1. No definition of done. An agent given a vague goal does not stop. It explores, second-guesses, re-reads files it already read, and produces a plausible answer to a question nobody pinned down. Every loop is metered. The bill arrives whether or not the output was what anyone wanted.

  2. Rework billed at full price. Generated code that solves the wrong problem costs twice: once to produce, once to produce again after review catches it. At 5x per agentic task, a second pass is not a rounding error.

  3. Retries nobody is counting. Failed tool calls, truncated context, silent restarts. Most teams have no line item for these because their observability was built for request-response, not for a process that runs for twenty minutes and decides its own next step.

The sharpest comment under Gartner's post made a related argument: the question is moving from which model to use toward what capability you are building, because the model is one layer and the durable value sits in the workflows, governed access, and measurable outcomes around it. Another pushed further, pointing out that choosing the right technology says nothing about whether an organization can operationalize it. Decision rights, measurement, and workforce capability decide that, not the reference architecture.

Both are right, and both land on the same missing artifact. You cannot govern access, measure an outcome, or tell an agent to stop without a written statement of what the work is and when it counts as complete.

A specification is a cost control. It bounds scope before the agent starts spending, gives review a fixed target instead of an open-ended judgment call, and turns "keep going" into a condition a machine can evaluate.

Before you sign off on next quarter's AI budget, ask what your agents are allowed to stop working on. If nobody can answer that, the number on the page is a guess.

Found this helpful? Share it with others!

SpecPilot logo
Specification-Driven Development CLI

Open source under MIT License

Built for developers who value planning and structure

Contact: hello@specpilot.dev