Your Agent Budget Is Built on One Call. Production Takes Twelve.

Every cost estimate for an agentic workflow starts the same way: tokens per call × model price × expected requests. That arithmetic is correct. It is also describing a system that doesn't exist in production.

A procurement approval agent doesn't make one inference call per user request. It classifies the request, extracts vendor and budget details, checks the approved vendor list, verifies department budget, routes to the right approval tier, drafts the approval message, parses the manager response, runs a compliance check, writes to the PO system, and notifies the requestor. That's ten inference calls on the happy path. When the vendor lookup returns ambiguous results, add two more. Twelve calls is typical — and that's a well-scoped, single-purpose agent.

The same pattern appears everywhere. A code review agent working through diff analysis, context retrieval, security review, and comment synthesis makes 7–9 inference calls per PR. A customer support agent that retrieves history, classifies intent, drafts a response, and checks policy compliance makes 6–8. Multi-agent orchestration adds more on top.

The call count alone doesn't explain the full cost gap. Anthropic's engineering team measured production agent systems and found agents burn roughly 4× more tokens than direct chat interactions; multi-agent research pipelines burn 15× more^[1]. That gap isn't model pricing — it's the inference multiplier: a compound of call count, context accumulation, tool schema overhead, and retry tax. Understanding all four components is what separates a realistic budget from a billing surprise.

40% of agentic AI pilots get cancelled before production, and runaway inference costs are the most common reason^[2].

Component 1: Call count. This is the part every team eventually notices. A workflow with 12 inference calls per user request costs at least 12× a single call — before anything else compounds. Most cost estimates stop here. The problem: call count is a multiplier on the three components below, not the final answer.

Component 2: Context accumulation. Every subsequent call in a multi-turn agent loop re-sends the full accumulated conversation history. Step 5 doesn't pay for step 5's reasoning — it pays for steps 1 through 5 in full, as input tokens. In a documented 5-step agent run, per-call input token counts grew: 888 → 3,400 → 8,900 → 14,200 → 18,900^[2]. The cost of step 5 alone exceeded steps 1 and 2 combined. The formula is triangular, not linear: total input tokens across N steps equals roughly N(N+1)/2 × average tokens per step. At 12 steps, the context accumulation factor is approximately 6.5× what a flat per-step estimate predicts.

Component 3: Tool schema overhead. Agent frameworks inject every registered tool's full schema into every inference call — whether or not the tool gets called. A single tool definition runs 550–1,400 tokens depending on description length and parameter detail^[3]. In multi-server MCP deployments, tool schema overhead reaches 10,000–60,000 tokens per call^[1], accounting for 60–80% of token usage in static toolsets. That overhead is billed on every step, before a single token of actual work happens.

Component 4: Retry tax. Failed tool calls don't disappear. The error, the model's recovery attempt, and all intermediate reasoning accumulate in context and get re-sent on every subsequent step. A 10% per-step failure rate, compounded across 10 steps without circuit breakers, multiplies costs several times over^[2]. One team cut their per-task tool call count from 14 to 2 by adding explicit SUCCESS/FAILED terminal states to tool responses — eliminating the retry loops that were consuming the majority of their budget.

The structural reason cost estimates fail is that engineers price multi-step agent workflows as N independent inference calls. They are not independent. Each call carries the full history of everything that came before it, because that's how the API works.

For a workflow with N steps, average static context S (system prompt + tool schemas), average user input u per step, and average tool result r per step, total input token consumption follows:

Total input ≈ N·S + N·u + N(N+1)/2 · r

The triangular term N(N+1)/2 is the problem. For a 10-step workflow it's 55. For 12 steps it's 78. Multiply that by the average tool result size and you're paying for far more than 12 separate steps.

Apply this to a 12-step procurement agent on Sonnet 4.6 ($3/M input, $15/M output)^[6]. Reasonable assumptions: 3,000-token system prompt plus tool schemas, 200-token average user input per step, 500-token average tool result per step.

Naive estimate: 12 × (3,000 + 200 + 500) = 44,400 input tokens.

Formula estimate: N·S is 36,000; N·u is 2,400; N(N+1)/2 × r is 78 × 500 = 39,000. Total: approximately 77,400 input tokens — 1.74× the naive estimate before a single output token is counted.

Add output tokens, the retry path on vendor ambiguity, and tool schema overhead from a moderately sized MCP toolset, and the real multiplier on the naive budget reaches 3–5× for this single workflow. That's before any multi-agent orchestration layer.

The only way to know your workflow's actual inference multiplier is to instrument it and measure from staging runs. A spreadsheet model can get the formula right; it cannot know your tool schema sizes, your retry rates, or your actual context accumulation slope.

The measurement pattern: wrap every inference call inside a parent workflow trace span, record per-call input and output token counts, track cumulative context size at each step boundary, and compute the ratio of total measured token spend to your step-1 token count × step count. That ratio is your multiplier.

OpenTelemetry's GenAI semantic conventions (gen_ai.usage.input_tokens, gen_ai.usage.output_tokens) give you per-call token data at the instrumentation layer^[7]. The gap in most observability setups: teams see per-call cost but not per-user-action cost. Aggregating across the full workflow under a parent span closes that gap.

Understanding the four-component multiplier tells you where to intervene. The highest-impact changes target components 2 and 3 — because they compound against every call in the workflow.

Dynamic tool loading (targets Component 3 — tool schema overhead). The fastest win in most systems. Instead of injecting every registered tool's schema on every call, load only the tools relevant to the current step. One team reduced tool-definition overhead from 134,000 tokens to 8,700 per call — an 85% reduction in that component — by switching to dynamic loading^[2]. At 12 steps, that's eliminating over 1.5M tokens of overhead across the full workflow. Implementation: classify the step type first with a cheap Haiku 4.5 call, then load only the tool subset needed for that step class. The classification call costs a few hundred tokens; the savings across subsequent steps return that cost many times over.

Structured handoffs instead of full transcripts (targets Component 2 — context accumulation). Most agent loops pass full conversation transcripts between steps. Replacing those with structured JSON summaries — the decision made, the data retrieved, the constraints that apply — cuts context size per step by 50–70% while preserving what the next step actually needs. The formula doesn't change; the per-step r value in N(N+1)/2 × r does. Halving r on a 12-step workflow halves the accumulation component.

Prompt caching on stable context (targets Components 2 and 3). System prompts and tool schemas are identical across calls within a workflow. Marking them with cache_control: { type: "ephemeral" } prices cache reads at 10% of standard input cost^[6]. For a 3,000-token system prompt across 12 steps, that's 33,000 tokens billed at full rate without caching versus 3,000 at full rate and 30,000 at the cache-read rate — a real reduction. One constraint worth knowing: the cache TTL is five minutes^[1]. Async approval flows and human-in-the-loop waits that span longer than five minutes will re-incur the cache write cost on the next step.

Combining dynamic tool loading and prompt caching addresses components 2 and 3 without touching workflow logic. Teams that implement both report 70–85% reduction from unoptimized baselines^[4].

The inference multiplier is the real unit of measurement for agent cost engineering. A 12-step workflow doesn't have a cost — it has a multiplier, and that multiplier interacts with model tier, tool schema size, and retry rate in ways a single-call benchmark cannot capture.

Measure the multiplier from staging traces. Document it per workflow, at P95. Set the production budget ceiling against that number, not against the per-call estimate. The teams that avoid billing surprises share one discipline: they treat multiplier measurement as a launch gate, not a post-incident activity.