AI agents turn one human request into chains of model calls, tool use, retries, and context. The next FinOps challenge is connecting that spend to an outcome.
An engineer gives a coding agent a one-line task: find out why a test is failing and fix it.
The visible interaction is almost trivial. Behind it, the agent searches the repository, retrieves files, calls a model, invokes tools, runs the test suite, reads the error, revises its plan, and tries again. When the test finally passes, the engineer sees one completed task.
The billing system sees something else: a chain of separately metered events.
Finance sees something else again: a monthly total.
Those are three different views of the same work, and none of them necessarily connects what the agent accomplished to what it cost.
That gap matters because the numbers around it are becoming large. Gartner forecasts that direct worldwide spending on AI infrastructure, software, and services will reach roughly $2.6 trillion in 2026, up 47% from 2025. A separate Gartner projection, reported by TechRadar, puts spending on AI agents at $206.5 billion in 2026 and $376.3 billion in 2027. These are forecasts, not audited outcomes, and they do not imply that trillions of dollars are being wasted. They do show why AI economics is becoming a management problem rather than a technical footnote.
The other side of the forecast is less comfortable. Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027 because of escalating costs and unclear business value. That is a prediction, not a measured failure rate, but it captures the tension: spending is accelerating while the systems for explaining its value are still immature.
One request is no longer one unit of work
Software was easier to budget when the dominant unit was a seat, a server, or a subscription. An agent is different. It determines much of its own execution path.
One request might take three model calls. Another might take 300. The path can change based on the model selected, the context retrieved, the tools invoked, the errors encountered, and the agent’s decision about when it has done enough.
Early research illustrates how variable that path can become. A 2026 preprint examining eight frontier models on SWE-bench Verified found that, in its benchmark setting, agentic coding tasks consumed roughly 1,000 times as many tokens as simpler code-reasoning and code-chat tasks. Runs on the same task varied by as much as 30 times in total token usage, and spending more tokens did not consistently produce higher accuracy. The models also tended to underestimate their own eventual token consumption. A separate systems study accepted for publication at HPCA 2026 found that additional agent compute could produce rapidly diminishing returns.
Those results come from controlled coding workloads; they should not be treated as universal multipliers for every agent. But they demonstrate why seat-based intuition breaks down. Agent cost is partly determined at runtime, and two attempts at the same task can follow very different economic paths.
The risk is not that every additional step is waste. Exploration, validation, and recovery can make an agent more reliable. The risk is that many organizations cannot distinguish necessary work from avoidable repetition.
The invoice arrives before the explanation
In June 2026, The Wall Street Journal reported results from a KPMG survey in which only 26% of companies said they had a comprehensive view of their AI costs. Half had some visibility, while 22% had no visibility or saw the cost only after billing. That is materially different from having a dashboard: a company may know its total token consumption without knowing which workflow, customer, agent, or business outcome created it.
FinOps practitioners are now being asked to close that gap. The FinOps Foundation’s 2026 State of FinOps report included 1,192 respondents representing more than $83 billion in annual cloud spend. It found that 98% of responding teams now manage AI spend, up from 31% two years earlier, and identified AI cost management as the most desired new FinOps skillset. FinOps for AI was also the community’s top forward-looking priority.
Yet the same report shows that the necessary tooling has not caught up. Granular monitoring of tokens, LLM requests, and GPU utilization was the most requested tooling capability. One practitioner put the maturity gap bluntly: “Dashboards are table stakes of yesterday—reactive.”
The FinOps Foundation’s AI framework goes further. It notes that there is not yet a generally accepted framework for allocating costs across multi-agent workloads. It also says AI reporting requires additional data structures that connect costs to business outputs, not merely provider invoices or token totals.
The problem, in other words, is not an absence of numbers. It is an absence of causality.
Waste has recognizable shapes, but the name is not the verdict
Once a team examines an agent’s execution trace rather than only its invoice, potentially avoidable spend becomes easier to see. But an honest audit must distinguish what the evidence proves from what it merely suggests.
Consider retries. A retry is not automatically waste. Retrying after a transient rate limit or network interruption may be exactly the right behavior. But if an agent encounters a deterministic permission error, changes nothing, and repeats the same request with the same inputs and credentials, the resulting spend is more defensibly classified as avoidable.
The same distinction applies to loops. An agent that revisits a step after learning something new may be progressing. An agent that repeats the same plan, invokes the same tools, receives substantially the same results, and eventually times out without producing an outcome is showing stronger evidence of nonproductive spend.
Other patterns are better treated as optimization opportunities rather than confirmed losses.
A context window may grow because every turn carries forward an expanding history. Input tokens were the dominant cost driver in the coding-agent study, but that does not prove that any particular piece of context is unnecessary. The only defensible way to call it waste is to shorten or summarize the context and show that the workflow still meets its quality requirements.
A frontier model may be handling a step that a smaller model could complete more cheaply. That is a candidate downgrade, not proven waste. The lower-cost model still has to pass the required thresholds for quality, latency, safety, and reliability.
Repeated stable prompt prefixes may be candidates for caching. Tool calls that repeatedly return unchanged information may be candidates for consolidation. Both can produce savings, but only where the architecture and provider support them and only after the effect on outcomes has been tested.
This distinction matters. Repeated deterministic failures and non-converging loops can leave strong evidence in the trace. Context trimming, caching, and model routing are hypotheses. Calling every expensive behavior “waste” is marketing. Measurement requires a confidence level and a validation method.
A bill can show usage. It cannot show whether the usage was worthwhile.
Provider billing data can usually tell a team which model was used, how many tokens were processed, and what it was charged. It usually cannot explain why the call happened, what changed because of it, whether the workflow succeeded, or whether the same outcome could have been reached more efficiently.
That information lives across several layers: the execution trace, tool results, application state, pricing data, and the definition of a successful business outcome.
The FinOps Foundation explicitly recognizes this requirement. Its AI framework says usage data increasingly needs to include tokens used, calls made, and outcomes achieved, with reconciliation mechanisms that connect them. It expects this data to be more granular and higher-volume than conventional cloud billing data. It also defines inference efficiency not only as cost per prompt, but as the cost of reaching an anticipated outcome.
That changes the useful unit of measurement.
For a support agent, the important number may be cost per correctly resolved case—not tokens per conversation.
For a coding agent, it may be cost per accepted change, with tests passing and no regression—not cost per model call.
For a research agent, it may be cost per report that meets an evidence threshold—not cost per page generated.
For an operations agent, it may be cost per successfully completed workflow, adjusted for human intervention, latency, and error rate.
Tokens remain important. They explain part of the bill. But tokens are an input, not an outcome.
Measurement should come before blunt control
The FinOps Foundation’s definition is useful here: “FinOps is about getting the most value out of technology to drive efficient growth.” The discipline is not simply about minimizing cost. A workflow that costs more but produces proportionally more value may deserve additional investment.
That suggests a practical order of operations:
Define the outcome. Establish what success means for the workflow, including quality, latency, safety, and human-review requirements.
Capture the complete execution. Record model calls, token usage, tool invocations, retries, context growth, errors, and changes in state.
Attach cost to the execution path. Apply the appropriate pricing and allocate shared costs to the relevant agent, workflow, customer, or business process.
Separate evidence from hypotheses. Classify clearly demonstrable failures separately from potential savings that require testing.
Change one variable and compare. Adjust the retry policy, context strategy, model route, loop guard, or cache behavior, then measure both cost and outcome quality again.
Budget caps, approval gates, and model restrictions still have a role. But a broad limit applied before measurement is blunt: it can constrain the workflows that justify their cost along with those that do not.
The objective is not simply to make every agent cheaper. It is to make agent economics explainable.
Where Xerg fits
That execution-to-economics gap is the problem Xerg is designed to address.
Xerg ingests agent execution logs and converts them into dollar-denominated measures such as cost per outcome, outcome yield, and waste rate. It separates trace-confirmable patterns, including repeated retries and non-converging loops, from testable opportunities such as context reduction or model downgrades. It then supports before-and-after comparison so teams can determine whether a change actually improved the economics rather than merely reducing token usage.
That makes Xerg complementary to billing systems, observability platforms, and broader FinOps practices. Billing establishes what was charged. Observability reconstructs what the system did. FinOps creates organizational accountability for technology value. Xerg focuses on the missing join between an agent’s behavior, its cost, and its outcome.
It does not require the claim that agent spending is universally excessive. Some agents will produce far more value than they cost. Others will quietly repeat failed actions, carry unnecessary context, or use expensive resources without improving the result.
The point is to measure the difference.
The next great agent-cost problem is not simply that agents will spend money. Using models and tools to perform work is what they are built to do. The problem is that one line of human intent can expand into an opaque chain of spending without leaving an equally detailed economic record.
Once that record exists, teams can invest more confidently in agents that work, and stop subsidizing the loops that do not.