Agent cost curves are not linear, and the shape catches teams out in month two. A small slice of interactions — the ones that retry, re-retrieve, and fan out across tools — carries most of the bill.
The tooling is rarely the problem. What is missing is the instrumentation to see which interactions are expensive, and the policy layer to stop them before they compound.
Where does the spend actually go?
Trace every run and the distribution is brutally uneven: roughly a quarter of interactions account for three quarters of token spend. Three patterns explain almost all of it — retry storms after a malformed tool response, context bloat from retrieval that never gets trimmed, and tool-call fan-out where the planner calls four tools to answer something one could have settled.
What is a retry storm?
A retry storm is what happens when a tool returns a response the model cannot parse and the agent tries again with more context each time. Each retry is more expensive than the last because the failed attempt is now in the window. We have seen a single malformed webhook payload turn a $0.02 interaction into a $3.40 one, and the run still failed.
The fix is not a better prompt. It is a typed tool contract that fails fast, a retry ceiling of two, and a deterministic escape hatch to a human on the third.
Why does context bloat cost so much?
Context bloat is retrieval that accumulates across a multi-step run and never gets trimmed, so every subsequent model call pays for documents that stopped being relevant three steps ago. On a ten-step run with five retrieved chunks per step, the last call can be carrying forty chunks of which two matter.
Budget retrieval by task type rather than globally. A classification step gets three chunks; a drafting step gets twelve; nothing carries retrieved context across a step boundary unless the planner explicitly pins it.
What does tool-call fan-out look like in a trace?
Fan-out is the planner calling four tools in parallel when one would have resolved the question, usually because the tool descriptions overlap and the model hedges. It is invisible in aggregate cost dashboards and obvious the moment you look at a per-run trace with cost attributed per tool call.
Deduplicate the tool surface. If two tools can answer the same question, merge them or make the boundary explicit in the schema — the model is hedging because you gave it a reason to.
If you cannot see cost per run in the same view as quality, you will optimize one and quietly break the other.
What did we change?
We ship four controls with every agent now: hard step and spend ceilings per run, retrieval budgets tied to task type, a deduplicated tool surface with typed contracts, and a regression gate that fails a merge when cost per resolved task rises without a matching quality gain.
Across the last four TekPod engagements that combination cut cost per resolved task by a median of 61%, with no measured drop in eval scores.
What should you measure first?
Measure cost per resolved task, not cost per token. Token spend is an input; the number that matters is what it costs to finish a unit of work a human would otherwise have done. Put that metric next to your eval score in the same view, gate merges on both, and the expensive quartile stops being invisible.