Key Insight: An organization planning for a ten, fifty, or hundredfold increase in AI-driven work cannot get there through a bottom-up budget request. Engineers will not submit that number, and nothing in their planning process is built to produce that number. At the same time, finance cannot set the envelope alone, because the gross spend it can see includes an unmeasured share of leakage and reveals nothing about which layers are recoverable. Both directions fail on their own. What the room converged on is not a better forecasting formula but a division of labor.
I brought several Advanced Practitioners together to compare AI estimation methods… They left with an accountability problem instead.
They met under the Chatham House Rule to work through one question: “What is the method to your madness when it comes to AI cost estimation?” The hour that followed produced no shortage of techniques. But the practitioners in the room were not stuck on how to calculate a number. They were stuck on who is entitled to set the budget.
That’s the premise we keep hearing, from practitioners and from our Technical Advisory Council: AI’s cost to serve is rarely blown by model pricing. It is driven by operational behavior, engineering decisions, and business events that multiply consumption, and those decisions rarely sit with a single owner.
The framing that anchored our discussion came early: Most AI projects are still experimental right now. Code-forward agents that could write production-quality code arrived only months ago. Agentic workflows accelerated, then seemed to partially reverse. Nothing in the stack has settled long enough to be treated as run rate. Yet.
That has practical consequences for planning. Several practitioners described a hard rule of one-year contracts only, on the reasoning that the market is moving too fast to trade agility for a discount, and providers aren’t willing to offer set capacity too far in the future. Tools bought last year are expiring and not being renewed, because something newer arrived with a different cost model. Subsidized pricing and free-tier incentives are distorting the baseline, and nobody in the room could say what the true cost looks like after the subsidies end.
The effect is a forecast horizon that has collapsed to roughly twelve months, maximum. As one practitioner put it, taking the 2026 usage curve and extrapolating 2027 from it is a problem for a future version of yourself.
Where AI touches engineering, value realization is tractable. Work is tracked. There are sprints, cycle times, delivery metrics, pull requests, and incident rates. Practitioners described building composite productivity scores rather than relying on any single measure, because a single measure gets gamed. Gaming metrics is, as one FinOps leader noted, more or less what engineers are paid to do.
The composites described in the room included lines of code added against lines removed, the severity and volume of incidents traced to AI-assisted pull requests, and normalization against cycle time and delivered points. The design goal is a metric where even a gamed result still represents real output.
Outside engineering, the picture inverts. A marketing team that stands up an AI workflow generates spend, plausibly generates value, and produces almost nothing measurable. There are no tracked hours, no acceptance criteria, and no tickets to close. The work may well meet capitalization rules, but there is no systematic record to capitalize against. Surveys and interviews can fill some of that gap, but they do not scale to thousands of non-technical staff.
So value coverage is uneven, and the uncovered portion is the part growing fastest.
The sharpest moment in the discussion came from a decomposition of a hypothetical hundred dollars of AI spend. The layers of loss were familiar to everyone on the call: model mismatch, where a task runs on a more capable and more expensive model than it needs; idle and dark usage, often unnoticed until later; prompt bloat, visible in the ratio of input tokens to output tokens (and in cases of poor cache hit rate); retry waste, the bane of my existence; verbosity; and unnecessary tool calls.
One practitioner offered a concrete example: A developer tooling option in “automatic mode” was quietly selecting a frontier model for trivial operations, including checking out a branch. Nobody noticed until a post-mortem.
That leads directly to the budgeting question the room could not resolve cleanly: If a meaningful share of the hundred dollars is leaking, what do you set the budget at? The gross invoice overstates the requirement, and the net figure is not knowable without instrumentation most teams haven’t yet built.
There was near-consensus on one point about remediation: This is not human work. The corrections are too granular, too numerous, and too unstable. Changing a model changes response quality, which changes downstream behavior, which means a hard-coded value from last year cannot simply be swapped. Practitioners described telling tool providers to design for agent-to-agent consumption, because no overworked engineer is going to sit down and act on a prompt bloat recommendation.
Several attribution patterns surfaced, and they point in a consistent direction.
One practitioner described partnering with HR to attach license and usage data reliably to a team or an individual, then deliberately separating software development AI usage from general enterprise AI usage so the development cycle could be measured on its own terms.
Another described routing simple tickets to a shared internal tool, so the tokens accrue to the tool rather than to a person. The reasoning was that a person should not have been doing that work in the first place, so charging it to them distorts the picture.
A third described tiering token allocations by demonstrated productivity rather than issuing a flat per-seat limit. A principal engineer producing large gains should not sit under the same cap as someone spending millions tokens configuring their environment on day one.
Others described publishing per-user spend openly in an internal developer portal, with nothing hidden, alongside weekly variance conversations with finance where every increase comes with some form of justification.
Underneath these is a four-category model used to decide who sets which budget: Seat-based software that has added AI, coding copilots, external customer-facing applications, and internal, non-coder agentic work. Whereas coding copilots can run inside the software development lifecycle, non-coder agentic work (e.g. marking, finance, HR, operations) feels invisible from a tracking standpoint. As such, that category is where the risk concentrates. It’s the newest, the least governed, and the most likely to churn.
This also connects to a pattern raised earlier in the year, where departments hold labor, software, and infrastructure budgets and are then asked to fund AI by trading against one of those buckets rather than growing the total.
An organization planning for a ten, fifty, or hundredfold increase in AI-driven work cannot get there through a bottom-up budget request. Engineers will not submit that number, and nothing in their planning process is built to produce that number. At the same time, finance cannot set the envelope alone, because the gross spend it can see includes an unmeasured share of leakage and reveals nothing about which layers are recoverable.
Both directions fail on their own. What the room converged on is not a better forecasting formula but a division of labor:
This is why optimization and guardrails are converging. A token quota is simultaneously a financial control and an engineering control, and it only works if both sides set it together.
Two constraints keep this honest. FP&A in most organizations is not operating at the speed of the technology, which means the planning cycle is slower than the thing it is planning for. And investors do not buy productivity. As one practitioner put it, you can spend heavily on tokens and become far more productive, and if it does not show up as revenue or profit, it does not count. A productivity story is not, by itself, a budget justification.
Tammy Burnitt (FinOps Foundation Director, Technical Community Architecture) models this shift from, “What does an LLM cost per token?” to “What is the total cost to serve AI in an enterprise?” That’s a much more useful budgeting perspective because it incorporates engineering, product management, cloud operations, FinOps, governance, customer growth, M&A, and modernization, all of which materially influence AI spend long after the initial proof of concept.
The State of FinOps 2026 data points in the same direction. Ninety-eight percent of respondents now manage AI spend, up from thirty-one percent two years ago, and practitioners with executive engagement report two to four times more influence. The 2026 FinOps Framework added Executive Strategy Alignment as a capability for a reason. Setting the AI envelope is the clearest current example of why it matters.
