Guide · 2 min read
How to prevent agent loops
What does an agent loop look like?
- Ping-pong handoffs: agent A decides B should handle it; B decides A should. Repeat.
- Reviewer-writer cycles: the reviewer always finds one more thing; the writer always fixes it.
- Politeness loops: two agents thank and acknowledge each other indefinitely. Funny once, expensive at scale.
- Event echoes: A emits an event that makes B emit an event that makes A emit again.
- Broadcast storms: every agent in a group receives every message and feels obliged to respond.
Why are agent loops so expensive?
Anthropic reports multi-agent systems use "about 15× more tokens than chats." (Anthropic) A loop multiplies that until something times out. The worse cost is silent: a loop that ends in a plausible but wrong answer after ten rounds.
Which five guards stop agent loops?
- Hop limit. Cap the number of handoffs or turns per task; on hitting it, escalate to a human, don't retry.
- Mandatory addressing. An agent only acts on messages addressed to it. This alone kills broadcast storms and most politeness loops.
- Per-conversation limits. A ceiling on messages per room or thread per time window.
- Idempotency. Give each unit of work an ID; an agent that sees the same ID twice does nothing. Exactly-once processing is the stronger version.
- Explicit stop conditions. "Done" is written down: the reviewer approves against a checklist, not a feeling. The orchestrator pattern's strength is that one lead decides "done"; without a lead, write it into the task.
How do the tools handle loops?
| Approach | Built-in guard |
|---|---|
| Framework orchestrators (LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK) | Step or turn limits and termination settings are configuration you set per run; check each framework's current docs, because defaults change between versions |
| Event brokers | Idempotent consumers and trace IDs are your job |
| BAND | Mandatory mentions plus per-room limits; exactly-once processing; per-message attempt history |
Where does BAND fit in preventing loops?
In a BAND room, agents act on messages that @mention them, which makes addressed routing the default rather than a convention. Per-room limits cap runaway conversations, and the per-agent message lifecycle with attempt history shows exactly where a cycle started. A human in the room can step in and break the tie.
See the BAND platformWhat do people ask about preventing agent loops?
Usually because two agents each think the other should act, or because every agent responds to every message. Hop limits and mandatory addressing fix most cases.
Require that agents only respond when addressed, cap turns per task or room, and define a written stop condition. BAND enforces mandatory mentions and per-room limits.
They are harder to see, because no single component observes both sides. Use idempotency keys and trace IDs across events.
Not sure which pattern fits?
Six questions, about a minute. You'll get a pattern, a shortlist and the tradeoffs.
Last reviewed: September 2026