The Economics of Agentic Al: You Can't Control Costs You Can't Trace

In May 2026, a story spread that an unnamed company had spent $500 million on Claude in a single month after failing to set employee usage limits.

It had every ingredient of a perfect enterprise-AI cautionary tale: a shocking number, an anonymous company, an avoidable configuration error, and a technology moving faster than its buyers could govern it.

It also had almost no evidence. The real issue was never the invoice. It is AI agent cost attribution: whether a company can trace spend back to a workflow, an owner, and an outcome.

Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value as leading causes, which makes attribution a boardroom question, not just an engineering one.

The $500 million claim traces back to one unnamed consultant describing one unnamed client. No invoice, workforce size, token count, or contract has surfaced.

A skeptical analysis from Stax worked through the economics and argued that ordinary Claude Code usage would land far below half a billion dollars, even at large-enterprise scale. The responsible conclusion is not that the event happened. It is that we cannot verify it.

Fortunately, the architecture problem does not depend on the viral number. The named cases are less cinematic and more useful. According to reporting on comments from Uber's CTO, the company exhausted its planned 2026 AI coding budget within the first four months, as adoption expanded across roughly 5,000 engineers. Reported monthly costs for heavy users reached $500 to $2,000.

Microsoft reportedly moved much of one division away from Claude Code after internal usage costs rose, steering teams toward GitHub Copilot CLI. These are not half-billion-dollar accidents. They are recognizable enterprise rollouts colliding with a consumption model their budgets were not designed to represent.

Why AI Agent Costs Don't Behave Like Traditional Software Spend

Traditional software procurement organizes spend around a human and a license. The model works because human usage has a natural ceiling. An employee can only click, type, or review for so many hours a day.

An agentic AI system, one that autonomously plans and executes multi-step tasks, calling tools or data sources to complete a goal without step-by-step human instruction, breaks that ceiling.

One developer can start a workflow that plans, searches a repository, calls tools, invokes models repeatedly, retries failed steps, delegates to subagents, and runs verification. Parallel agents keep consuming compute while the developer moves to something else.

The employee may still have a "seat," but the seat no longer predicts consumption.

This is why agent cost behaves more like infrastructure than conventional SaaS. It is variable, workload-dependent, sensitive to model choice, and able to scale independently of headcount. It also combines multiple meters:

• Input and output tokens
• Cached context and long-context premiums
• Tool and API calls
• Data queries and egress
• Sandbox or accelerator time
• Retries, evaluators, and background loops

A procurement limit can stop total spending. It cannot tell a company whether that spending produced value.

In short: a hard usage cap controls the size of the bill, not the value behind it.

FinOps, the discipline of tracking, forecasting, and governing cloud and AI spend across teams, has moved from a niche practice to a mainstream requirement. The 2026 State of FinOps report found that 98% of surveyed FinOps practitioners now manage AI spend, up from 31% in 2024. AI has moved from an experimental line item into the operating scope of technology-cost teams.

Yet a provider invoice usually answers only one question: how much did we spend? AI cost attribution answers a different one: which product, team, and workflow generated that spend, and did it produce anything worth the money?

The questions an operator actually needs are more specific:

• Which product and workflow generated the cost?
• Which team or business outcome owned it?
• Which model, tool, and data product were involved?
• How much came from useful execution versus retries or abandoned loops?
• What did the workflow produce?
• Which work should be routed to a smaller model, cached, batched, or stopped?

Those answers require context to travel with execution. Reconstructing them from a monthly invoice is slow and often impossible. This is the durable lesson behind the disputed $500 million story: Attribution is the circulatory system.

In short: an invoice tells you the total. Attribution tells you what it was for.

How to Build AI Cost Attribution Into the Agent Harness

Cost control should begin when an agent proposes work, not after the provider closes the billing period. That requires moving the check into the harness, the orchestration layer that manages an agent's model calls, tool calls, and retries, rather than leaving it to the billing dashboard.

Take the refund-investigation agent used throughout this series, first introduced when we mapped harness engineering onto enterprise data platforms. Before it queries data or calls a frontier model, the harness already knows the identities of the user and agent, the support workflow, the requested data products, and a correlation ID, a single identifier attached to every step of a workflow so the full path can be traced later. That context becomes the basis for cost policy.

A runtime cost path works like this:

1. Estimate. The router considers prompt size, model, tool plan, expected data scan, and maximum iterations.
2. Attribute. The request receives product, team, workflow, environment, and business-purpose tags.
3. Route. A policy selects the cheapest model and execution path that meet the task's quality and latency requirements. This is an active research problem: RouteLLM's preference-based routers cut costs by more than half in benchmark testing without sacrificing response quality, which is the same trade-off a production router has to make on every call.
4. Enforce. Per-call, per-workflow, and per-domain limits stop or require approval for work outside the budget envelope. Recent research on budget-aware tool use found that simply giving an agent a bigger allowance doesn't improve results; the agent has to be aware of the budget and adapt its own behavior to it, which is the same principle behind per-workflow enforcement.
5. Observe. Tokens, queries, tool calls, retries, latency, and outcomes stream under one correlation ID.
6. Adapt. Repeated waste becomes a routing rule, tool redesign, cache, or tighter loop limit.

The enforcement point may be an AI gateway (a control layer that intercepts and governs model API calls), an agent runtime, or a data-query broker. The data platform matters here because data-intensive agent costs combine model consumption with the queries the model triggers. A platform cannot meter a direct call to an external SaaS tool unless that call passes through a governed interface.

How DataOS Puts AI Cost Attribution Into Practice

DataOS turns that six-step path into infrastructure instead of policy on paper.

Lens, DataOS's semantic layer, carries the product, team, workflow, and business-purpose tags at the point of query, so attribution does not depend on an agent remembering to log its own metadata. The Data Product Hub surfaces every governed data product an agent can call, which is what makes the fourth and fifth questions in the attribution gap, above, answerable in near real time rather than reconstructed after the fact.

Bifrost, the API and agent gateway, sits in front of every model and tool call and functions as the AI gateway described above: it estimates, routes, and enforces budget policy before a request executes rather than after. Access policy in DataOS is set at the point a data product is built, not bolted on afterward, so a cost or entitlement rule travels with the product instead of living in a separate system someone has to remember to check.

Policy enforcement points (PEPs) sit at each call site and apply the limit in real time; policy decision points (PDPs) hold the actual rules, so a change to a team's budget or a model's approved use case propagates everywhere at once instead of requiring a redeploy. Tenant-level monitoring tracks whether the compute backing these calls is healthy and has the capacity teams need, which is the "Observe" step made operational rather than aspirational.

The result is that the control plane, the layer that enforces policy across a system, spans model routing, agent execution, and data access by design. Cost becomes a property of the workflow, not a surprise on a vendor account.

AI Budget Caps vs. Cost Attribution: Why You Need Both

It would be a mistake to argue that architecture makes basic spend limits unnecessary.

Organizations should still use provider budgets, alerts, quotas, and rate limits. An individual tool should not be able to consume an unbounded share of a company's budget. High-cost models should not be the default for low-value tasks. Autonomous loops need time, iteration, and token ceilings.

Those controls answer one question: how much loss will we tolerate before the system stops? Attribution answers a different one: which work deserves funding? Most organizations still cannot answer that second question. McKinsey's State of AI research found that only 39% of organizations attribute any level of EBIT impact to AI, and most of those attribute less than 5%. A spending cap does not fix that gap. It just puts a ceiling on the uncertainty.

Uber's reported experience illustrates the distinction. Exhausting an annual budget in four months is a forecasting and control failure. But the company also reported high adoption and substantial AI-generated code.

A lower cap alone cannot determine whether the tool was wasteful, underbudgeted, or valuable enough to justify reallocating funds. That requires linking cost to engineering outcomes: review burden, incidents, cycle time, and shipped product value. BCG's research on enterprise AI value found that 60% of companies report only minimal revenue or cost benefit from their AI investment despite substantial spend, while a small group of "future-built" firms extract several times the return. The gap between those two groups is rarely a model-quality problem. It is a measurement problem.

The same distinction applies outside software development. A customer-support agent that costs $20 per resolved case may be excellent or terrible, depending on resolution quality, escalation reduction, and customer retention. Cost without an outcome denominator is just a large number.

In summary, a cap limits damage. Only attribution tells you whether the spend was worth it.

Questions to Ask AI Vendors About Cost Governance

AI evaluations still concentrate on capability: benchmark performance, answer quality, context length, and tool support. Enterprise buyers should treat financial control as a product requirement, not an afterthought.

Ask vendors:

• Can usage be attributed to a user, agent, workflow, team, and business purpose?
• Are those dimensions available in near real time?
• Can we set hard and soft budgets at each level?
• Can policy route requests by cost, quality, latency, and data sensitivity?
• Do retries, background work, and evaluator calls appear in the same trace?
• Can we export granular consumption and outcome data?
• What happens when a limit is reached: fail, degrade, queue, or request approval?

Vendors have an economic incentive to reduce friction on consumption. Buyers have an equally legitimate incentive to make consumption explainable.

The next notorious AI bill may have four zeroes or nine. The exact number is not the strategic issue. If a company cannot connect that bill to a workflow, an owner, a policy decision, and an outcome, it still does not have cost governance.

It has an invoice.

Read more from this series:

1. Why Cheaper AI Tokens Are Increasing Enterprise AI Costs (Part 1) and
2. Why Your Data Platform Isn't Wired for AI (Part 2).