Agent spend needs an owner before it needs a cap

2026-10-20


Agent spend needs an owner before it needs a cap

October 20, 2026

Token budgets are blowing up for the same reason cloud bills did in 2012: nobody owns the number. Name the owner, tag the runs, show the cost back for a month, and only then talk about limits.

The most expensive sentence in engineering right now is "the team is just experimenting." It was true in January, when a few engineers were trying agents on side projects. It is a budgeting fiction by the time a quarter's worth of agentic coding runs in the background of every repo, because background agents consume capacity with no human watching, and the invoice is often the first signal anyone gets.

The cautionary tale making the rounds is Uber. As reported secondhand (the CTO's disclosure surfaced via The Information, and Business Insider reported the COO's follow-up), Uber used up its 2026 allotment for Claude Code and Cursor in roughly four months, and its COO said it was hard to connect the token spend to measurable product gains. I'd treat the specific figures floating around as unverified, because most of the write-ups cite each other. The pattern, though, is not exotic. A tool gets adopted faster than the plan assumed, the budget was sized for the adoption curve nobody expected, and the question "what did we get for this?" arrives before anyone has instrumented the answer.

The lesson for a TPM or a tech leader is not "cap the spend." A cap is what you reach for when you have no information. It cuts the cheap, valuable usage along with the wasteful loops, it teaches engineers to hide usage, and it moves the argument from "is this worth it" to "who gets to exceed the limit." The lesson is that agent spend is a program with an owner, a unit of measure, and a feedback loop, and most orgs have none of the three. Today's Deep Dive is how to build them before the invoice does it for you.


Deep Dive — AI as Leverage: Governing Agent Spend Like a Program, Not a Subscription

The category error. Seat licenses trained us to think of AI tooling as a fixed cost per head. Agentic tooling is not that. When usage-based billing arrived (the Unblocked write-up reports GitHub Copilot moving to token-based billing on June 1, 2026, with heavy agentic users reporting bills many times higher), a flat line item became a variable one that scales with how much work you delegate to machines. Tian Pan, writing about governance once monthly token spend reaches seven figures, adds the structural reasons: agentic loops fan out into many model calls, production cost can run far above development estimates, and requests of the same shape can vary wildly in cost depending on the context they pull in. A line item with that variance needs an owner the way a cloud account does.

Step one: one owner, answerable to two bosses. Dennis Pilarinos's FinOps-for-AI-coding piece makes the point that the real failure is rarely reckless engineers; it is agent spend that nobody is accountable for. Name a single budget owner who answers to both engineering and finance. In a large org this is often a TPM-shaped role, because the job is cross-functional by construction: it sits between the platform team running the gateway, the finance partner, and the teams consuming tokens. If you are a TPM and this job does not exist yet, it is the highest-leverage unowned problem on your floor.

Step two: tag everything. You cannot allocate what you cannot attribute. Pan's recommendation is an internal gateway in front of model providers that stamps every request with a team identifier and enforces rate limits, so chargeback comes from data and not from self-reporting. If a gateway is a quarter away, start smaller: require that every agent run, scheduled job or CI integration carries a team, repo or workflow tag. Untagged spend is the number you chase for the rest of the year.

Step three: choose a unit that points at outcomes. Raw tokens are the wrong denominator. Both Pan and Pilarinos argue against raw-token chargeback: it rewards terse prompts and cheaper models that quietly degrade quality, and it says nothing about whether the work shipped. Pilarinos suggests cost per merged pull request for coding agents; Pan's examples are cost per resolved ticket or per qualified lead for operational agents. Neither unit is perfect (merged PRs can be gamed, and I would not use cost per PR as a performance metric for any individual), but both turn the conversation from "how many tokens" to "what did a unit of finished work cost, and is that trending down." Pilarinos also cites the FinOps Foundation's notion of token yield rate, the share of tokens that lead to a downstream business outcome. Whatever you choose, pair it with a quality indicator so the cost number cannot be improved by shipping worse work. That is Grove's paired-indicator logic applied to a new input.

Step four: show back before you charge back. This is the sequencing most orgs get wrong. Charging teams for a number they have never seen and cannot yet explain produces defensiveness and shadow tooling. Give every team a monthly view of its own spend, tagged and attributed, with no consequences attached. Two things happen. Engineers find the embarrassing loops themselves, such as an agent re-reading the same files or a retry storm, and the finance partner learns which spikes are launches and which are leaks. Only after a month or two of that do you attach budgets.

Step five: governance that survives a bad quarter. Pan's proposal for orgs at serious scale is a standing inference budget committee of five to seven people: an engineering lead from each major consuming team, the platform lead, a finance partner, and a chair with authority to break ties. It maintains four artifacts: a capacity pool, a published allocation table with burst allowances for launches, a monthly chargeback report, and an exception log with named approvers and conditions. The detail I would steal even at small scale is the exception log. Approvals that happen in a DM are how an allocation table becomes fiction. Pan also argues for building this around half a million dollars a month of spend rather than improvising at ten times that, which matches the older cloud lesson that governance is cheapest when it feels slightly premature.

What to watch for. Vendor-authored guidance (Unblocked sells context tooling, and says so in its pitch) tends to define the problem in ways its product solves, so take the framework and leave the funnel. Standards are also still forming: the Linux Foundation announced its intent to launch a Tokenomics Foundation in June 2026 to work with the FinOps Foundation on token-cost standards, with a long list of initial supporters. Do not wait for it. Your tags and units will map to a standard later far more easily than the absence of them will.

The leadership move underneath. Notice that none of this is about saying no. It is about making the spend legible so that leaders can say yes with confidence. The org that can show cost per shipped outcome trending down gets to spend more on agents, because it can defend the number. The org that cannot gets a cap, and caps are decided by whoever is angriest in the budget review.

Try this week. Pull last month's invoice or usage export for any agentic tool your org pays for and ask one question: what percentage of the spend can I attribute to a named team or workflow? Write that percentage down, name the person who will own it, and put "get untagged spend under 10%" on the next program review agenda.


Method — The FinOps Lifecycle: Inform, Optimize, Operate (FinOps Foundation)

What it is. The FinOps Foundation's framework for managing variable cloud spend, built around three iterative phases: Inform (visibility and allocation), Optimize (reduce waste, improve rates), and Operate (continuously govern against targets). It is now being stretched to cover AI and token spend.

When to use it. When a cost that used to be fixed becomes usage-based and no one is accountable for it: agent tooling, model APIs, anything billed per token or per run.

How to run it:

  1. Inform. Tag every run to a team or workflow, build the per-team view, and publish it. Resist setting targets yet.
  2. Pick the unit. Choose one outcome-based unit (cost per merged PR, per resolved ticket) and one paired quality indicator.
  3. Show back for a full cycle. Let teams see their own numbers for four to six weeks and fix the obvious waste themselves.
  4. Optimize. Attack the biggest leaks first: retry loops, redundant context, models over-specified for the task, and caching where the vendor supports it.
  5. Operate. Set allocations and burn-rate alerts, record exceptions with an approver, and review monthly. Repeat the loop, because usage shifts every time a new capability ships.

When NOT to use it. When spend is genuinely small and flat; a three-person pilot does not need an allocation table, just a name next to the invoice.

Example: "Which of our top three agent workflows costs the most per merged change, and who owns that number?" If nobody can answer in a week, you are still in Inform.


Field Notes

Uber COO Struggles to Justify AI Token Costs — A secondhand summary of reporting that Uber's COO could not tie rising token spend to measurable product gains. Read it as a pattern, not gospel: the numbers are unverified and the wording is paraphrased, but the question it poses is the one your CFO will ask.

Linux Foundation announces intent to launch the Tokenomics Foundation — A June 2026 effort, working with the FinOps Foundation, to standardize how token costs are measured and compared. Useful as a signal that tagging and unit-cost discipline will become table stakes.

FinOps for AI Coding (Unblocked) — A vendor post, but a practical checklist: single owner, tagged runs, show-back first, and cost per merged PR. Discount the pitch, keep the sequence.


Events


Reading


"When a measure becomes a target, it ceases to be a good measure."

— Marilyn Strathern (1997), summarizing Goodhart's law


Don't miss what's next. Subscribe to Critical Path: