Budget-gating an autonomous agent
Almost everything written about AI agents is about capability. Very little is about cost, which is strange, because cost is the constraint that actually stops people deploying them.
An agent that can call a model in a loop can spend money in a loop. That is not an edge case; it is the default behaviour of a retry.
Dashboards are not controls
The common approach is a spend dashboard and an alert threshold. This feels like cost control and is not, for one reason: it reports on money already spent.
A human watching a graph is a control with a response time measured in hours. An agent's response time is measured in seconds. The mismatch is the entire problem — by the time the alert is useful, the spend has happened.
A control has to be able to say no before the work, not describe what happened after it.
Four properties a real budget gate needs
It gates before the work
The cost of an action is estimated and approved before the action runs. If the estimate does not fit the remaining budget, the work does not start. This is the difference between a budget and a receipt.
It paces over time
A monthly budget with no daily bound is a monthly budget you can exhaust on the first afternoon. Pacing spreads the ceiling so one runaway day cannot consume the period — and a runaway day is the failure you are actually defending against.
The approver is not the spender
If the same component decides to act and decides whether it can afford to, there is no gate, only a formality. Separating them is what makes the check able to fail.
Deleting work does not refund it
Any system where you can remove a unit of work and reclaim its consumed budget can be looped: create, spend, delete, repeat. Spend already consumed must stay consumed for the period, or the ceiling is decorative.
The estimate problem
Gating before the work requires knowing what the work costs, and you do not — token counts are not known until the call returns.
The workable answer is to estimate deliberately high and reconcile afterwards. Over-reserving means you occasionally refuse work that would have fit, which is a mild and visible failure. Under-reserving means you occasionally allow work that does not fit, which is an invisible failure that compounds.
When one direction fails loudly and the other fails silently, pick the loud one.
Booking cost you are not certain about
A related trap: if you price model usage in your own books and a model is missing from your price table, the natural fallback is your default rate. If your default happens to be a cheaper model, you have just built a system that silently understates its own largest variable cost — and understates it most for whichever model you most recently added.
Price every model explicitly, and when you must guess, guess expensive. Books that flatter you are worse than no books.
How this is built in Empyre
Empyre gates AI spend before work runs: a dedicated CFO agent approves cost upfront, spend is paced daily so one day cannot consume the cycle, and deleting a company carries its consumed spend forward rather than releasing it, so create-and-delete loops cannot mint fresh capacity.
The mechanics are documented in the Empyre docs.
Frequently asked questions
How do I stop an AI agent spending too much?
Gate before the work rather than alerting after it, pace the budget over time so one day cannot exhaust the period, and make sure the component that approves spend is not the one that wants to spend.
Is a hard spend cap not too blunt?
It is blunt, and that is the point. A cap that can be argued with is not a cap. The place for nuance is the size of the budget, not whether it is enforced.
What about retries?
Retries are where loops get expensive, because a failure that triggers a retry often triggers it repeatedly. Retries must draw from the same budget as the original attempt — a retry path with its own allowance is an unbounded one.
Try Empyre free
Describe a business in plain words and watch eight AI agents build and deploy it. The first build is free — no card required.