What is Cost Attribution?
ObservabilityAssigning spend to the step, run, agent, and tenant that caused it, rather than reading a monthly aggregate. The prerequisite for cost bounds: you cannot cap what you cannot attribute.
Why It Matters
Agent spend does not arrive as a clean line item. A run fans out into model calls, tool invocations, retries, and sub-agent handoffs, and the invoice at the end of the month explains none of it. Cost attribution assigns spend to the step, run, agent, and tenant that caused it, so a spike has a name attached.
It is also the precondition for every other cost control. Cost bounds cannot hold against spend nobody attributed, and cost creep is invisible until someone asks which run or tenant produced the number.
What Gets Attributed
Per step. Each span carries its token counts and tool-call cost, so a run’s expense decomposes into the steps that caused it.
Per run. The full trajectory’s total, which is the unit that matters for questions like “what does this workflow cost.”
Per agent and tenant. Which agent in a multi-agent system, and which customer in a multi-tenant deployment, produced the spend.
Where It Breaks
The aggregate invoice is the failure shape: spend visible monthly, in total, with no way to connect a spike to the run that caused it. A $47K delegation loop looks like a billing surprise instead of a traceable incident.
The second break is attribution without action. Costs recorded faithfully and reviewed never: dashboards that answer “what happened” on a cadence slower than the spending. Attribution earns its keep when it feeds bounds and alerts that fire before the invoice does.
How Flytebit Handles It
Per-call and per-step attribution is part of the telemetry we instrument in every observability engagement: spend attached to the span that caused it, rolled up per run, per agent, per tenant, and wired to the bounds that act on it. The $47K loop that motivates this design is dissected in Observability for Agentic AI Governance.