Blog
Your multi-agent pipeline
needs a circuit breaker.
Two agents in our SuperBot pipeline got into a fight.
Web-Dev wrote code. QA flagged a regression. Web-Dev fixed the regression — but the fix introduced a new style issue. QA flagged that. Web-Dev fixed the style — which re-introduced the original regression. And so on.
Nobody was home. This ran for about an hour before we noticed. The bill was educational.
What went wrong
The pipeline worked exactly as designed. QA is supposed to dispatch back to Web-Dev when it finds issues. Web-Dev is supposed to apply fixes and re-submit. Neither agent was broken.
The problem was that our design had no upper bound. Agents could re-dispatch indefinitely, the same "fix this and resubmit" instruction could fire repeatedly, and there was no signal for "this has been going nowhere for a while — stop."
HTTP clients solved this decades ago. Call it a circuit breaker and everyone nods. The pattern just hadn't crossed over into agent orchestration yet.
The fix (three layers)
We added three layers to the dispatch path:
1. Dispatch dedup. Before an agent dispatches to another agent, hash the combination of (target agent, issue, task intent) and check if the same dispatch already ran in this session. If yes, don't dispatch — escalate for human review.
This alone killed the ping-pong. The "fix the style issue" dispatch had the same intent-hash every round, so the second attempt got deduped.
2. Circuit breaker. Track the number of rework cycles on an issue. Three is the soft limit, five is the hard limit. At three, the PM gets a warning and is asked to reassess scope. At five, the issue auto-assigns to a human and all agent work on it stops.
3. Scope rules. Agents can only modify files within the scope they were dispatched on. If Web-Dev is dispatched to fix a specific test failure, it can't drift into refactoring the module. This prevents the "fix one thing, break another" loop from being possible in the first place.
Why all three
Any one of these alone would have helped. All three together removed the failure mode entirely.
- Dedup stops identical dispatches (the cheap fast fail).
- Circuit breaker stops pipelines that are thrashing even when each dispatch is technically different.
- Scope rules stop the thrashing from being possible.
If you're building a multi-agent system, start with dedup — it's ten lines of code and catches the worst case. Add the circuit breaker when you see your first rework-depth-of-7 incident. Add scope rules once you've got enough traffic to notice patterns.
The meta-lesson
The instinct when a multi-agent system misbehaves is to make the agents smarter. "Add more guidance to the QA prompt so it doesn't over-flag."
That's a trap. Smarter prompts reduce the failure rate but don't eliminate it. At scale, a small failure rate becomes frequent incidents.
The better move is to bound the damage. Assume any individual agent turn can do something dumb. Design the orchestration so that dumb turn can't spiral.
Borrow from distributed systems. Circuit breakers, idempotency keys, bulkheads, backoff. All of it applies.
Your agents don't need to be smart enough to never disagree. Your orchestrator needs to be smart enough to notice when they've been disagreeing too long.
← Back to blog