Your AI agent has a goal, not a budget
Someone asked the question that’s going to define the next two years of cloud bills: what happens to cost control once agents, not people, are the ones doing the spending? The replies split into the usual camps — token budgets, cheaper models, per-seat limits. Every one of them is answering a smaller question than the one being asked.
Here’s the thing about an agent: it doesn’t have a budget. It has a goal.
Cost isn’t in the objective function
An agent is optimizing for exactly one thing — did I produce the answer — and nothing in its loop measures what the answer cost. So every decision it makes is rational from where it stands. Re-read the file. Re-run the query with a wider date range. Try the other API, just to be sure. It’s buying a better chance at the goal with a resource it cannot see.
A person doing that same job flinches before running SELECT * against three years of data. Some part of
them knows that query has a price. The agent doesn’t flinch. It has never seen an invoice.
This isn’t a bug you can prompt away. You can put “be frugal, avoid expensive operations” at the top of the system prompt and the model will genuinely try. But a prompt is a preference, not a limit. The moment being frugal and reaching the goal disagree, the goal wins — because the goal is what it’s scored on, and frugality is a suggestion handed to it by a stranger. And it has no idea what’s expensive in your account anyway. It doesn’t know your egress rate, your per-terabyte scan price, or that the “quick check” API you gave it bills forty cents a call. It’s guessing.
Your token cap guards one meter. The agent touches ten.
This is the part I think most people are going to get wrong, and it’s why “set a token budget” isn’t the answer even though it sounds like one.
When the whole conversation was LLM API cost, there was exactly one meter and it sat in one place: the model API. Cap the tokens, cap the bill. That worked.
Agents broke it, because an agent’s entire value is that it does things — and doing things means credentials. The moment it has credentials, the model call is the cheapest line item it can touch:
- It queries the warehouse, and that’s billed per terabyte scanned. The query was written by something with no sense of what a scan costs.
- It reads the bucket twice, because it wasn’t confident the first read was current. That’s egress — the line you can’t see.
- It starts a container to test its own work, and nothing tears that container down when the run dies.
- It calls the paid third-party API — search, enrichment, geocoding — per call, all afternoon.
Every one of those is a real meter with a real rate, and your gateway can’t see a single one of them. It sees the model call that decided to do them. The reasoning is metered in tokens; the consequences are metered in AWS. You capped the cheap half.
The reasoning is metered in tokens. The consequences are metered in AWS. Most people cap the cheap half.
The multiplier nobody prices in
Then there’s what happens when the agent is wrong, which it will be. A stuck agent doesn’t fail — it retries. That’s already an expensive habit when the thing being retried is a completion. When it’s a full-table scan, or a container start, or a metered API call, the same loop costs you twenty or fifty times more per lap.
So the honest shape of the risk isn’t “agents add a new line to your bill.” It’s that agents put a multiplier on the lines you already have. What arrives is your existing cloud bill, run by something that never sleeps, never gets bored, and never once wonders whether this is worth it. The unlimited-liability default you’ve been living with quietly becomes a much faster problem.
The budget has to live in the credential
So where does the brake actually go? Not in the prompt — that’s advice. Not only in the token budget — that’s one meter of ten. It goes where the agent’s ability to spend comes from in the first place: its permissions.
An agent’s blast radius is exactly the set of things its credentials let it touch. That’s a number you control, and it’s the one thing it cannot reason its way around:
- Give it its own identity, never a shared or human key. If you can’t say what the agent spent on its own, you can’t cap it. That’s the key-scoping argument, one step further out.
- Scope the role to the task, not the team. Read the one dataset, not the warehouse. Write the one prefix, not the bucket.
- Put quotas on the expensive verbs, not just the tokens — a scan ceiling on queries, a request cap per third-party API, a hard limit on how many jobs one run can start. Put the limit where the meter is.
- Expire everything with the run. Credentials that die when the task ends turn a weekend loop into a bounded event instead of an open tab.
- Route the actions through one door so the gateway and the kill switch sit on what the agent does, not only on what it says. A breaker that only knows about tokens is watching the wrong wire.
You're not teaching it to budget. You're making the expensive things unreachable.
None of that asks the agent to understand money, and that’s the whole point. A flat spend cap is still worth having as a floor — but it’s the smoke alarm, not the sprinkler. The permission is the sprinkler.
This is the trade, and it’s worth making
I’m not arguing against agents. The reason to hand one credentials is that it can finish the job, and that is genuinely valuable. But we’re about to give autonomous software the keys to metered infrastructure while the entire cost conversation is still about tokens — and the gap between those two facts is where the surprise bills of 2026 are going to come from.
The teams that get this right won’t be the ones with the strictest prompts. They’ll be the ones who decided, before the agent ran, exactly which meters it was allowed to reach.
If you’re putting an agent anywhere near your infrastructure, the question isn’t whether it will do something expensive — it’s whether it can. Send me your agent setup and its permissions and I’ll show you which meters it can still reach unbounded. Every message comes straight to me — I read and reply to each one myself, usually within a business day, and what readers send shapes what I build next. Send it over — free, within a day.