An agent calls the same tool forty times in a row with near-identical arguments. It doesn't crash. It doesn't throw. Every response is a 200, latency sits inside the SLO, CPU is flat – and the session quietly spends a week of that agent's normal budget before anyone opens the billing dashboard. The tell isn't an error – it's the absence of progress underneath a stack of perfectly successful calls.
Conventional APM can't see this because, from an infrastructure point of view, nothing is wrong. That is the gap AI agent observability exists to close: it measures what the agent actually did – iterations, token burn rate, recursion depth, repeated tool calls – not whether the service running it stayed healthy. Below: three failure patterns worth naming, the metrics that detect them, and the point where detection has to become enforcement.
Why Traditional Monitoring Doesn't Catch Runaway Agents – the AI Agent Observability Gap
Application monitoring answers three questions: is the service up, how fast does it respond, what share of requests fail. Uptime, latency, error rates – signals designed for systems where one request produces one response and cost tracks infrastructure hours rather than output volume. Autonomous AI agents invert nearly every one of those assumptions. One goal goes in; an unknown number of steps come out. The agent is stateful, carries context between calls, acts through tools, and decides for itself how hard to try. Its real behavior only exists at runtime.
Agent observability measures a different object than application monitoring. Application monitoring tracks the request; agent observability tracks the goal – how many reasoning steps the agent took, how many tool calls it issued, how many tokens the whole session consumed, and whether the same call pattern repeats without moving closer to completion. A single goal can fan out into hundreds of model calls, and every one of them can return successfully while the session as a whole never converges.
The pattern is easy to miss because each component reports success independently. Per-call rate limits cap one request; they cannot see that a single goal just triggered nine hundred of them. A perfectly healthy service can loop forever.
The cost asymmetry makes this expensive fast. Anthropic reported in June 2025 that in its own production data, agents typically consume around 4× more tokens than chat interactions and multi-agent systems around 15× more. A malfunction that would have cost $2 in a chat product costs $30 in an agent product before anything looks abnormal. AI agent observability therefore has to collect telemetry data at the session and goal level rather than per call – per-agent usage, full prompt visibility, per-task benchmarking. That is the layer OptScale AI's Team & Agent AI Performance pillar is built on.
Three Patterns Worth Naming: Loops, Drift, and Recursion
Most writing on this subject stops at "monitor your agents." That isn't actionable. Three observable patterns account for the bulk of runaway spend, and each leaves a distinct signature in an agent trace.
Loop – repetition without progress
A loop is when an agent repeats the same action without making progress toward its goal. The observable signal is the same tool call, with identical or near-identical arguments, executed N times in sequence while the task state does not change.
In a trace, this shows up as sibling spans with the same tool name and matching argument hashes, each returning successfully, with no new entities entering the agent's context. Agent loop detection is therefore a comparison problem, not a machine-learning one: hash the tool name plus normalized arguments and count consecutive matches.
This is not an edge case. MAST – the Multi-Agent System Failure Taxonomy from UC Berkeley (Cemri et al., 2025), built from more than 1,600 annotated execution traces across seven multi-agent frameworks – lists both "Step Repetition" and "Unaware of Termination Conditions" among its 14 documented failure modes.
Drift – the task quietly changes
Drift is when an agent's behavior gradually diverges from the task it was given, without any single step being wrong. The observable signal is growing semantic distance between the agent's recent outputs and the original prompt or goal statement, usually alongside token usage climbing above the agent's own baseline.
Where this gets expensive is that drift produces work – plausible, well-formed, billable work that nobody asked for. Detection is comparative: embed the original goal and each successive output, then track cosine distance across the session. A rising curve over several steps is the anomaly pattern; one distant step is noise.
Recursion – depth without a ceiling
Recursion is when an agent spawns sub-agents or sub-tasks without a bounded depth limit. The observable signal is call-stack depth in the agent graph increasing over time with no enforced maximum – each level individually reasonable, the total unbounded.
Here's what that looks like in practice: a planner decomposes a goal into four sub-tasks, and each sub-agent decides its own sub-task is still too broad and decomposes again. At depth 5 with a branching factor of 4, one request becomes over a thousand leaf calls. Recursion has the worst cost profile of the three because it compounds multiplicatively – and the easiest fix, because a hard maximum depth stops it outright.
Metrics That Actually Catch This
Naming patterns is useless without numbers attached. Four AI agent evaluation metrics do most of the work, and all four are computable from standard trace and span data.
The fourth is the one most teams skip, and the one finance actually asks about. Cost-per-completed-task tells you what the agent is worth; cost-per-abandoned-task tells you what it costs when it fails. The ratio between them is the clearest single signal in AI agent analytics that an agent burns budget without producing value – two agents with identical average session cost have entirely different economics if one abandons 5% of runs and the other 40%.
Treat these as starting points. The right baseline is per-agent and empirical: run the agent for a week, take the median, set ceilings against observed behavior.
Monitoring vs Evaluation Tools – Where Each One Stops
The observation side of this category is well served. Langfuse offers open-source tracing, session grouping, prompt management, and per-trace cost attribution. Arize – and its open-source Phoenix project – concentrates on evaluation, drift analysis, and LLM-as-a-judge scoring. LangSmith gives step-level traces of agent workflows built on LangChain and LangGraph, plus dataset-driven evals. All three map onto OpenTelemetry's GenAI semantic conventions, which standardize attributes such as gen_ai.usage.input_tokens, define spans for agent invocations, and keep prompt bodies opt-in so sensitive data stays out of the trace backend by default – though that spec's agent portion was still marked Development in the 1.40.0 conventions as of April 2026.
To be clear about where the line is: these AI agent observability tools are built to show you what happened. They record the agent trace, score the output, and surface the anomaly on a dashboard. That work is necessary. But observation ends at the alert – most AI monitoring tools sit beside the execution path and consume telemetry after the fact, with no position from which to refuse the next call. That's a monitoring problem. Stopping it is a different one.
Setting Budget Ceilings, Not Just Alerts
Detecting a runaway agent is half the job. Stopping it before the invoice arrives requires sitting in the request path, not beside it. Consider the arithmetic: an agent looping at 30 calls per minute, carrying roughly 10,000 tokens of context per call, moves about 300,000 tokens a minute – on the order of a dollar a minute at current frontier-model input pricing, per agent, for as long as it runs. An alert that reaches an on-call engineer in fifteen minutes has already let the incident play out. Overnight, it runs for eight hours.
Gateway-level enforcement changes the shape of the problem. Every model call, tool call, and retrieval an agent makes has to leave the process, so routing that outbound traffic through one control point/gateway creates the single place where a limit can be applied rather than recorded. A budget ceiling set there is enforced: max cost per task, max tokens, max execution time, max recursion depth – with auto-stop the moment one is breached. AI agent anomaly detection at the same layer catches the pattern; the ceiling ends it.
This is where AI agent monitoring stops being a dashboard and becomes a control, and where runtime monitoring earns its keep: loops caught mid-execution, token bursts flagged live, unauthorized MCP servers and vector stores blocked rather than logged after the fact. It pairs directly with AI cost optimization, too – the same gateway that enforces the ceiling can compress context, align prompt caches and route to the best-value model that still meets quality, cutting the cost of the calls that should happen while eliminating the ones that shouldn't.
