The conversation happens in every enterprise about eighteen months into agent adoption. Someone in finance asks which agents are responsible for a model API bill that has grown by a factor of six, and nobody can answer.
Not because the data is unavailable. Because nobody instrumented for the question. The invoice arrives as a single number against a single account, aggregated across every team, every agent, and every tenant. It is a bill, not a cost model — and you cannot manage what you cannot attribute.
This is the operational half of the AI economics picture. The strategic half — model tiering, caching, routing — is well covered and reasonably well understood. The attribution problem gets less attention and blocks more decisions, because almost every optimisation question requires knowing where the money currently goes.
Why agent spend resists conventional FinOps
Cloud FinOps practice assumes you can tag resources. A VM belongs to a cost centre; a storage bucket has an owner; allocation follows the tag. Agent spend violates several of those assumptions at once.
The unit of consumption is a request, not a resource. There is nothing to tag. A model API call is ephemeral, and by default the only durable record is a line on an aggregated invoice.
Consumption is non-deterministic per unit of work. Two runs of the same task can differ several-fold in cost depending on how many reasoning steps the agent takes, how many tools it calls, and how much context accumulates. Traditional unit economics assume a stable cost per transaction; agents do not offer one, which makes the distribution the thing you have to model rather than the mean.
Cost is nested. A multi-agent task incurs spend across several agents, each making several calls, some of which invoke sub-agents. Attributing the total to the originating business request requires propagating identity through the whole call tree.
A single actor can generate unbounded spend. This is the property with no real cloud analogue. A misconfigured retry loop, a prompt injection that induces repeated tool calls, or a poorly scoped task can consume a month’s budget in an afternoon. Cost is not merely a financial concern; it is an availability and blast-radius concern.
The five dimensions worth attributing
Aggregate spend is nearly useless for decisions. Five dimensions cover the questions people actually ask.
Per agent. The baseline. Which agents cost what, and how has that changed. Answers “is this agent worth operating,” which is the question that should drive decommissioning decisions and almost never does, because the cost side of the ROI calculation is missing.
Per task type. Within one agent, different task types have very different economics. An agent handling both simple status lookups and complex multi-system reconciliations has a bimodal cost distribution, and the average conceals both modes. Task-level attribution is what reveals that 6% of requests drive 60% of spend — which is where routing and caching investment should go.
Per tenant or business unit. Required for chargeback, and required much earlier than teams expect if the agent serves multiple internal customers. Retrofitting tenant attribution is painful because it means threading identity through code that was not designed to carry it.
Per model and per tier. Which models are actually being used, versus which your architecture document says are being used. Routing logic drifts, fallbacks fire more often than anyone realises, and a fallback to a frontier model that triggers on 30% of requests instead of the intended 2% is a common and expensive silent failure.
Per outcome. The dimension almost nobody instruments and the most valuable one. Cost of successful completions versus cost of failures, retries, and abandoned tasks. Spend on failure is pure waste, and it is frequently 15–30% of the total. It is also the number that makes the business case for reliability work, because it converts an engineering argument into a financial one.
Instrumenting it
The mechanics are not difficult. They are simply easier before you have thirty agents than after.
Propagate a correlation identifier through the entire call tree. One identifier per originating business request, carried through every agent, sub-agent, and tool call. This is the foundation for everything else, and it is the same identifier your observability stack should already be using — cost attribution and tracing are the same instrumentation problem viewed from two angles, and building them separately is a mistake teams make once.
The current MCP specification helps here: the documented OpenTelemetry trace-context conventions for _meta (traceparent, tracestate, baggage) give you a standard place to carry this across agent-to-tool boundaries rather than inventing a header per integration.
Record cost at the call site, not from the invoice. Every model call should emit a structured record: correlation ID, agent ID, task type, tenant, model, input tokens, output tokens, cached tokens, latency, and outcome. Reconstructing attribution from provider invoices is a reporting exercise that arrives weeks late; recording at the call site gives you the data in real time, which is what budget enforcement requires.
Capture cached versus uncached tokens separately. Prompt caching changes effective cost substantially, and a metric that does not distinguish them will show a cost reduction you cannot explain or reproduce. It also means you can measure cache hit rate as a first-class operational metric, which is the feedback loop that makes caching investment tractable.
Route through a single measurement point. Whether that is a gateway or a shared client library, one chokepoint through which all model traffic passes is what makes attribution complete rather than approximate. Direct provider SDK calls scattered across services are how you end up with 70% coverage and no way to find the rest. This is the architectural decision that matters most, and it is much cheaper to make early.
Emit cost as a metric, not only a log. You want alerting thresholds and dashboards on spend rate, not a monthly report. Rate-of-spend alerting is what catches a runaway loop in twenty minutes instead of at month end.
Budgets that fail safely
Attribution tells you what happened. Budget enforcement is what stops the incident.
Three controls, in increasing order of aggressiveness:
Per-task ceilings. A hard limit on tokens or tool calls for a single task execution. When the limit is hit, the task terminates and escalates rather than continuing. This is the control that contains runaway loops, and it belongs in the agent framework rather than in monitoring — by the time an alert fires, the money is spent. Set the ceiling from your observed distribution, not the mean: roughly the 99th percentile of normal executions, so it catches pathology without killing legitimate hard cases.
Per-agent rate limits. A spend rate cap per agent per unit time, enforced at the gateway. Protects the shared budget from one misbehaving agent and gives you a natural blast-radius boundary aligned with your security boundaries.
Tenant quotas. Where agents serve multiple business units, per-tenant caps prevent one consumer from exhausting shared capacity — the same reasoning as API rate limiting, applied to cost rather than throughput.
The design question that matters more than the thresholds: what happens when a budget is exhausted? Three options, and the choice should be explicit per agent rather than a platform default.
Degrade — fall back to a cheaper model and accept lower quality. Appropriate for high-volume, low-stakes work. Queue — defer the work until the budget window resets. Appropriate for asynchronous processing. Escalate — stop and hand off to a human. Appropriate for anything consequential.
Silent failure is the option to design out. An agent that hits a budget ceiling and returns a degraded answer without signalling it has converted a cost control into a correctness problem — and this is a genuine autonomy border, which means it belongs in the agent’s design record rather than in infrastructure configuration nobody reads.
Making the numbers mean something
Raw spend is not a decision input. Two derived metrics turn it into one.
Cost per successful outcome. Total agent cost divided by successful completions — including the cost of the failures. This is the number to compare against the manual process it replaces, and it is usually meaningfully worse than the naive per-call figure teams quote in business cases. It is also the metric that improves when reliability improves, which correctly aligns the incentive.
Cost per unit of business value. Where you can define the unit — per invoice processed, per ticket resolved, per document reviewed — this is what a business sponsor can actually evaluate. It also enables the comparison that matters for scaling decisions: does this get cheaper per unit as volume grows, or does it scale linearly? Agents with heavy per-task reasoning frequently do not benefit from volume the way traditional automation does, and knowing that before committing to a rollout is worth a great deal.
Both metrics require the outcome dimension, which is why instrumenting outcome is worth the extra effort it takes.
What attribution does not give you
It does not tell you whether an agent should exist. A precise cost figure for an agent delivering no value is a well-measured waste. Attribution informs the ROI conversation; it does not resolve it.
It also does not capture the full cost of an agent programme. Model API spend is the visible line, and for many deployments it is not the largest one. Engineering time, evaluation infrastructure, human review capacity, and the observability stack itself are all real costs that no token counter reports. Teams that optimise hard on token spend while consuming three engineer-months on prompt tuning have optimised the wrong variable — and only a full-programme view surfaces that.
Finally, attribution is a measurement discipline, not an optimisation. Knowing that 60% of spend comes from 6% of requests is only valuable if something changes as a result. The measurement is the cheap part.
Key takeaways
Agent spend resists conventional FinOps because the unit of consumption is an ephemeral request rather than a taggable resource, cost per unit of work is non-deterministic so the distribution matters more than the mean, spend nests across multi-agent call trees, and a single misconfigured actor can consume a month’s budget in an afternoon — making cost a blast-radius concern rather than only a financial one. Attribute across five dimensions: per agent to support decommissioning decisions, per task type to reveal the small fraction of requests driving most spend, per tenant for chargeback, per model to catch fallback logic firing far more often than intended, and per outcome to expose the 15–30% of spend typically consumed by failures and retries. Instrumentation requires one correlation identifier propagated through the entire call tree, cost recorded at the call site rather than reconstructed from invoices, cached and uncached tokens tracked separately, all traffic routed through a single measurement point, and spend emitted as an alertable metric rather than a monthly report. Enforce per-task ceilings set near the 99th percentile of observed executions inside the agent framework, per-agent rate limits at the gateway, and tenant quotas — then decide explicitly per agent whether budget exhaustion degrades, queues, or escalates, because silent degradation converts a cost control into a correctness problem. Finally, translate spend into cost per successful outcome and cost per unit of business value, since those are the only figures a sponsor can evaluate and the only ones that reveal whether an agent’s economics improve with volume.