How One Enterprise Backend Team Rebuilt Their AI Agent Cost Attribution Pipeline After Six Months of Silent Inference Spend Misallocation
In the spring of 2026, a backend platform team at a mid-sized financial services company made a discovery that sent a quiet shockwave through their engineering and finance departments. Their AI agent cost chargeback system, the one that had been dutifully generating monthly reports for six months, had been lying to them. Not dramatically. Not obviously. Just quietly, consistently, and expensively.
Three business units had been systematically over-billed for inference spend. Two others had been getting a free ride. And nobody had noticed, because the numbers always looked plausible. This is the story of how they found the bug, what caused it, and how they rebuilt their attribution pipeline from the ground up.
The Setup: A Shared AI Agent Platform Serving Multiple Business Units
The company, which we will call Meridian Financial (the real name withheld at their request), had built a centralized AI agent platform in late 2025. The platform orchestrated a suite of specialized AI agents handling tasks across five business units: retail banking, wealth management, compliance, fraud detection, and internal IT operations.
Each business unit had its own workflows, its own data, and its own budget. The platform team was responsible for the shared infrastructure, including the multi-model inference layer that routed requests to a mix of hosted frontier models and internally deployed open-weight models. Costs were meant to be charged back to each business unit based on their proportional consumption of inference resources.
On paper, the architecture was sound:
- A central orchestration layer managed agent workflows using a graph-based execution engine.
- A tagging system attached a
tenant_idandworkflow_idto every inference request at dispatch time. - A cost aggregation service consumed usage logs from the inference layer, joined them against a pricing table, and rolled up totals by
tenant_idfor monthly chargeback reports.
Simple. Auditable. Broken.
The Discovery: A Compliance Analyst Asks an Uncomfortable Question
The problem surfaced not from an engineering audit, but from a budget conversation. The compliance business unit had noticed that their AI-related line item had grown 340% over six months, while their actual usage of the platform had only modestly increased. A senior analyst flagged it to the platform team as a billing question, expecting a quick explanation.
What they got instead was three weeks of investigation.
The platform team's initial response was to pull raw inference logs and cross-reference them against the chargeback reports. The numbers did not reconcile. Specifically, the team found that the aggregated token counts in the chargeback reports were consistently higher for compliance workflows than what the raw logs showed. The inverse was true for the fraud detection unit: their reported spend was significantly lower than their actual log-level consumption.
The delta was not random noise. It was systematic, and it had been accumulating since the platform launched.
Root Cause: Three Compounding Bugs in the Attribution Pipeline
After a thorough forensic review, the team identified three distinct issues that had combined to produce the misallocation. Each one alone might have been caught quickly. Together, they created a plausible-looking but fundamentally incorrect output.
Bug 1: Async Workflow Context Leakage
The orchestration engine used an async task queue to fan out agent sub-tasks in parallel. When a parent workflow spawned multiple child tasks, it passed the tenant_id via a shared execution context object. The problem was that the context object was not being deep-copied before being passed to child tasks. It was being passed by reference.
In practice, this meant that when a high-volume fraud detection workflow ran concurrent sub-tasks, and a compliance workflow happened to initialize in the same execution thread pool window, the compliance workflow's context occasionally overwrote the tenant_id field in the shared reference. Subsequent inference calls from fraud detection sub-tasks were then tagged with the compliance tenant_id.
The race condition was non-deterministic but statistically biased. Fraud detection workflows were longer-running and more computationally intensive. Compliance workflows tended to initialize more frequently but with shorter lifespans. The overlap pattern consistently favored context leakage in one direction.
Bug 2: A Silent Default in the Pricing Table Join
The cost aggregation service joined inference log records against a pricing table to convert token counts into dollar amounts. The pricing table was keyed by model_id. When a new model was added to the inference layer (a more capable reasoning model introduced in Q1 2026 for wealth management workflows), its model_id was not immediately added to the pricing table.
Rather than throwing an error or flagging unmatched records, the aggregation service had a silent fallback: unmatched model_id values defaulted to the pricing entry for the cheapest available model. The wealth management unit's expensive reasoning model calls were being priced at the rate of a lightweight summarization model, roughly one-eighth the actual cost.
The missing pricing entry was added within two weeks, but nobody realized that historical records had been silently mispriced. The aggregation service ran on a rolling window and did not backfill corrected costs.
Bug 3: Workflow Retry Events Were Double-Counted
The third bug was the most subtle. The inference layer emitted usage events to a message queue. The cost aggregation service consumed these events and wrote them to a time-series cost store. The message queue had at-least-once delivery semantics, meaning that under certain failure conditions, events could be delivered more than once.
The aggregation service had deduplication logic based on a composite key of request_id and timestamp. However, when the orchestration engine retried a failed inference call, it generated a new request_id but reused the same workflow_id and tenant_id. The deduplication logic correctly identified these as distinct events (because they had distinct request_id values), but the cost store had no mechanism to distinguish between a genuine new inference call and a retry of a previously failed one.
Compliance workflows had a significantly higher retry rate due to the nature of their prompts (longer context windows, stricter output format requirements, and higher model temperature settings). This meant compliance was being charged not just for successful inference, but for every failed attempt that preceded it.
The Damage Assessment: Six Months of Incorrect Chargebacks
Once all three bugs were understood, the team ran a full historical reprocessing of raw inference logs. The findings were stark:
- Compliance had been overcharged by approximately $214,000 over six months, driven primarily by context leakage and retry double-counting.
- Fraud Detection had been undercharged by approximately $189,000, the primary beneficiary of the context leakage bug.
- Wealth Management had been undercharged by approximately $97,000 due to the silent pricing table default.
- Retail Banking and IT Operations showed minor discrepancies in both directions, largely attributable to low-level retry noise.
The total misallocation across the platform exceeded $500,000 in gross dollar terms (counting both over- and under-charges). For a platform that had been positioned internally as a cost-efficient shared service, this was a significant credibility problem.
The Rebuild: Designing a Trustworthy Attribution Pipeline
The team did not patch the existing system. They made the decision to rebuild the attribution pipeline from scratch, using the three bugs as design requirements for the new architecture. Here is what they built.
1. Immutable Context Propagation with Trace-Bound Tenant Identity
The new orchestration engine treats tenant context as immutable once set at workflow initialization. Every child task receives a deep copy of the parent context, and the tenant_id is bound to the distributed trace ID using OpenTelemetry span attributes. This means that even if a child task's local context is somehow corrupted, the inference layer can independently validate the tenant_id against the trace metadata before tagging usage events.
The team also added a runtime assertion layer: any inference call whose span-level tenant_id does not match the task-level tenant_id raises an alert rather than silently proceeding. This turns a silent misattribution into a visible operational event.
2. Strict Pricing Table Validation with Deployment Gates
The new cost aggregation service treats an unresolved model_id as a hard error, not a soft fallback. When a new model is deployed to the inference layer, a pre-deployment check validates that a corresponding pricing entry exists in the cost store. If it does not, the deployment is blocked.
Additionally, the pricing table now has a versioning system. Every cost record is stamped with the pricing table version that was used to calculate it, enabling retrospective audits to identify any records that were priced under an incorrect or incomplete table version.
3. Semantic Event Deduplication with Retry Lineage Tracking
The new pipeline distinguishes between original inference calls and retries at the event schema level. The orchestration engine now emits a retry_of_request_id field whenever it retries a failed call. The cost aggregation service uses this field to link retry events to their parent request and applies a configurable policy for how retry costs are attributed.
In the current configuration, the first retry is charged to the tenant (since retries are often caused by prompt engineering choices within the tenant's control), but subsequent retries beyond the first are charged to a shared infrastructure cost pool, reflecting the possibility of platform-level instability rather than tenant-driven behavior.
4. A Real-Time Attribution Dashboard with Anomaly Alerts
Perhaps the most operationally important addition is a real-time attribution dashboard that surfaces per-tenant spend at the workflow level, updated every 15 minutes. The dashboard includes anomaly detection logic that flags any tenant whose spend trajectory deviates more than two standard deviations from their 30-day rolling baseline.
This is the safeguard that would have caught the compliance overcharge within days rather than months. The team refers to it internally as their "canary for the cost plane."
Lessons Learned: What Every Enterprise AI Platform Team Should Take Away
The Meridian Financial story is not unique. As enterprise AI agent platforms have matured through 2025 and into 2026, the complexity of multi-tenant cost attribution has quietly become one of the most underestimated engineering challenges in the space. Here are the durable lessons from this case.
Plausible Numbers Are Not Correct Numbers
The most dangerous property of the misallocation was that the reports looked reasonable. No individual business unit's bill was so wildly out of range that it triggered immediate scrutiny. In multi-tenant systems with variable workloads, "plausible" is a very low bar. Build systems that can prove correctness, not just produce believable output.
At-Least-Once Delivery Requires Semantic Deduplication
Using a message queue with at-least-once semantics for cost-critical event pipelines without semantic deduplication is a liability. Deduplication on request_id alone is insufficient when your upstream system can generate new IDs for logically equivalent retries. Model the business semantics of your events, not just their technical identifiers.
Silent Defaults Are Silent Bugs
Any system that silently falls back to a default value when it encounters an unexpected input is a system that will eventually produce incorrect output without telling you. In cost pipelines especially, fail loudly. An error that stops a report is far less damaging than a report that silently lies.
Tenant Identity Must Be Cryptographically Anchored, Not Contextually Assumed
Passing tenant identity through mutable shared state in an async execution environment is asking for race conditions. In 2026, with distributed tracing infrastructure widely available, there is no excuse for not anchoring tenant identity to immutable trace-level metadata. Treat tenant_id with the same care you would treat an auth token.
FinOps for AI Is a First-Class Engineering Discipline
The team at Meridian Financial had excellent engineers. The attribution pipeline was not built carelessly. It was built without treating cost correctness as a first-class requirement. In the era of agentic AI, where a single workflow can spawn dozens of inference calls across multiple models, the financial surface area of a bug in the cost plane is enormous. FinOps for AI deserves the same rigor as security or reliability engineering.
Where Meridian Financial Stands Today
Six months after the rebuild, the new attribution pipeline has processed over 40 million inference events without a single misattribution alert escalating to an incident. The compliance business unit received a credit reconciliation. The fraud detection and wealth management units were invoiced for the historical underbilling, a conversation that required careful handling but was ultimately resolved without significant friction, largely because the team came prepared with a full audit trail and a credible explanation of what had gone wrong.
More importantly, the platform now has a cost attribution system that the business units actually trust. Chargeback reports are no longer a source of skepticism. They are a tool that business unit leads use proactively to optimize their own AI workflow designs, choosing simpler models for routine tasks and reserving more capable (and expensive) models for genuinely complex reasoning steps.
That shift, from cost attribution as a billing formality to cost attribution as a product optimization signal, may be the most valuable outcome of the entire painful episode.
Conclusion: Build the Cost Plane Like It Matters, Because It Does
If your organization is running a shared AI agent platform with multiple tenants or business units, the question is not whether your attribution pipeline has bugs. The question is whether you have the observability to find them before they compound for six months.
Audit your context propagation. Validate your pricing table completeness at deployment time. Treat retry events as semantically distinct from original calls. And build a real-time anomaly detection layer over your cost data. These are not advanced engineering practices. They are table stakes for any platform where inference spend is measured in six or seven figures annually.
The cost plane is not a reporting afterthought. It is infrastructure. Build it accordingly.