Key facts.
- GAIA shows realistic assistant tasks remain hard for frontier models, with GPT-4 plus plugins around 15% versus roughly 92% for humans, so an agent will encounter tasks it cannot complete and, uncapped, will spend on them indefinitely. source
- tau2-bench scores only fully correct task completions in its dual-control customer-service domains, a reminder that partial progress still counts as a failed, paid-for run that a cap should bound. source
- The IMF's 2026 note on agentic payments stresses that autonomous agents acting with spending authority need explicit limits and oversight, framing budget control as a governance requirement, not an optimization. source
Why is a cap a governance control rather than an efficiency tweak?
Without a ceiling one bad run loops to a bill nobody approved, since a stronger model won't remove the failures: on GAIA a plugin GPT-4 scored ~15% to ~92%. (arXiv:2311.12983)
Because it bounds a worst case, and bounding worst cases is what governance does. An efficiency tweak lowers the average bill. A cap limits the maximum a single task can cost no matter how badly it goes, which is the property a risk function actually needs. The distinction matters because the expensive runs are not the average runs. They are the ones that loop, retry, and re-read a growing context, and those are rare per task but unbounded in cost without a ceiling. A cost-per-task target tells the agent what good looks like. A hard cap guarantees that even a pathological run stops before it becomes a budget incident.
This is the same logic that makes a credit limit a control rather than a suggestion. You do not set a card limit because you expect to hit it. You set it so that if something goes wrong, the loss is bounded. An agent with spending authority and no cap is a card with no limit, and the IMF note is explicit that autonomous agents transacting on your behalf need exactly that kind of bound.
What does a usable cap actually look like?
Two numbers and a behavior. A target cost per task, derived from the value of a successful outcome, so the economics stay positive. A hard cap, set above the target with headroom for legitimate retries, that stops the run and escalates when crossed. And a defined behavior on cap: not a silent failure, but a clean halt that hands the task to a human or a fallback, with the partial work preserved. The cap is not there to make the agent cheaper on a good day. It is there so a bad day has a known maximum cost and a defined exit, which is what lets governance approve the agent for production at all.
| Control | What it bounds | Who needs it |
|---|---|---|
| Cost-per-task target | The average, the economics | Product and finance |
| Hard per-task cap | The worst case | Risk and governance |
| Cap behavior (halt + escalate) | The failure exit | Operations |
The Pattern Intelligence Layer is where the cap becomes a property of every run rather than a setting someone hopes was applied. The target, the ceiling, and the halt-and-escalate behavior are enforced at the pattern level, so cost stays bounded across every task, every model, and every retry. Reliability at the pattern level includes the reliability of a spend ceiling that does not depend on the agent choosing to stop.
Frequently asked questions
Will a cap cut off legitimate long tasks?
Only if set too low. Put the cap above the target with headroom for normal retries, and it bounds pathological runs while leaving honest ones alone.
Is a cost target not enough on its own?
No. A target shapes the average; it does not stop a looping run. The hard cap is what bounds the worst case, which is the governance need.
What should happen when the cap is hit?
A clean halt with escalation to a human or fallback, preserving partial work, not a silent failure that hides the cost event.