Agent Cost Attribution Across Multi-Agent Pipelines
Production multi-agent systems hide cost across four separate problems that compound invisibly.
Multi-agent pipelines break the basic assumption that older observability tools were built on: one request, one bounded execution path. When agents spawn sub-agents, retry failures, fan out into parallel workers, and share context across tool calls, the token bill stops behaving like a single invoice and starts behaving like a chain reaction.
A single well-prompted call has a cost you can predict before you send it. The CAL framework's analysis of a three-agent pipeline (planner, executor, reviewer) found that the same task burns substantially more tokens across all three agents than one careful call would. That gap doesn't come from bad prompting. It comes from mechanics the billing layer has no way to break apart. A dashboard showing total token spend tells a team what they owe; it doesn't show which agent spent it, which tool call dragged the context window out, or whether the orchestration layer itself is adding cost. Closing that gap means treating multi-agent cost as four separate mechanical problems, not one dashboard problem. Each one compounds differently, and each one hides in a different place.
Context duplication: how orchestrator prompts compound across every subagent spawn
Picture an orchestrator that spawns three subagents, and each of those subagents calls three tools in turn. That alone puts four context windows running at once: the orchestrator's and one for each subagent, every one of them carrying the full conversation history it was handed. Four windows doesn't sound like much until you notice that each one is paying, separately, for context the orchestrator already paid for once.
The duplication gets worse once tools enter the picture. When a tool call returns a large JSON blob, that blob gets attached to the next LLM call whether the agent actually needs all of it or not. Nobody is pulling the specific fields that matter. The system just pushes the whole thing forward, and the agent pays to read data it never asked for.
Agents handing off work produce context bleed. Agent A builds up a large working memory over the course of its task. Agent B gets spawned to do something small, maybe summarize a result or check one condition, and it gets handed Agent A's entire memory anyway, because that's what the harness has on hand to attach. The node that needed five lines of context pays for five thousand. The cost of specificity lands on the wrong node every time this happens.
A standard trace does not capture any of this. The duplicate tokens arrive at each subagent looking like ordinary input tokens, generated fresh, when really they're inherited. Nothing in a typical tracing stack distinguishes "this agent produced this context" from "this agent was handed this context and had no choice but to pay for it." From the outside, a bloated context window and a genuinely necessary one look identical.
Retry accumulation: how each failed attempt makes the next one more expensive
Retries don't cost a flat fee each time they fire. They cost more each time. A tool-call failure triggers a retry with the full prior conversation history still attached, and that retry adds its own tokens on top of what was already there. By the time a call has failed four times, the fifth attempt is carrying the weight of all four previous ones. It's a cost that climbs every time the agent tries again.
Multi-agent systems fail often in production, and most of those failures trace back to coordination issues between agents. Every one of those failures triggers a full retry, with its own accumulated context, its own token cost. Hourly spend can multiply with no single call ever throwing an error, a pattern the observability literature calls a silent cost storm. Nothing crashes. Nothing pages anyone. The bill just climbs.
Consider a planner agent that rebuilds its context from scratch on every retry attempt. A large share of its total budget can go toward that rebuilding, attempt after attempt, and none of it shows up as anything other than ordinary planning cost. The invoice reads "planning." It gives no hint that retries, not planning itself, are driving the number up. Standard monitoring catches error rate well, but it has nothing to say about cost-per-failure or cumulative retry spend, and a pipeline's budget holds up in production only when those two numbers stay in check.
Coordination overhead: the quadratic cost of agent-to-agent communication
Adding more agents to a pipeline makes the cost of getting them to talk to each other grow faster than the headcount does. A five-agent mesh needs ten communication channels. Adding five more agents, for ten total, makes the channel count more than double. It jumps to forty-five. Every new agent has to coordinate with every agent already in the system, not just hand off to the next one in line, which is the quadratic cost underneath any mesh or hub-and-spoke design.
In typical hub-and-spoke setups, that coordination messaging alone can eat close to a third of the total token budget. Not the task. Not the actual work the pipeline was built to do. Just the overhead of agents passing state and status back and forth so the system holds together.
The most expensive specific version of this appears in how orchestrators manage subagent output. An orchestrator that re-summarizes every subagent's result before dispatching the next task carries that full accumulated summary into each new context window. Each dispatch adds the previous summary on top of the last, multiplying the orchestrator's own token spend compared to a design that runs subagents in parallel and aggregates once at the end.
This creates its own blind spot on the invoice. Planning tokens and execution tokens look the same once they're billed, so there's no way to tell, after the fact, whether the orchestrator's coordination work made up a small slice of total spend or ate the lion's share of it. The coordination cost gets folded invisibly into what looks like ordinary execution.
Memory injection: the cost component that no production observability tool currently reports
Every node in a multi-agent workflow pulls context from memory before it generates anything, and that retrieved context gets billed as input tokens at the exact same per-token rate as the system prompt or the user's own query. Standard observability tools report total input tokens as one number. They don't separate what a node generated from what it was simply handed. That means this cost component doesn't appear as its own line anywhere in a standard stack, because nothing in the stack is built to compute it separately.
Researchers Vivek Kumar Singh, Preeti Priyam, and Gautam Bhowmick gave this problem a name and a method in a September 2026 paper (arXiv:2609.23790). They introduce what they call Total Cost of Agency, a decomposition of multi-agent workflow spend into five parts: base prompt, inference, memory injection, miss penalty, and context accumulation. Breaking the bill into these five pieces makes memory injection visible.
Running this decomposition against real model APIs on a 200-task enterprise benchmark, the researchers found memory injection accounts for roughly twelve percent of total billed cost. Twelve percent is already a meaningful slice of any production budget. The more important finding is how that share moves with pipeline depth. At workflow depth one, injected memory accounts for essentially none of the bill. By depth six, it accounts for over a quarter of billed cost, and the growth across that range is close to perfectly linear (R² of 0.9974). A team that benchmarks a shallow pipeline, two or three steps deep, and then ships something six steps deep is going to find its actual production costs running well ahead of what the benchmark predicted, and memory injection is a measurable reason why.
The method behind this finding matters as much as the number itself. The researchers measure injected tokens directly with a two-pass, non-billable token count, run through the model provider's own tokenizer, rather than estimating injection size from word counts or rough proxies. That direct count adds negligible overhead against normal inference latency. The paper also shows this cost responds to a simple lever: cutting the retrieval window from thirty-two entries down to two lowers injected tokens by more than a quarter, with accuracy holding within the range you'd expect from normal seed-to-seed variation. Memory injection is a tuned parameter that nobody is currently watching.
Attribution gaps in the OTel GenAI schema
OpenTelemetry's GenAI semantic conventions are becoming the shared language most teams reach for when tracing agent behavior, and building on that standard rather than a vendor's proprietary SDK keeps a team's options open as the observability market keeps consolidating. But the standard, as it stands, has no concept of who's paying. It doesn't define attributes for tenant, project, or cost center, so none of the four failure modes above come with a built-in way to say which team or which budget they belong to.
That gap matters most at the boundaries between agent calls. Without a team explicitly adding custom attributes and making sure they propagate through W3C trace context headers at every hop, a multi-agent chain loses track of who owns the cost the moment it crosses from one agent to the next. The trace still exists. Someone can see that work happened. Nobody can see which cost center should be charged for it.
Shared infrastructure makes this sharper still. Say one project's pipeline runs first and pays to write a shared system prompt into a model provider's cache. A second project runs later, hits that same cache, and gets a steep discount on a call that would otherwise cost full price. Attribute naively, and the first project eats the entire cost while the second gets a windfall it did nothing to earn. It is a real financial design choice that arises any time two teams share inference infrastructure, and it needs a deliberate answer, not a default.
Three patterns are emerging across the industry to close gaps like these. The first is mandatory metadata tagging at the gateway layer, attributing cost directly to each request as it's made. The second is hierarchical budget enforcement, with alert thresholds set at different tiers so a team catches a budget problem before it becomes a monthly surprise. The third is cost-aware model routing, where the system checks budget headroom before it decides which model to call, rather than finding out afterward that a call was too expensive.
One practice ties these together: rejecting untagged requests outright instead of letting them fall into a default bucket closes the gap. A default bucket is exactly how context duplication and retry costs stay permanently invisible. If an untagged request gets quietly absorbed somewhere, nobody ever goes looking for where it actually came from.
Among the tools built for this layer, Langfuse is a useful reference point for how framework-agnostic instrumentation can work in practice. Acquired by ClickHouse in January 2026, it runs on a backend built for high-volume trace analytics, wraps around any LLM client as a drop-in replacement, and captures tokens, cost, and latency without much setup. That's one option among several a team might weigh when choosing an instrumentation layer, not a verdict on which is correct for every pipeline.
Instrumenting each failure mode: a per-mechanism approach to cost tagging
Attribution that actually works tags tokens by the mechanism that generated them: context carried over from another node, coordination overhead, retry origin, memory injection. Tagging by agent name or pipeline step alone won't catch any of the four problems above, because each one occurs inside a category that looks ordinary from the outside.
For context duplication and coordination overhead, phase tagging is the starting point. Every LLM call should carry a phase tag, plan, execute, verify, or synthesize, written into the system prompt at call time, along with a run ID and an agent role ID. These should be set explicitly when the call is made. Role-based billing takes this further: treat each role in a run, orchestrator, subagent, critic, formatter, as its own billing entity, even if one underlying model happens to fill more than one of those roles across a run. This makes certain waste immediately visible. A formatter that's calling a large-context model to do simple text cleanup is burning money for no reason, and once formatter cost is its own line, that pattern jumps out of aggregate spend. The same tagging makes an orchestrator's re-summarization cost visible as its own phase, separate from whatever the subagents themselves are doing.
Retry chains need their own markers. Tag every LLM call with an attempt index and a parent-call ID, so a chain of retries can be reconstructed after the fact. Cost-per-failure and cumulative retry spend deserve to be tracked as first-class metrics in their own right, not derived from error rate, since error rate is exactly the number that misses a silent cost storm. Where a model decides on its own to retry something, tracing needs to happen at the level of each reasoning pass, not just at the level of the tool call, or the retry's cost gets absorbed into whatever step called it.
Memory injection calls for the exact method the TCA paper lays out: a two-pass, non-billable token count run through the model provider's own tokenizer, measuring injected tokens directly. Instrument this at the node level, capturing token counts before and after memory retrieval, so injected tokens stay separate from the base prompt. Once that's a separate metric per node, retrieval window size becomes a decision with an actual cost basis behind it. Injection share climbing as a pipeline gets deeper is worth tracking over time. If a pipeline is heading toward the depths the TCA paper measured, where injection reached over a quarter of total cost, that's an early signal to shrink the retrieval window before the cost raises the bill at the end of the month.
Shared context needs two different attribution models depending on what it is. Direct attribution, tagging each request at the gateway with project ID, team, pipeline step, and cost center, works well for inference calls that can be tied to a single owner at the moment they're dispatched. Proportional allocation fits better for genuinely shared infrastructure, a vector database query used by five pipelines, a system prompt loaded once but read by multiple projects, where no single request can honestly claim the whole cost. Picking the right one for each kind of spend is what turns a pile of traces into an attribution system a finance team can actually trust.
