Search for how to give an AI agent a budget and you get two completely different answers, both called the same thing. One is about tokens. The other is about your bank balance. Conflating them is how teams end up protected against the cheap failure and exposed to the expensive one.
Two questions wearing the same words
Ask the internet how to stop an AI agent burning through your budget and you get a confident answer. Read a few of them and you notice they are not answering the same question.
One set is about inference cost: token caps per run, model routing, an auto-pause when a task loops. The failure mode is a bill from your model provider.
The other is about payments: the agent has a wallet or a card and can move real value to a third party. The failure mode is money leaving your account and not coming back.
Both get called "agent budget" and "spend controls". They are not the same problem, they do not fail the same way, and the controls for one do almost nothing for the other.
Why the difference is not academic
Token overspend is bounded, observable and reversible in the ways that matter. The bill arrives at the end of the month, your provider shows you a dashboard, and the worst case is a number you did not plan for. Unpleasant, survivable.
Payment overspend is none of those things. It is unbounded until something stops it, it is often invisible until reconciliation, and once a stablecoin transfer settles there is no chargeback, no dispute window and no support line. The counterparty has the money.
So a team that reads the token-cost articles, sets a per-run cap, and concludes it has solved agent spending has protected itself against the recoverable failure while leaving the unrecoverable one wide open.
What a real payment limit has to survive
A token cap lives in your own orchestration code and that is fine, because the thing it is protecting against is your own code looping. A payment limit has a harder job: it has to hold against an agent that is actively trying to get past it.
That is not a hypothetical. A language model is a persuasion engine. Put the limit in the prompt and you have written a suggestion. Put it in a wrapper the agent calls and you have written a suggestion with an extra step, because the agent decides whether to call it.
The test for any payment control is simple: if the agent were adversarial, would this still hold? Most guardrails fail that question immediately.
The four ways a limit leaks
The first is the obvious one, an agent that simply asks for more than it should. Every control catches this and it is the least interesting case.
The second is the path nobody instrumented. A team blocks purchases and forgets recurring payments, or blocks transfers and forgets that cancelling a protective position is also a way to lose money. Guardrails that cover the main verb and miss the adjacent ones are the normal failure, not the exception.
The third is the retry. An agent told no does not always stop; it rephrases and tries again. If refusals are not counted, a limit that says no ninety times and yes once has said yes.
The fourth is the one that looks like success: the agent stays under every per-transaction cap and makes forty of them. Any control without a time window is not a budget, it is a transaction size limit.
Where the number should actually live
The useful mental model is to ask what has to be true for the limit to fail, and then make that thing harder.
A limit in a prompt fails if the agent is persuaded. A limit in your server fails if your server is wrong, compromised, or simply down at the moment it matters. A limit in a contract on-chain fails if the contract is wrong, which is a much smaller and much more auditable surface.
None of these is sufficient alone, which is why the answer is layers rather than a choice. The server pre-check is the fast path and handles the common case. The on-chain vault reverts an over-limit transfer regardless of what anything upstream believed. Wallet-layer screening at the custody provider catches what neither saw.
An agent can talk its way past one of those. Talking a contract into ignoring its own require statement is not a thing that happens.
The signal most systems throw away
Almost every guardrail design has two outcomes: allow and block. Real spending decisions have three.
The missing one is the case where the payment is permitted but large enough, or unusual enough, that a person should see it before it happens. Collapse that into allow and you have a system that silently approves the payments you most wanted to know about. Collapse it into block and people turn the whole thing off within a week because it keeps stopping legitimate work.
Naming it explicitly, as WARN, is what makes the difference. It escalates rather than deciding, and the human in the loop is asked a specific question at a specific moment instead of being handed a dashboard to monitor.
Set both, but know which is which
None of this argues against token budgets. Cap your per-run inference cost, route to cheaper models where you can, and pause a task that loops. That work is real and the articles about it are good.
Just do not file it under the same heading as payment authority, and do not let a green dashboard on one imply safety on the other. Ask which budget a given control protects, and be honest when the answer is "the cheap one".
The agent that runs up a large inference bill has cost you money. The agent that pays the wrong counterparty has given your money to someone else. Only one of those is a support ticket.