How do I stop AI agents from looping or running up costs?
Updated · DBShifts
Short answer
Track the chain of calls each request sets off and limit it: how deep it goes, how often one agent is called again, how often a request repeats, how fast it fans out, its total calls and cost, and how long it runs. When a limit is crossed, stop the whole chain, not just one call.
Key facts
- A loop between agents usually shows up as the same request repeated, or an agent called again in the same chain.
- Limits have to be per chain: per-agent rate limits miss a loop spread across several agents.
- Fan-out, many calls from one chain in a short time, is the other shape of a runaway.
- Stopping the whole chain is safer than refusing one call, which the agent may simply retry.
- A cost cap needs agents to report their cost; the call graph alone does not know it.
How agent chains run away
Two agents delegate a task back and forth. A planner retries a failing step forever. A task fans out into subtasks that fan out again. Each call looks reasonable on its own; the chain is the problem, and per-agent limits do not see chains.
Limits that catch it
Depth: how many agents deep one request may go. Revisits: whether an agent may be called again in the same chain. Repeats: the same request, ignoring case, spacing and numbers, more than a few times. Fan-out: calls per few seconds. Totals: calls per chain and reported cost per chain. Time: how long a chain may keep making calls.
What should happen when one trips
Stop the chain, so every further call in it is refused, retries included. Record why. Count it against the agent that made the call, and pause an agent that keeps tripping limits until someone looks. Let a person stop any chain by hand from its trace.
Checklist
- 1
A chain id carried on every call
- 2
Limits on depth, repeats and revisits
- 3
A fan-out limit per short window
- 4
Call and cost budgets per chain
- 5
A maximum chain lifetime
- 6
Automatic pause for an agent that keeps hitting limits
Common mistakes
Rate-limiting each agent separately
A loop across three agents can stay under every agent's own limit while running all night.
Refusing the call but not the chain
Agents retry. Stopping the chain stops the retries with it.
Watching cost only on the invoice
By the time the model provider's bill shows the spike, the loop has already run. Count cost per chain as it happens.
How DBShifts does it
- DBShifts Agent Mesh gives every chain an id, also its W3C trace id, and counts its calls atomically.
- Limits per account: depth, revisits of the same agent, identical requests (case, spacing and digits ignored), calls per 10 seconds, calls per chain, reported cost (an X-Mesh-Cost-Usd response header) and chain lifetime.
- A chain that crosses a limit is stopped, every further call in it is refused, and the reason is recorded; owners can also stop a chain from its trace.
- An agent that keeps being refused is paused automatically after the number of refusals you set within a window.
Questions people also ask
What are sensible starting limits?
DBShifts starts at a depth of 6, one revisit, three identical requests, 20 calls per 10 seconds, 50 calls per chain and a 60-minute lifetime, with no cost cap until you set one. Tighten them once the traces show what real traffic looks like.
Does stopping a chain stop work already running?
No. Calls already in flight finish; every new call in that chain is refused.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.