How to set a spend limit on an AI agent

A spend limit is a hard stop on what an agent may consume or commit before it has to hold and ask a person. Set it in money, at three levels: per run, per day and per decision type. Enforce it inside the system, where a run cannot get past it.

Most teams meter tokens, because that is the unit the vendor bills in. It is the wrong unit. Tokens measure what the model consumed. A limit has to measure what the business is exposed to. That includes everything the agent approved, refunded, ordered or paid.

Two limits, one for each exposure

Compute spend is what the agent costs to think. Commitment spend is what the agent costs you by deciding. They fail at different speeds, and a single limit cannot cover both. A runaway retry loop burns compute in minutes. A badly set approval rule commits money for two weeks before anyone looks.

The second column hurts most. It does not appear on the model provider's invoice, so cost tools often miss it.

GatehouseIn RUN-7F2K4, the simulated run on Gatehouse, Surehand's control plane, the manifest sets an autopay limit of 250.00. Rule bank-detail-change holds INV-40218 for 2,400.00 for the AP lead by name. Read the run on Gatehouse ↗

How to set the number

Do not guess a budget. Work it out from the process the agent replaces, whose cost and error rate you already know.

1. /01

   Measure the current unit cost. What does one claim, invoice or ticket cost to handle today, including all staff time? Call this C.

2. /02

   Measure the current error cost. What does a wrong one cost, on average, including rework and goodwill? Call this E.

3. /03

   Set the per run compute limit at a small share of C. If thinking about the work costs a meaningful fraction of doing the work, the economics are already wrong.

4. /04

   Set the per decision commitment limit below E. An agent should never be able to commit more, unattended, than one mistake costs to clean up.

5. /05

   Set the daily limit a little above expected volume. That leaves room for a busy Monday, and a loop trips it quickly rather than overnight.

6. /06

   Review all three once the deployment has run on real inputs for a few weeks, when you have real numbers instead of estimates.

What happens at the limit

At the limit the run should hold. A failure throws the work away and reports an error where nobody looks. The item goes back to a person who never knew it was tried. A hold keeps the run and records why it stopped. It goes to a named approver with the evidence gathered.

That is also what makes the limit safe to set tight. When hitting the limit is cheap and recoverable, you can afford to start conservative and relax it with evidence. When hitting the limit means lost work and an angry customer, everyone sets it high, which is the same as not having one.

Four limits cover one process, and two of them are on money the agent moves.

A limit has to stop the run

A dashboard reports what already happened. A limit prevents it. If only a person watching a chart stands between a retry loop and your card, the control is their attention. Nobody is watching at 2am on a Sunday. The check has to run before each call.

Ask whether the system can exceed the number at all. If the honest answer is that it would be noticed quickly, that is monitoring. A limit means the run stops.

What a limit does not protect you from

A limit does not stop an agent from being wrong at low cost. An agent that sorts a thousand claims wrongly under budget has cost you nothing in spend and a great deal in trust. Limits bound financial exposure. They say nothing about accuracy. A team that watches only spend will miss a quality drift that stays inside every limit. Confidence thresholds and sealed records cover that, which is why the three are set together.