Multi-agent systems fail in predictable, maddening ways. The agent that was supposed to research quietly starts rewriting the shared notes file. The reviewer agent approves work that was never finished. Two agents edit the same file and silently overwrite each other. And the classic: your agents pass a task back and forth like a hot potato until the token bill looks like a car payment.
None of these failures are model quality problems. The models are fine. The problem is coordination: agents have no instinct for when to stop, who owns what, or how to resolve a disagreement. They do exactly what the architecture lets them do, and most architectures let them trample each other.
This guide covers the five failure modes that actually break agent teams, how to diagnose each one from the logs, and the design fixes that stop them from recurring. If your agent team is fighting, looping, or stealing each other’s work, start here.
Failure Mode 1: The Endless Loop
The loop is the most expensive failure mode because it does not look like a failure. Every agent looks busy. Progress bars move. Logs fill up. And nothing is getting done, because Agent A keeps handing work to Agent B, who hands it back to Agent A, who hands it back again.
Loops usually start with ambiguous handoff contracts. If Agent A’s instructions say “review the draft and route it back if it needs changes,” and Agent B’s say “check for issues and return for revision,” you have built a perfect ping-pong machine. Each agent dutifully finds something slightly imperfect and sends the work back, forever.
How to diagnose it: Look at the handoff log, not the output log. Count how many times the same artifact ID changed hands. If the same document was passed more than three times, you have a loop, not a review process.
How to fix it: Every handoff contract needs an exit condition, not just a condition for sending work back. Add explicit rules: “If changes are minor, apply them yourself and pass to publish. Only return for revision if a section is missing entirely.” And add a hard iteration cap. Three passes, then the orchestrator takes over and decides. Our guide to stopping an agent stuck in a loop covers the same principle for single agents, and it applies double for teams.
Failure Mode 2: Agents Fighting Over Shared State
Give two agents write access to the same file, document, or database row, and they will eventually fight. Agent A writes its research findings to the shared notes file. Agent B, working from a stale cached copy, writes its updates to the same file and silently deletes Agent A’s section. No error. No conflict warning. Just lost work.
This is the classic race condition, and agent teams make it worse because each agent operates in its own context window with its own view of the world. Neither agent knows the other just wrote to the same place.
How to diagnose it: Compare the shared artifact’s state against the sum of each agent’s reported actions. If Agent A’s log says it wrote section 2, and the final file has no section 2, something overwrote it. Check timestamps in the file history.
How to fix it: One writer per artifact. If two agents need to contribute to the same document, they should write to separate files and a third process merges them. This is the single highest-value rule in multi-agent design: never let two agents write to the same path. You can also use append-only logs for shared state, where agents only add entries and never rewrite existing ones.
Failure Mode 3: Stealing Each Other’s Work
Duplicated effort is the quiet killer. Two agents both see “research competitor pricing” on their task list, and both do it. You pay for the research twice, and you get two slightly different answers, and now you have to reconcile them. Worse, one agent finishes a task and another agent, not knowing it is done, redoes it from scratch.
This happens when the orchestrator hands out tasks without a shared ledger of what is in progress and what is complete. Agents cannot see each other’s task lists unless the architecture shares that state.
How to diagnose it: Search the logs for two agents calling the same tool with the same arguments within a short window. Duplicate web fetches, duplicate file reads, duplicate API calls are the fingerprint.
How to fix it: A shared task registry with explicit states: pending, in progress, done, blocked. Agents check the registry before starting work and claim tasks atomically. If a task is already in progress, they skip it. This is a small piece of infrastructure that eliminates an entire class of waste.
Failure Mode 4: The Rubber-Stamp Reviewer
You added a reviewer agent to catch errors, and it approves everything. The review step is theater. The reviewer shares the same model family, the same training data, and often the same prompt style as the producer, so it tends to agree with the work in front of it. Confirmation bias is baked into the architecture.
How to diagnose it: Check the reviewer’s revision rate. If it approves 95% of submissions without changes, it is not reviewing, it is stamping. Also check whether the reviewer actually re-verified facts or just read the summary.
How to fix it: Give the reviewer an adversarial prompt, not a cooperative one. Explicitly instruct it to find at least three specific problems or to verify every claim against a source. Better yet, make the review verifiable: the reviewer must cite the exact source for each factual claim, and the orchestrator checks that citations exist. If the reviewer cannot produce citations, the review fails. Independent verification is the one place a second agent genuinely pays for itself, but only if you force it to actually verify.
Failure Mode 5: The Orphaned Handoff
Agent A finishes its work and passes it to Agent B. Agent B never picks it up. Maybe B crashed, maybe B’s context expired, maybe the handoff went to a queue that nobody reads. Either way, the work sits there, and the pipeline appears to hang forever with no error message.
How to diagnose it: Look for a handoff record with a status of “sent” that never becomes “received.” The orchestrator log will show Agent A completing, and then silence.
How to fix it: Every handoff needs a timeout and a dead-letter path. If a task is not picked up within N minutes, the orchestrator should retry it, reassign it, or flag it for a human. Treat handoffs like message queues: they need acknowledgments, retries, and timeouts. In OpenClaw, the sub-agent model handles this cleanly when you wait for completion events, but you still need a timeout on the wait if you are running long pipelines.
The Debugging Workflow That Catches All Five
When a team misbehaves, do not stare at the final output. Work backward through the system in this order:
- Check the orchestrator log first. It shows the intended sequence: who was supposed to do what, in what order.
- Then check handoff records. Every transition between agents. Look for loops (same artifact passed repeatedly), orphans (sent but never received), and duplicates (same task claimed twice).
- Then check per-agent logs. Only now compare what each agent actually did against what the orchestrator asked for.
- Then check shared state. Compare the final state of any shared file or database against the sum of agent actions. This is where overwrites and lost work show up.
If you skip straight to the output, you will blame the model. The model is almost never the problem. The coordination layer is the problem, and the coordination layer is the part you control.
Design Rules That Prevent All Five
Steal these rules for your next team, and most of this article becomes irrelevant:
- One writer per artifact. No exceptions. Two agents never write to the same path.
- Every handoff has an exit condition. If it can bounce back, it will bounce back. Add caps and escalation.
- Shared task registry with states. Pending, in progress, done, blocked. Agents claim tasks; they do not guess.
- Verifiable reviews. Reviewers must produce evidence, not opinions.
- Timeouts on everything. Handoffs, tool calls, waits. A hung pipeline should fail loudly, not silently.
These are not advanced patterns. They are the same rules reliable distributed systems have used for decades, applied to agents. The teams that work are not the ones with the smartest models. They are the ones with the most boring coordination layer.
The Verdict
Agent teams fail in human ways: they fight over resources, duplicate work, rubber-stamp each other, and pass responsibility forever. The good news is every one of those failures is a design failure, not a model failure, which means you can fix them with architecture instead of waiting for a better model.
Build your team around ownership rules and handoff contracts, then debug it from the orchestrator log down. Do that, and your agents will spend their time doing the work instead of fighting each other for the right to do it.
Before you wire up the orchestration, check whether you need a team at all, and how to design handoffs that do not loop. Both guides are quick reads and will save you real token money.
About The Author
