Cap the spend before it runs away
An agent in a loop is a powerful thing and a dangerous one. Give it a tool and a goal and it will keep calling — search, fetch, summarize, retry, call again — until the goal is met or something stops it. If nothing stops it, "something" is your bill. A planning loop that mis-reads its own progress can fire the same paid tool a thousand times in a minute; an agent left running overnight can burn a month's budget before anyone wakes up. "It'll probably stop on its own" is not a spending limit.
The fix is a budget guardrail: a running total of spend and a fixed cap,
checked before every call. The rule is one line of arithmetic — allow a call only
if spent + cost <= cap; otherwise refuse it and leave the budget untouched. The
key move is what happens after a refusal: you don't stop the whole agent, and you
don't quietly let the next call through either. You keep walking the queue, and
every call that would still breach the cap keeps getting refused. The guardrail
isn't a circuit breaker that trips once — it's a gate that every call must pass.
Walk a concrete budget of 100. search costs 30 → spend is 30, allow. fetch
costs 25 → 55, allow. summarize costs 40 → 95, allow. Now translate costs 20:
95 + 20 = 115, over the cap, so refuse — and spend stays at 95, untouched.
Here's the subtle part: ping costs only 5, and 95 + 5 = 100 still fits, so it's
allowed even though a call just got refused. Then log costs 1: 100 + 1 = 101, over — refused. Final spend lands exactly on 100, never a cent above. A
refusal isn't the end of the run; it's just this call not fitting the budget.
Below, the call queue and the print lines are wired, but the guardrail is missing —
the loop charges every call and prints ALLOW no matter what, so it sails past the
cap to a final spend of 121. Add the check: allow a call only when
spent + call.cost <= cap (charge it and print ALLOW <name> (spent X/100)),
otherwise print REFUSE <name> (would exceed 100) and don't add its cost. Get it
right and the run ends with final spend: 100.
A budget guardrail is the difference between an agent that stops and an agent that stops you — checked before every call, it caps the spend no matter how long the loop runs.