You gave your AI agent access, but did anyone give it a budget? I was chatting with a dev leader at a Fortune 500 company who ran a deterministic script that called external paid services on a simple if/then basis. It was predictable and easily auditable. They knew what each report cost because the logic triggering the call was the same logic that constrained it.
But then they switched to an AI agent. The agent was instantly smarter and better at handling edge cases. It was also free to call that same external service whenever it decided the situation warranted it, and it decided that a heck of a lot more than the old script did. The service was the same, as was the price-per-call; the agent just removed the deterministic boundary and replaced it with judgment. Then the invoice comes in, and tens of thousands of dollars had left the account without engineering knowing.
The agent was doing exactly what agents are designed to do, by reasoning through ambiguity and taking actions it was permitted to take. The problem was that in the haste to get the agent up and running nobody had defined what ‘too much action’ looked like in dollar terms before the go-live.
Healthy metrics, followed by an unhealthy bill
These costs are sneaky. A system can appear perfectly healthy by every technical measure while quietly running up a tab. Latency seems great, and every call is authenticated and authorized. From where engineering sits, everything looks fine.
Traditional monitoring was built on the core assumption that humans control the system. Someone deploys, and someone else watches and responds. That loop worked when software waited for instructions, but one of the benefits of agents is they don’t need to wait. That also means, though, between the moment something goes sideways and the moment a human responds to an alert, that an agent can retry thousands of times and use multiple tools. Real costs are generated at every step and, by that point, detection has come far too late.
Visibility gaps make the problem worse. While most teams can pull total AI spend from their provider dashboard, they can’t see which workflow or agent actually drove it, or which feature owns the spike. Multi-step agent behavior collapses into a single line item. You know money is being spent, just not why it’s happening or who owns the cleanup. For many teams now deploying agents, this has become a shadow tax showing up on invoices long after the spending pattern is already baked in.
Thinking in jobs and squads
One reason this feels abstract at design time is that dev teams tend to think in API calls and token counts. But tokens measure what a model consumes, not what it produces. Two agents can do the same job on paper and have drastically different economics in production. One takes a clean path while the other loops, retries, calls extra tools, and blows the unit cost up. Yet both look identical in a token dashboard.
The more useful model is constructed around jobs and squads. A discrete unit of work, a job could be resolving a ticket or generating a quote. Squads are functional groupings of agents around a business function (customer support or sales, for example). When you apply limits at that level, agent governance becomes far more specific and, in turn, actually enforceable. It also gets you closer to the harder question: what did it all deliver and was it worth it? Can you pinpoint the cost-per-resolved-ticket for your agent deployment? Or the cost-per-qualified-lead it turned up? These are the numbers that turn agentic AI from a budget line into a business case, and they require tracking what a job spent alongside what it delivered. Did it convert and handle the work autonomously, or did it escalate to a human?
Governance at the execution layer
Monitoring observes but isn’t designed to intervene. What’s actually needed are controls that live inside the execution path that can stop unwanted agentic behavior before it compounds. Consider how payment systems handle fraud. Those systems aren’t sending a report after suspicious transactions clear. They are evaluating against a policy in real time and will reject it if it fails. Same mechanism as with the stock market, where circuit breakers halt trading during a crash, not after the fact. An economic circuit breaker for an AI agent is the same concept, and it lives in engineering.
Attribution must come first. Every agent action needs to carry context around which tenant triggered it and which feature or workflow owns it. As it stands now, many agents run on shared API keys with no link to a specific team or workflow. Finance can see the total bill but cannot point to an owner. Without that metadata attached at the call level, you cannot enforce anything because you cannot identify what you’re looking at.
From there, it’s about boundaries. Define what “spending too much” actually means before the agent goes live. Think of it as a P&L for each agent, where you understand the ROI and build in retry ceilings and spend velocity limits that trip whenever costs accelerate faster than anticipated.
Finally, no governance is complete without enforcement. The moment a boundary is hit, a circuit breaker kicks in and the job stops before anyone has a chance to intervene. A cancelled job is a controlled decision keeping minor logic issues from becoming a finger-pointing five-figure incident.
The invoice is a lagging indicator
Dev leaders getting this right can move faster because they understand exactly what things cost and where the lines are. Agent autonomy gets governable and optimization gets specific (rather than staying in a vague “don’t spend too much” mandate from finance). When a circuit breaker trips, it’s a data point worth reading.
The reason agents get expensive, and will continue to get more expensive, is because they’re doing something right with nothing in place to tell them when to stop. The good news is that it’s an engineering problem with an engineering fix. The invoice is coming either way.
Every agent you deploy today is making economic decisions on your behalf. The only question is whether you’ve given it an economic framework — or just an API key.
