Once you start splitting a task across several Claude Code subagents instead of running it in one long session, you inherit a new category of bug. Not a bigger pile of the same bugs, a different kind. A single agent either gets the answer right or wrong and you can usually tell which from the output. A fan-out of five parallel agents can each return something that looks locally correct and still add up to a wrong result, because the thing that broke was the coordination, not any one agent’s reasoning.
I noticed this the hard way running periodic multi-agent checks across a handful of self-hosted services: network controller status, backup verification, container health. Early on my only failure response was “retry the step that looks wrong.” That works embarrassingly often, which is exactly what makes it a trap: it works often enough that you stop asking whether it worked for the right reason.
Three tiers, one retry strategy, two tiers where it fails
Split the failures that show up in a multi-agent run into three buckets, because they don’t respond to the same fix.
Tool-invocation errors. A subagent’s tool call fails outright: a command errors out, a connection times out, a malformed argument gets rejected. These recover on retry almost every time, because the failure was transient and local to one step. This is the case your instinct handles correctly by default.
Ambiguous delegation. A subagent got a task that was underspecified, and it did something reasonable but not what you meant. “Check if the backup service is healthy” can mean “is the process running,” “did last night’s job succeed,” or “is the data actually restorable,” and an agent will pick one without flagging the ambiguity. Retrying with a sharper prompt recovers this maybe a third of the time. The rest needs a human to notice the mismatch and rewrite the task.
Latent failures. These don’t recover on retry at all, because retrying re-runs the same flawed setup. Three shapes show up repeatedly:
- Context pollution: a later stage consumes stale context from an earlier one. This gets worse once you start forking subagents that inherit the parent’s full conversation, because whatever stale assumption the parent was carrying rides along into every fork. A forked agent checking “is the tunnel still up” after the parent already decided it was will cheerfully agree, using the parent’s memory instead of checking.
- Conflicting outputs: two subagents report incompatible facts about the same thing, and nothing in the pipeline reconciles them. One agent reads a config file, another queries a live API, they disagree by a version number, and the fan-in step picks one silently instead of surfacing the conflict.
- Premature action: an agent acts before the thing it depends on, another subagent’s result or a file it needs, was actually ready. This is a race condition with a natural-language interface, which makes it harder to spot in the output because the agent will write a confident-sounding paragraph about a state that hadn’t settled yet.
None of these three show up as an error. The run completes, every subagent returns a plausible-looking result, and the mistake is in how the pieces fit together, not in any individual piece. That’s why retrying the whole pipeline and hoping doesn’t work: you get the same plausible-looking wrong answer a second time.
The check that actually catches them
The fix isn’t more retries, it’s a deliberate reconciliation pass after any multi-agent run, before treating the result as final. Three questions, applied to the assembled output rather than to each subagent in isolation:
- Do any two subagents disagree on the same fact (same host, same metric, same config value)? If so, that’s a conflict to resolve, not an average to compute.
- Did a later stage act on an earlier stage’s output that could itself be stale or superseded by something discovered afterward?
- Did anything act, write, deploy, notify, before its specific dependency was confirmed ready, rather than just assumed ready?
If the answer to any of these is yes, the fix is re-running the specific stage with corrected or reconciled input, not re-running the whole pipeline from scratch. Re-running from scratch burns tokens on the two tiers of failure that already work fine on retry, while leaving the actual latent failure untouched, because the setup that caused it hasn’t changed.
One more thing worth doing after the fact: when you do find a latent failure, write down which component actually caused it. Was it the model drawing a wrong conclusion from correct inputs, a specific tool returning stale or malformed data, or the orchestration logic itself (a fan-in step that assembled inputs incorrectly, a stage that ran before its dependency was ready)? Without that attribution, a recurring failure pattern looks like three unrelated incidents instead of one root cause showing up three times. “The config-reading tool is occasionally stale” is a fixable, specific claim. “Sometimes the agents disagree” is not.
Depth makes this worse, not better
It’s tempting to assume a deeper pipeline, more fan-out stages chained together, is just more of the same risk spread thinner. It isn’t. The radius a single bad result can spread grows close to linearly with pipeline depth: a stale fact picked up at stage one can still be driving a decision at stage four, three fan-in steps later, with no single stage having done anything individually wrong. The practical consequence is that adding stages to a workflow should come with adding reconciliation checkpoints, not just adding more subagents and hoping the fan-in step sorts it out.
The boring version of all this: parallel agents don’t make a task more reliable by default, they make it faster and introduce a new way to be wrong. Whether the speed is worth it depends on whether you’re willing to do the reconciliation pass afterward. Skipping that pass to save time is how you end up with a report that looks thorough and says something false.