How One Enterprise Backend Team Discovered Their Multi-Agent Cost Attribution Model Was Silently Misallocating LLM Token Spend Across Business Units , and the Chargeback Architecture They Built Before Q3 2026 Budget Cycles Locked In Broken Baselines

By the time the anomaly surfaced, it had been running silently for nearly eight months. A mid-sized financial services firm, which we'll call Meridian Capital Group (a composite case study based on patterns observed across several real enterprise teams), had rolled out a sophisticated multi-agent AI platform in late 2024. By early 2026, that platform was processing millions of LLM inference calls per day across six distinct business units: Retail Banking, Wealth Management, Risk and Compliance, Operations, Marketing, and the internal IT Service Desk.

The problem was not that the system was broken. It was that the system appeared to be working perfectly, right up until a sharp-eyed FinOps analyst noticed that Retail Banking's AI budget had been quietly subsidizing the Compliance team's document-parsing workloads for the better part of a year.

What followed was a three-month sprint to build a proper LLM cost chargeback architecture before the Q3 2026 budget cycle locked in what would have been deeply flawed financial baselines for every department in the organization. This is that story.

The Setup: A Shared Inference Gateway and a False Sense of Control

Meridian's backend team had done a lot of things right. They had deployed a centralized inference gateway, built on top of a managed LLM API layer, routing requests from all six business units through a single authenticated endpoint. They had tagging conventions. They had dashboards. They had what looked, on the surface, like a mature observability stack.

The multi-agent orchestration layer sat on top of this gateway. Each business unit ran its own set of agents: some autonomous, some human-in-the-loop, and some hybrid. These agents would spin up sub-agents dynamically, pass context between them via shared memory stores, and occasionally invoke shared utility agents maintained by the central platform team. Think of a Compliance agent that would call a shared "document summarization" sub-agent, which was also used by Marketing for campaign brief generation and by Operations for vendor contract review.

This is where the attribution model started to silently collapse.

The Root Cause: Shared Sub-Agents and Orphaned Token Charges

The core issue came down to how the team had implemented cost tagging at the gateway level. When a parent agent from, say, the Wealth Management team initiated a chain of sub-agent calls, the initial request carried the correct business_unit: wealth_management tag. But when that parent agent invoked a shared utility sub-agent, the sub-agent's subsequent LLM calls were issued under the sub-agent's own service identity, not the originating business unit's identity.

The result: token charges generated by shared sub-agents were being attributed to whichever cost center owned the sub-agent's service account, not the business unit that had triggered the workload. In Meridian's case, the shared utility sub-agents were registered under the central platform team's cost center, which then rolled up (incorrectly, it turned out) into Retail Banking's budget allocation due to a legacy mapping error in their cloud billing configuration.

The team identified four specific failure patterns once they started digging:

• Orphaned context window inflation: Shared sub-agents were receiving large context payloads assembled by parent agents. The token cost of processing that context was charged to the sub-agent's owner, not the business unit that assembled and passed the context.
• Async callback misattribution: Some agents used asynchronous task queues. By the time a deferred LLM call was executed, the original request's trace context had been dropped, and the charge landed in a catch-all "unattributed" bucket that was being silently swept into Retail Banking's ledger on a monthly basis.
• Retry amplification: The orchestration layer had an aggressive retry policy for failed LLM calls. Retried tokens were being logged as new, independent charges with no link to the original request's attribution tag, effectively double-counting certain workloads.
• Model routing drift: The gateway's smart routing logic would sometimes upgrade a request from a cheaper model tier to a premium model tier based on prompt complexity. The cost delta from that upgrade was being logged at the infrastructure level, below the attribution tagging layer, making it invisible to business-unit-level reporting.

Why It Stayed Hidden for Eight Months

This is the part of the story that most engineering leaders find uncomfortable, because it reflects a gap that is far more common than anyone wants to admit.

The dashboards showed total spend. They showed spend by model. They showed spend by time of day. What they did not show, with any granularity, was spend by originating business intent. The team had confused infrastructure-level observability with financial attribution. These are not the same thing.

Additionally, because all six business units were growing their AI usage simultaneously throughout 2025, the absolute dollar figures for every department were climbing. No single department's costs were declining in a way that would have flagged an obvious anomaly. The misallocation was hidden inside a rising tide of legitimate growth.

The analyst who eventually caught it did so not by looking at dashboards, but by doing something refreshingly old-fashioned: she cross-referenced the number of agent invocations logged by the Compliance team's application layer against the token charges attributed to Compliance in the billing system. The ratio was off by a factor of roughly 2.3. That discrepancy was the thread that unraveled everything.

The Chargeback Architecture They Built

Once the problem was fully scoped, the backend team had roughly ten weeks before Q3 2026 budget submissions needed to be finalized. They built fast, and they built deliberately. Here is the architecture they landed on.

1. Propagated Trace Context as the Attribution Source of Truth

The team replaced their static tagging model with a distributed trace propagation system. Every agent invocation, regardless of whether it was a parent agent, a child agent, or a shared utility sub-agent, was required to carry a propagated attribution envelope in its request headers. This envelope contained:

• The originating business unit identifier
• The originating use case or workflow identifier
• The root trace ID from the initiating request
• A cost responsibility flag (either "originator pays" or "shared pool," explicitly declared)

The inference gateway was updated to extract this envelope at the point of every LLM API call and write it directly into the billing event record before the charge was logged. This eliminated the orphaned attribution problem entirely for synchronous call chains.

2. A Dedicated Attribution Service for Async Workloads

For asynchronous and deferred workloads, the team introduced a lightweight Attribution Correlation Service. When an agent enqueued a deferred LLM task, it would register the task ID against its attribution envelope in a fast key-value store (they used a Redis cluster already in their stack). When the deferred task was eventually executed, the inference gateway would look up the task ID and retrieve the correct attribution context before logging the charge.

The TTL on these records was set to 72 hours, covering the longest observed async processing delay in their system with comfortable margin.

3. Retry Charges Linked to Root Request

The retry attribution fix was the simplest of the four. The orchestration layer was updated to pass the original request's trace ID and attribution envelope to every retry attempt. Retry charges were flagged with a retry: true marker and linked to the root request in the billing ledger, allowing finance to choose whether to count retries as separate line items or aggregate them under the original charge. The default was set to aggregate, which eliminated the double-counting issue immediately.

4. Model Upgrade Cost Delta Attribution

The model routing drift problem required the most architectural thought. The team introduced a routing decision log at the gateway level. Whenever the smart router upgraded a request to a higher model tier, it logged both the originally requested model and the actual model used, along with the cost delta between the two. This delta was tagged with the same attribution envelope as the base request.

This gave finance two useful levers: the ability to charge the business unit for the full actual cost (including the upgrade delta), or to charge the business unit for the originally requested model tier and absorb the upgrade delta into a central platform cost pool. Meridian chose the former for most cases, with a negotiated exception for Compliance workloads where the routing upgrades were driven by regulatory document complexity rather than business unit choice.

5. A Real-Time Chargeback Dashboard with Business Unit Sign-Off

The final piece was organizational, not technical. The team built a real-time chargeback dashboard that gave each business unit's finance partner direct read access to their attributed token spend, broken down by workflow, model tier, and agent type. Critically, the dashboard included a monthly sign-off workflow: business unit finance partners were required to review and acknowledge their attributed costs before they were finalized in the billing system.

This created accountability on both sides. Business units could dispute attributions before they were locked. The platform team had a paper trail showing that costs had been reviewed and accepted. And the FinOps team had clean, auditable data flowing into the Q3 budget cycle.

The Numbers, Once the Dust Settled

When the corrected attribution model was run retroactively against the prior eight months of billing data, the results were significant:

• Retail Banking had been overcharged by approximately 34% relative to its actual LLM consumption.
• Risk and Compliance had been undercharged by approximately 61%, primarily due to its heavy use of shared document-parsing sub-agents.
• Operations had been undercharged by approximately 28% due to async callback misattribution.
• The remaining three business units showed smaller variances, all within a 15% band, which the team considered acceptable given the complexity of the system.

The total misallocation across all business units, measured against what correct attribution would have shown, was approximately $840,000 over the eight-month period. Not a catastrophic number for a firm of Meridian's size, but more than enough to have materially distorted Q3 2026 budget baselines if left uncorrected. Compliance, for instance, would have entered Q3 planning with an AI budget roughly 60% lower than its actual consumption pattern warranted, virtually guaranteeing a budget overrun by Q4.

What This Means for Every Enterprise Running Multi-Agent AI

Meridian's story is not an edge case. It is a preview of where a significant number of enterprise AI programs are right now in early-to-mid 2026. The pattern is consistent: teams build multi-agent platforms quickly (often correctly), instrument them for engineering observability (often adequately), and then assume that engineering observability is the same as financial attribution (almost always incorrectly).

A few principles stand out from this case study that apply broadly:

• Attribution must be propagated, not inferred. You cannot reliably reconstruct who should pay for a token charge after the fact by looking at which service account made the API call. The originating business intent must travel with the request through every hop in the agent chain.
• Shared utility agents are a hidden cost socialization mechanism. Every shared agent in your architecture is a potential cost attribution leak. This does not mean you should not build shared agents; it means you must explicitly model how their costs are allocated before you deploy them.
• Async workloads require explicit attribution persistence. If your agents defer work to queues or background jobs, the attribution context must be stored and retrieved, not assumed to survive the async boundary.
• Model routing decisions are a financial decision, not just an engineering decision. If your gateway upgrades requests to more expensive models, that decision has a cost owner. Make sure that owner is identified at routing time, not discovered at billing time.
• Budget cycles will lock in whatever baselines you give them. Finance teams are not AI engineers. They will plan Q3, Q4, and beyond based on the numbers that land in their spreadsheets. If those numbers are wrong, the plans built on them will be wrong, and fixing it mid-cycle is far more painful than getting it right before the cycle begins.

Getting Ahead of It: A Practical Starting Point

If you are running a multi-agent platform and you are not certain your attribution model is accurate, here is a simple diagnostic to run this week. Pull your last 30 days of LLM billing data. Cross-reference the token charges attributed to each business unit against the number of agent invocations logged by each business unit's application layer. If the ratio is not consistent across business units, you likely have an attribution problem. The size of the inconsistency will tell you how urgently you need to act.

The good news from Meridian's experience is that the fix, once the problem is properly scoped, is an engineering problem with a clean engineering solution. Propagated trace context, an attribution correlation service for async workloads, and a routing decision log will address the vast majority of misattribution patterns seen in production multi-agent systems today.

The bad news is that the window to fix it before Q3 2026 budget cycles finalize is narrowing. Teams that have not started this work yet are operating on borrowed time, and the baselines being set right now will shape AI investment decisions well into 2027.

Conclusion: The Silent Tax of Broken Attribution

Meridian's FinOps analyst found the problem by doing the math by hand. Most organizations will not be that lucky. The misallocation will flow quietly into budget models, shape headcount decisions, influence which business units are seen as "efficient" AI consumers and which are seen as profligate, and ultimately determine where AI investment gets directed in the next planning cycle.

Getting LLM cost attribution right is not a nice-to-have for enterprise AI programs in 2026. It is a foundational requirement for making sound financial decisions about AI at scale. The teams that recognize this now, and build the chargeback architecture to support it, will enter their next budget cycle with something genuinely rare: numbers they can actually trust.

And in enterprise AI, right now, that is a significant competitive advantage.