Software that breaks usually breaks loudly. An error gets thrown, a page goes blank, someone calls you. The failure announces itself and you go fix it.
AI agents have a failure mode that announces nothing. The system stays up. Every status light stays green. No error appears in any log. And it bills you the whole time it's doing nothing at all.
I know this failure well because metering every paid call is the first thing I build into the systems I deploy. That instrumentation is the only reason it's visible at all. It leaves no other trace, so you only find it by going and looking.
The most expensive thing an AI agent does is check whether it has work
A lot of AI agents are built to stay resident: the process runs around the clock and checks in on a schedule to see whether there's anything to do.
The cost isn't in the work. It's in the checking.
Here's the part nobody tells you, and it's a property of the technology rather than of anyone's code. The AI models behind these systems are stateless. They remember nothing between calls. So every time your agent checks in, it re-sends everything it knows, the instructions, the history, the state it carries, just to ask "anything for me?" You're billed for that entire re-send, whether the answer is yes or no.
Run that hourly and you're paying a subscription to ask a question that usually has no answer.
Now look at it from the outside. The process is running. The server is healthy. The agent is behaving exactly as designed: it was told to check every hour, and it is checking every hour. There is no error state for "expensive and idle."
An agent burning money doing nothing is operationally indistinguishable from an agent earning its keep. That is the entire problem.
Why the usual defenses miss it
Monitoring watches for failure, and this isn't failure. Uptime checks, error rates, health endpoints all report green, and they're right to. You can't alert on a condition your monitoring has no concept of.
Cost review runs monthly, and the burn runs hourly. By the time this reaches a normal review cycle, it's had most of a billing period to accumulate.
The spend often isn't visible where you're looking. Application logs record work performed. Tokens spent on a check-in that found nothing aren't work, so unless something meters every paid call, that spend registers nowhere except at the provider. Most instrumentation records what agents did, not what they cost.
How to check whether this is happening to you right now
You don't need a vendor for this and it takes about ten minutes.
Pull your daily AI spend for the last thirty days, not the monthly total. Every major provider shows this in their billing console.
Then look at the shape of the line. This is the whole test. Real work is spiky: it follows your business, climbing when your team is working and dropping at night, on weekends, over holidays. An idle agent checking on a schedule produces the opposite, a flat line that never sleeps, because 3am costs it exactly what 3pm does. If Sunday at midnight looks like Tuesday at 10am, something is running that isn't responding to your business.
Then divide. Take a week of spend and count what the system actually produced: emails drafted, reports generated, leads handled. Cost per useful output is a number most people have never calculated, and it tells you whether you're buying work or buying check-ins.
What to build instead
Five layers. What matters isn't any one of them, it's that each covers what the one before it misses.
Agents are bounded, not resident. Wake on a schedule, do one defined job, exit. Nothing stays running, nothing re-sends its context to discover it has nothing to do. If there's no work, no process exists to be billed for. That removes the failure structurally instead of watching for it.
Going bounded usually means running less often, and frequency is rarely load-bearing: most schedules are set by habit. They were answering a question nobody asked, every hour, at a price. If you're paying for "always on" and getting the same result you'd get from "wakes up when needed," you're paying for a design choice rather than for the work.
Every paid action is metered as it happens, recorded at the moment of spend and attributed to whatever spent it. This turns cost from an accounting artifact into an operational signal, which for this failure is the only signal there is.
Alerts fire on the provider's own reported total, not on the internal ledger. This is where most designs quietly fail. If your alerts watch a number your own software computes, any spend that software failed to record is invisible to them too, and two layers you thought were independent share one blind spot. Reading the provider's figure is what makes the second layer genuinely second. Warn at half the budget and at four-fifths, so the limit speaks before it's reached rather than after.
When the ceiling is hit, the system stops and asks rather than going dark. This one isn't detection, it's a decision about what follows detection. A cap that kills work mid-task is its own kind of failure, and a control that hurts people once gets switched off, after which it protects nobody.
A spending limit at the provider itself. This is the layer that gets skipped most often and the one I'd argue matters most, because it's the only one your own software can't be wrong about. Every other control depends on code behaving correctly, and code is the most likely thing to be wrong here. A limit in your provider's billing settings stops charges cold regardless of what any process decides. It takes about four clicks, and if you do nothing else after reading this, do that.
How the layers actually cover each other
Trace the failure through them. A bounded agent can't quietly burn, because nothing is resident to burn. If a design drifts back toward always-on, metering surfaces it within a day rather than within an invoice. If that spend never reaches the meter, the alerts still see it, because they read the provider's number rather than ours. And if all of those fail, the provider's own limit ends it without anyone's permission.
Three layers detect, one decides how to respond, one is the backstop. None of them is clever. The design is that you never depend on one being right.
Three questions worth asking anyone who sells you AI
Send these verbatim. I've added what a real answer sounds like, because a question you can't score is just a question.
1. Does the agent exit when there's no work, or stay running and check in? A good answer names the schedule and what triggers a run. A dodge says "it's always available" without saying what that costs.
2. Do you meter spend as it happens, against a cap, and where does the alert read its number from? A good answer distinguishes their own tracking from the provider's billing figure. A dodge says "we monitor usage," which is a description of a dashboard, not a control.
3. Is there a spending limit set at the provider itself? A good answer is yes, with the amount. A dodge explains why their internal controls make it unnecessary, which is precisely the argument that fails when the internal controls are what broke.
Clean answers to all three tell you someone treated cost as an architecture problem. Anything vaguer is a request that you trust the architecture on faith, and faith is a poor control.
One reply, thirty seconds
Run the flat-line test on your own billing console this week. If the line doesn't sleep, reply and tell me what you're running, and I'll tell you plainly whether that pattern explains it. No pitch, no call required.