Guardrails & Control · 2 min read

Telling a busy agent from a broken one

A healthy agent working hard and an agent stuck in a loop both make lots of calls. Kill the wrong one and you break your product. Here's how to tell them apart from the traffic alone.

By Akhil Anand · October 8, 2026

The naive runaway-agent detector is a rate limit: more than N calls a minute, stop. It catches loops. It also catches your best customer's agent doing a legitimately large job — researching, planning, calling tools, writing — and kills it halfway through.

That's the real problem with agent guardrails. Volume isn't the signal. A busy agent and a broken one can make the same number of calls. What differs is the pattern.

What a broken loop looks like

Runaway agents tend to fail in two recognizable ways.

The dumb loop. The same request, again and again: same model, same input size, near-identical token counts. A retry with no backoff, or an agent re-asking a question it can't resolve. In the numbers, it's a run of identical fingerprints.

The smart loop. Subtler and more expensive. Each call carries the previous call's output in its context, so the prompt grows every turn — 4,000 tokens, then 6,000, then 9,000 — on the same model, with steady growth. The agent isn't repeating itself; it's spiraling, and each lap costs more than the last.

What a busy, healthy agent looks like

A productive agent varies. It calls different models for different steps, its payload sizes jump around as it moves between tasks, and its work spreads across features. Its bursts have structure rather than monotony.

Volume tells you an agent is working. Similarity tells you whether it's working or stuck.

Scoring the difference

AtlasBurn fingerprints traffic in 30-second windows and weighs several signals together: burst density, how homogeneous the model mix is, how similar the payloads are, and how concentrated the calls are on one feature. That produces a retry rate and a loop probability, rather than a single tripwire.

On the enforcement side, the patterns are separate detectors with different levels of confidence, so they get different actions. Four near-identical calls inside 30 seconds is a loop. Context that at least doubles across a fast burst on the same model is a runaway spiral. Both suspend. A raw request-rate burst, which could still be legitimate, only throttles. And you set the ceiling: in alert-only mode nothing is ever cut, it's just reported. Every intervention lifts automatically when it expires.

Why this matters more every month

As agents take on longer, multi-step work, the cost of a false positive goes up: you're not dropping one request, you're aborting a task a user is waiting on. Guardrails that can't tell busy from broken force a bad choice between overspending and breaking your product.

The answer isn't a lower rate limit. It's a detector that reads the shape of the work.


Try AtlasBurn free