An agent burns a month of its budget over a single weekend, and nothing on the dashboard looks wrong. I’ve seen this happen more than once, and it always has the same shape.
Every request returns a 200. Latency sits inside the SLO. CPU is flat. The on-call graphs are the calm, boring green you want them to be.
The only sign anything has happened is the bill. An agent that normally costs a few dollars a day has spent a few hundred over two nights — calling the same tool with almost the same arguments, over and over, thousands of times, getting a clean response every single time, and never once deciding it was done.
That’s the strange thing about how agents fail. We spent fifteen years learning to monitor software that fails loudly — it throws, it times out, it returns a 500, and something pages you. Agents have invented a new category: the failure where everything works, and money disappears. The tell isn’t an error. It’s the absence of progress underneath a stack of perfectly successful calls.
Agents have invented a new category: the failure where everything works and money disappears.
Application monitoring answers three questions: is the service up, how fast does it respond, what fraction of requests fail. Uptime, latency, error rate. Those signals were designed for a world where one request produces one response, and cost depends on how many servers you rent.
An agent breaks every one of those assumptions. One goal goes in. An unknown number of steps come out. It carries state between calls, takes actions through tools, and decides for itself how hard to try before it stops. Its real behavior doesn’t exist in the code you deployed—it exists only at runtime, in the specific path it took this time.
So the object you need to watch changes. Traditional monitoring tracks the request. What you actually need to track is the goal: how many reasoning steps the agent took, how many tool calls it made, how many tokens the whole session consumed, and whether the same move keeps repeating without getting closer to done. A single goal can fan out into hundreds of model calls, and each can succeed while the session as a whole goes nowhere.
This stays invisible because each piece reports success on its own. A per-call rate limit caps one request; it has no idea that one goal just triggered nine hundred of them. A health check confirms the service is alive — and a perfectly alive service can loop forever.
And the money moves faster than in any system you’re used to. Anthropic reported that in its own production data, agents tend to burn through roughly 4× the tokens of a chat interaction, and multi-agent setups around 15×. Sit with that multiplier for a second. A glitch that would have cost you two dollars in a chatbot costs thirty in an agent — before anything on your dashboard so much as blinks.
Most writing on this topic stops at “you should monitor your agents,” which is about as useful as being told to watch your spending. The interesting question is what specifically to watch for. In practice, three patterns account for most runaway spend, and each leaves a distinct, catchable signature.
Loops. The agent repeats the same action without making progress. In a trace, this is a run of sibling calls with the same tool name and near-identical arguments, each returning fine, with none adding anything new to what the agent knows. The nice part is that catching this is a comparison problem, not a machine-learning one — you hash the tool name plus its normalized arguments and count how many times it repeats in a row. Three in a row can be a retry. Ten in a row is a loop.
This isn’t a rare corner case. A team at UC Berkeley built MAST, a taxonomy of how multi-agent systems fail, from more than 1,600 annotated execution traces across seven frameworks. Two of the fourteen failure modes they documented are* essentially that the agent repeats itself and doesn’t know when to stop*. This is one of the most common ways these systems break.
Drift. The agent’s behavior slides away from the task it was given, without any single step being obviously wrong. Nobody makes a mistake; the goal just quietly mutates. What makes drift expensive is that it produces work — plausible, well-formed, completely billable work that nobody asked for. You catch it by comparison too: embed the original goal, embed each new output, and watch the semantic distance between them over the session. One far-off step is noise. A curve that climbs, step after step, is drift.
Recursion. The agent spawns sub-agents, and those sub-agents spawn their own, with no ceiling on how deep it goes. Picture a planner that splits a goal into four sub-tasks, and each sub-agent decides its slice is still too big and splits it into four more. Every individual decision looks reasonable. But at a depth of five with a branching factor of four, one request quietly becomes more than a thousand leaf calls. Recursion has the ugliest cost curve of the three, because it multiplies instead of adds — and, happily, the simplest fix, because a hard cap on depth just ends it.
Naming a pattern is useless without a number attached. Four metrics do most of the work, and all four fall out of standard trace data you may already be collecting.
Token burn rate per session — total tokens over the session’s duration or completed steps. When it runs above roughly 3× an agent’s own rolling baseline, something’s wrong. This is your cheapest, bluntest catch-all for drift and runaway fan-out.
Recursion depth — the deepest the sub-agent call stack goes in a single run. For most production agents, a hard cap somewhere between 3 and 5 is plenty.
Repeated-call ratio — identical calls divided by total calls in a session. Above 0.3, go look. Above 0.5, it’s almost certainly a loop.
Cost per completed task versus cost per abandoned task. This is the one most teams skip, and the one your finance people actually care about. The first number tells you what the agent is worth. The second tells you what it costs you when it fails. Two agents with the exact same average session cost can have completely different economics if one abandons 5% of its runs and the other abandons 40% — and you can’t see that difference at all until you split the cost by outcome.
One caveat on all four: treat those thresholds as starting points, not gospel. The honest baseline is empirical and per-agent. Run the thing for a week, take the median of its own behavior, and set your ceilings relative to that — not to a number you read in a blog post, including this one.
Here’s the part that’s easy to get wrong, and that took us a while to accept.
There’s a good, mature ecosystem for the watching half of this. Tools like Langfuse, Arize’s Phoenix, and LangSmith give you tracing, session grouping, cost attribution, drift analysis, evaluation scoring — a genuinely rich picture of what your agent did and why. If you don’t have any observability on your agents yet, start there; that’s the first, non-optional step, and I’m not knocking any of it.
But observation ends at the alert. These tools mostly sit beside the execution path, consuming telemetry after the fact. They can tell you, brilliantly, that an agent spent four hundred dollars looping last night. What they structurally can’t do is refuse the four-hundred-and-first call, because by the time the trace reaches them, the call already happened.
And the timing math is brutal. An agent looping at 30 calls a minute, dragging 10,000 tokens of accumulated context along each time, moves something like 300,000 tokens a minute — on the order of a dollar a minute, per agent, for as long as it runs. An alert that reaches a human in fifteen minutes has already let the whole incident play out. Overnight, “fifteen minutes” becomes eight hours.
Stopping it — actually stopping it — means putting the limit in the path, not beside it. Every model call, tool call, and retrieval an agent makes has to leave the process to go somewhere. Route that outbound traffic through a single choke point, and you get the one place where a ceiling can be enforced rather than merely recorded: max cost per task, max tokens, max time, max recursion depth, with an automatic stop the instant one is crossed. Watching catches the pattern. Only enforcement ends it. Mature teams run both — alerts to investigate, hard ceilings to contain.
You could read all of the above as a niche ops problem. It isn’t. Gartner forecast that more than 40% of agentic AI projects will be canceled by the end of 2027, and it named escalating costs and inadequate risk controls as reasons. Those aren’t model failures. Nobody’s canceling these projects because the LLM wasn’t smart enough. They’re governance failures — the gap between an agent that works in a demo and an agent you can safely let run unattended against a live budget.
Runaway agents live right in the center of that gap. They’re not a sign your model is bad. They’re a sign you’re flying an autonomous system with instruments built for a manual one. The fix isn’t a smarter model. It’s naming the failure modes — loops, drift, recursion — measuring the handful of numbers that expose them, and putting the stop where it can actually stop something.
Disclosure: I work on tooling for AI agent governance, so this is a problem I think about professionally — and, yes, with some bias. I’ve kept this piece about the problem, not any product.
The AI Agent Failure That Never Throws an Error was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.