Where an AI agent's bill gets decided

In an explainer published on 14 October 2026, McKinsey's Lari Hämäläinen, Wasim Lala and Kaavini Takkar describe a change most operators have already felt. In the first quarter of 2026 the large model providers moved from per-seat licences to consumption pricing, and the same usage could cost two to three times as much overnight. Moving a tool from pilot to production, they report, nearly quadruples its spend on average. One bank's projection went from about three million dollars a year to more than twenty-five million once everyone had every model with no guardrails, and its answer was to ask for one place where all of it could be seen and traced back to a person. Their conclusion is that AI cost can be managed and that control starts with visibility.

Visibility is the right first word, and it is not the last. A number you can read after the fact does not stop a loop that runs all night. This piece explains how AI Agent Builder controls cost in four places, each at a different distance from the money: the tenant that pays, the run that spends, the model each step uses, and the record every call leaves. Each stops something the others cannot, and the last section says what none of them stops.

The tenant holds the money

The unit that pays is the tenant: one client, one division, one subsidiary. Each tenant has its own account for spend, in one of three modes. A prepaid tenant is served until its balance reaches zero. A postpaid tenant is always served and billed for what it used. An unlimited tenant is not metered. Beside the account there is a monthly ceiling, on messages and on spend, that an operator sets per tenant; a ceiling set on a parent applies to the tenants beneath it until one of them sets its own.

Both are read before any step of a turn runs. When a prepaid balance is exhausted, or a ceiling is reached, the customer reads a neutral line saying the assistant is unavailable, nothing about billing, and no model is called. A denial is never remembered: the moment the balance is topped up, the next turn is served. A tenant that brings its own provider connection is outside the account, because the platform bills nothing for inference the provider invoices directly; the ceiling still applies.

The amount is the provider's cost for the call, passed through either a multiplier or a price per model that the operator sets. That is what lets an agency resell inference with its own margin. The balance is debited once per run, and the amount debited is the sum of the amounts recorded on that run's rows, so the two reconcile.

This is the answer to "which client is spending this", and it is deliberately coarse. It decides whether a turn starts. It cannot know what a turn will cost, so it needs something inside the turn.

The run has an allowance

A single turn of an agent that uses tools is many model calls: one to decide, one per tool result, one to answer, more if it retries. The McKinsey authors put the spread between a well-designed agent and a poorly designed one at up to thirty times the tokens for the same task. The multiplier that matters is therefore not the price of a token but how many calls a run is allowed to make, which is why the arithmetic of one turn counts calls rather than messages.

An agent can carry three caps for one run: a number of model calls, a number of tool calls, and an amount of money spent on inference. They count across every step of the run, not per node, and the two that bound model calls also count the calls made by agents it delegates to, so a sub-agent cannot spend what its parent was refused.

The money cap is the interesting one, because a call's cost is only known after it returns. The platform does not wait to find out:

1. Before the call, it reserves the worst case. The worst case for one call is the model's whole context window used for input and again for output, at that model's price. If the sum of what is already spent and that reservation exceeds the cap, the call is refused and never reaches the provider.
2. The reservation is written down first. It is stored durably before the request is sent. If it cannot be stored, the call is not made.
3. When the answer arrives, the reservation is replaced by the real cost, computed from the tokens the provider reports.
4. A call that fails keeps its reservation. If the provider drops the connection, nobody knows what was consumed, so the run is held to the worst case. A retry loop cannot spend its way past the cap by failing.

A run capped at ten cents, on a model whose worst case for one call is four cents, behaves like this:

The refusal is a typed error that is not retried, and it names what was already completed so that finished tool calls are not repeated.

Two more properties follow from keeping the allowance as a record rather than a counter in memory. It survives a pause: a run that waits for a person to approve a step comes back with its spend intact, not reset. And it refuses what it cannot measure: under a money cap, a model whose price the platform does not know is refused before any request is sent, because a cap on a cost you cannot compute is a cap in name only.

Every call leaves a record

Each model call is stored as a row of its own: the tenant, the agent, the session, the connection it went through, the provider and model, tokens in and out, how many of them were cached, the estimated cost, what was billed and under which pricing. The record is written whether or not the run is billed, so a call is visible even when nobody is charged for it.

The report over these rows groups by tenant, agent, model, connection, day or category, filters by any of them, is scoped to what the person asking is allowed to see, and exports to a spreadsheet. The question the bank in the McKinsey example wanted to put to every request, why it was not routed to a cheaper model, is a grouping by model and connection. "Which agent spent it" and "which client" are one click each. Because the session is on every row, the cost of a whole conversation is the sum of its rows.

Nothing in this changes what an agent does. It makes the other three places tunable, which is what visibility is for.

The model is part of the definition

The cheapest token is the one a deterministic step never spends. A workflow that already knows its next move does not need a model to say it: conditions, code and direct tool calls run as ordinary steps, and a model is spent only where a decision or a sentence is genuinely open.

Where a model is needed, which one is a property of the agent and its tenant, not of whoever happens to be using it. The tenant maps each of a few reasoning levels, from low to high, to a connection and a model. An agent asks for a level, so an operator who finds that the highest level is overused changes what it means once, for every agent, instead of editing them one by one. A step that needs a particular model can name a connection and a model explicitly, and that choice is visible in the definition rather than inside a prompt. The McKinsey authors describe the opposite pattern: usage at one client that moved from a mid-tier model to the top-tier one within a few months, because the better model was available and people reached for it. A model written into the definition and visible in the report does not drift that way unnoticed.

Decisions are the case where the saving is largest. Classifying a message, checking scope and picking a tool are answered by a decision model with a value and a confidence instead of a generated paragraph, so the steps that run on every turn stop paying for generation they never needed.

Where it stops

• The caps are opt-in. An agent without limits has none. The platform provides the brake; whoever builds the agent decides to attach it.
• The tenant gates are read before a turn and charged after it. A balance or a ceiling is checked at the start and debited once at the end, so a turn in flight can take a balance below zero, and several turns that start together all read the same figure and all proceed. The run allowance bounds each of them, if set. Nothing bounds the number of them.
• The tenant gates fail open. If the lookup itself fails, the turn is served and the failure is logged. That is deliberate, since an outage in metering should not take agents offline, and it makes these limits a cost control rather than a security boundary.
• A failed run is recorded and not billed. The calls are in the report, but the tenant is not charged for a run that errored, so that provider cost falls on whoever operates the platform.
• The reservation is conservative. A cap lower than one worst-case call refuses the first call even when it would have cost a fraction of that. Caps work best a few multiples above a typical run.
• The estimate does not discount caching. The count of cached tokens is recorded, but the estimated cost is priced from input and output tokens alone, so where a provider discounts cached input the estimate is an upper bound.
• It measures model cost, not the rest of the cost. In a separate analysis of agent economics published on 24 August 2026, McKinsey finds that for a bank's customer-service agent tokens are 20 to 25 percent of the variable cost of a run and human oversight is 70 to 75 percent. The platform sees the tokens. The time a person spends reviewing an answer is outside it, and so is the cost of one resolved case.

Invariants worth testing on any system

Whatever you run your agents on, six checks tell you whether its cost controls are controls or reports.

A system that fails the first or the second has a dashboard. One that fails the last has a number it cannot explain.