Diagram 1: A branching agentic workflow with token counters escalating at each step, in warm gold and amber tones on near-black background

Every AI cost model built on chatbot economics is going to be wrong for agentic systems. The gap is not marginal. Gartner’s March 2026 analysis puts agentic tasks at 5 to 30 times more tokens per task than a standard chatbot query. An arXiv paper from April 2026 found agentic coding tasks consumed roughly 1,000 times more tokens than standard code reasoning. And the bills are showing up.

The Uber case that has been circulating since March 2026 is the canonical warning. Between December 2025 and March 2026, Claude Code adoption at Uber jumped from 32 percent to 84 percent of the 5,000-engineer organisation. Monthly API costs per engineer ran between $500 and $2,000. By April, the entire annual AI budget was gone.

That is not a story about reckless spending. Uber is a technically sophisticated engineering organisation. It is a story about pilot economics not surviving contact with production, and it is happening quietly at every company running agentic AI at scale. This article is about what actually changes when you move from single-shot AI to multi-step agents, and how to think about the economics before the bill arrives.

Why agents are expensive: the mechanical view

Understanding agent economics starts with understanding what agents actually do that costs so much. Five mechanics drive it.

The first is loop iteration. Agents plan, act, observe, and repeat. A single user request can trigger 10 to 20 LLM calls to complete. Each call is billed. The base rate for a single call may look reasonable; multiplied by the loop count, it stops looking reasonable quickly.

The second is context growth. Every step in an agent loop resends the full context: goal, memory, tool definitions, conversation history, retrieved documents. By step 10, you have paid for the same context 10 times. A Concordia University study from 2026 measured a 2-to-1 input-to-output ratio in typical agent workloads, with the “communication tax” of resending context consuming most of the input side.

The third is retry loops. Agents self-correct when outputs do not meet validation criteria. When they retry, they resubmit the full history plus new instructions. An agent that runs 10 correction cycles can consume 50 times the tokens of a single linear pass. Retry behaviour is often necessary for output quality. It is almost never in the cost projection.

The fourth is tool call overhead. Each tool call has its own token cost for the tool definition, the arguments, the result, and the reasoning about the result. Agents that call many tools inflate token consumption in ways that are invisible from the outside.

The fifth is background inference. Monitoring agents, document watchers, compliance surveillance systems all run continuously, consuming tokens against every event they process, regardless of whether any user requested a response. These workloads were minimal in 2024 enterprise deployments and are a rising share of agent bills in 2026.

The Agent Loop Multiplier

Recent research proposed an “Agent Loop Multiplier” that captures the token overhead of agent frameworks compared to a base LLM call. The measured range across common frameworks in 2026 was 1.2x for well-optimised A2A-native agents up to 3.87x for uncoordinated multi-agent systems using AG2. That is a 3x spread just from framework choice, independent of the underlying model.

The framework choice is one of the most consequential architecture decisions in an agentic programme, and it is one of the least discussed in most business cases. A $10,000-a-month agent deployment on an efficient framework becomes a $32,000-a-month deployment on an inefficient one, for essentially the same functional behaviour.

The illusion of falling costs

Here is the paradox that catches most people out. The per-token price of AI has fallen dramatically since 2023: roughly 10 times a year in the 2021 to 2025 window. And yet enterprise AI bills are climbing.

The EY example that has been widely quoted this year captures it well. A single customer service interaction that cost $0.04 in early 2023 costs $1.20 in 2026, a 30 times increase, even as token prices fell. What changed was not the price. What changed was the shape of the interaction: from a single-shot response to an agentic loop with retrieval, tool calls, retries, and multi-turn reasoning.

The framing that matters is not “cost per token.” It is “cost per successful task.” When you plot cost per successful task over time for equivalent-quality outcomes on agentic workloads, the trend is often flat or rising, not falling. The token deflation is being consumed by the token multiplication.

Cost per successful task: the metric that matters

Diagram 2: A layered stack showing how a naive per-token cost calculation misses the multiplier effects (loops, retries, context reloads, tool calls, background inference) that determine actual cost per successful task

Figure 1 shows the layered stack from per-token price to actual cost per successful task. The gap between the two is the agentic multiplier.

Cost per successful task, the metric shown at the bottom of Figure 1, is defined as: total cost incurred (across all tokens, retries, failures, and infrastructure) divided by number of tasks completed to the required quality standard. The denominator is the load-bearing part. A task that failed and had to be retried is not a success. A task that produced output rejected by a human reviewer is not a success. A task that appeared to succeed but caused downstream errors is not a success.

Instrumenting cost per successful task requires defining what “successful” means for each use case. That definition is often harder than it sounds. For a customer service agent, is success the ticket being closed, the customer being satisfied, or the issue being resolved with no follow-up contact? Each definition produces a different denominator, and different numbers. The discipline of picking one, documenting it, and measuring against it consistently is what separates programmes that can manage agent costs from programmes that get surprised by them.

The five levers for agentic cost

The four levers from BCR-06 (model routing, prompt caching, prompt compression, batching) still apply to agentic systems. But agentic systems have five additional cost levers that matter more than the base ones.

Loop budget caps. Setting an explicit maximum number of iterations before an agent must stop and hand off to a human or terminate. Uncapped loops are the single largest source of runaway agent cost. A 20-iteration cap on tasks that typically finish in 5 iterations rarely affects success rate and dramatically bounds worst-case cost.

Context pruning. Rather than resending the full conversation history at every step, aggressively summarise older turns and retain only the working context. Well-designed pruning can cut token consumption by 60 to 80 percent on long-running agents without materially affecting quality.

Effort controls. Modern reasoning models like Claude Opus 4.8 expose “effort” parameters (low, high, xhigh, max) that cap internal reasoning tokens. Default settings often quietly consume more than needed. Explicit effort budgeting per task type is one of the highest-leverage optimisations available in 2026.

Framework choice. As noted, the Agent Loop Multiplier varies 3x across common frameworks. Choosing an efficient framework at architecture time is dramatically easier than migrating one later.

Human-in-the-loop economics. Some agent tasks are best done as a first-pass agent with human review, rather than a fully autonomous agent that has to be right. Human review adds cost but caps the tail risk of expensive failures. The right split depends on the specific workflow, but it is worth modelling explicitly rather than assuming autonomous is always better.

The retry economics that break budgets

I want to spend an extra moment on retry economics because they are so consistently underestimated.

The naive model of an agentic task is: N steps, K tokens per step, total cost N×K×price. The real model is: N steps × R retries × context that grows across the retry × K tokens per step × price. If R is 3 (three tries before success) and context grows 30 percent per retry, actual cost is 3×1.3² = 5x the naive estimate.

Now factor in that early failed retries often trigger fresh agent loops (each with their own multiplier), and you can see how a business case built on the naive model ends up 5 to 20 times over budget in production.

The fix is not to eliminate retries; retries are how agents achieve quality. The fix is to model retries into the cost estimate from day one, and to instrument success rate carefully so you can see when retry rates start growing (which typically happens when task complexity expands, model quality drifts, or upstream inputs change).

When agents are worth it

Nothing above should suggest agents are bad economics. They are just different economics. When agents work, they can automate work that no single-shot AI can touch: multi-step processes, decisions that require tool use, workflows that need adaptation. The unit value can be much higher than a chatbot response, because the unit is a completed workflow rather than a single interaction.

The economics work when three things line up. First, the workflow is genuinely worth automating (high value per successful task). Second, the failure mode of a bad result is bounded (usually via human review at critical checkpoints). Third, the agent economics have been engineered rather than assumed (loop caps, context pruning, framework choice, effort controls all implemented from the start).

Gartner’s projection that more than 40 percent of agentic AI projects will be cancelled by 2027 is largely about the third dimension. The projects being cancelled are the ones where economics were not engineered, and the bill arrived before the value did.

Building the agent business case

Diagram 3: A worked example of an agentic use case showing baseline cost estimate, then applying the five levers (loop cap, pruning, effort controls, framework choice, human-in-loop) to arrive at a defensible cost per successful task, contrasted with the naive per-token calculation

Figure 2 works through an example of how the agent cost calculation should look. The naive per-token number is the starting point. Each lever adjusts it. The final number, cost per successful task with the levers engineered in, is what should go into the business case.

A defensible agent business case, following the structure in Figure 2, includes: the naive baseline and the engineered baseline both shown, the specific levers being applied with expected impact, a projected retry rate with sensitivity around it, an assumed adoption path that accounts for power users driving disproportionate cost, and a monitoring plan that will catch drift early.

Without those elements, the case is essentially guessing at what production economics will look like, and the guess is almost always wrong in the same direction (too optimistic). With them, the case is smaller than the exciting version but more likely to survive contact with the actual bill.

Agents are one of the highest-value opportunities in enterprise AI. They are also the category where economic discipline matters most, because the cost variance between well-engineered and poorly-engineered agents can be 10x on the same functional workload. The business case is where that discipline starts.