Multi-Agent Systems Fail at the Merge, Not the Fan-Out

When a multi-agent workflow produces a bad answer, the branch that ran in parallel is almost never the culprit. The subagents did their jobs. What failed is the seam, the moment their summaries came back to a parent agent that has to reconcile them into one conclusion. That step gets a fraction of the design attention the fan-out gets, and it is where the reliability actually lives.

We run agent routines in production across three platforms, and this pattern has held consistently enough that it has changed how we design them. Everyone tunes the delegation. Almost nobody tunes the synthesis.

What actually breaks in a multi-agent system?

Fan-out is a well-understood move now, and for good reason. Anthropic reported that its multi-agent research system, using a lead agent with parallel subagents, outperformed a single-agent baseline by 90.2% on internal research evaluations. The mechanism is not magic. Each subagent gets its own context window, burns tens of thousands of tokens reading raw material, and hands back a condensed summary that is often only 1,000 to 2,000 tokens.

That compression ratio is the entire value proposition. It is also the entire problem.

A summary is lossy on purpose. The subagent read the source and made judgment calls about what mattered, and those judgment calls do not travel. The parent receives a conclusion without the reasoning that produced it, and it has no way to audit what got dropped. When two subagents return summaries that quietly disagree, the parent is reconciling two confident paragraphs whose evidence is gone.

We have written before about when fanning out is worth it at all. This is the other half of that argument. Deciding to fan out is the easy call. Deciding what comes back, and what the parent does with it, is the hard one.

Why does the merge get so little attention?

Partly because it is invisible. A subagent that crashes is loud. A subagent that returns a plausible, well-written, subtly wrong summary is silent, and the parent will happily build on it.

Partly because the merge does not look like engineering. Fan-out has a satisfying shape: split the work, run it wide, collect the results. The merge looks like the boring bit at the end. In practice it is the only step where the system has to exercise judgment across everything at once, which makes it the step most exposed to the failure mode everybody is already worried about.

That failure mode is context pressure. Chroma's context rot research found that as the number of tokens in a context window increases, a model's ability to accurately recall information from that context decreases. The older and foundational result points the same direction: Lost in the Middle (Liu et al., 2023) found that performance is highest when relevant information sits at the beginning or end of the input, and degrades significantly when a model has to pull something from the middle of a long context.

Now look at where the parent agent sits. It has been running the longest, it holds the task framing, it holds every summary that has come back so far, and it is being asked to do the most integrative reasoning of the entire run. It does the hardest thinking at the point where its context is fullest.

Bigger context windows soften this without solving it. As Sourcegraph put it in May 2026, larger windows reduce some pressure but do not eliminate it, since latency and cost grow with size and the same lost-in-the-middle patterns still apply. Even at two million tokens, you still want the model seeing only what is useful right now.

What separates a merge that holds from one that does not?

The distinction we keep coming back to is whether the parent is merging data or merging prose.

The fragile column is what you get by default. Nothing in that column is a bug exactly, which is why it survives so long in a codebase.

The durable column costs a little more upfront and changes the character of the failure. A structured return means the parent is doing assembly rather than interpretation, and assembly is a much lower-variance operation for a language model. Asking each subagent for its evidence alongside its conclusion means a wrong branch can be caught instead of averaged in.

The disagreement row is the one we would push hardest on. A parent handed two conflicting summaries will usually produce something smooth and reasonable that splits the difference, and smooth is exactly the wrong output for a genuine contradiction. Conflicts should be loud.

How do you harden the seam?

Five things we do, in rough order of payoff.

Ask for structure, not prose. Give every subagent an output schema. The parent should be merging fields, not parsing paragraphs. This single change removes most of the interpretive burden from the exact step that can least afford it.

Make each subagent return its evidence. A claim with a source attached can be verified. A claim on its own has to be trusted. The token cost is real and it is worth it on anything consequential.

Decide the failure policy before you run it. On a wide fan-out, some branch will return nothing, time out, or error. If you have not decided what that means, the default is silent omission, and a missing branch reads exactly like a branch that found nothing. Those are very different facts.

Log what each branch actually returned. When a multi-agent run produces a bad answer, the parent's final output tells you nothing about which branch was wrong. Without per-branch logs you are debugging a conclusion instead of a process. This is the same argument we made about agent observability, pointed at the specific place it hurts most.

Keep the parent's context clean. The parent should hold the task, the structured results, and little else. Every extra token in the parent's window is competing for attention with the synthesis step. This is ordinary agent orchestration methodology, applied where it matters most.

Where this shows up in our own work

We run production agent systems for Smile PreVue, RunLink, and Howdy Dispatch, plus the content and monitoring routines that keep our own operation running. The rule of thumb we have landed on is simple enough to say in one line: fan out on reading, stay single-agent on deciding.

Reading is the ideal delegation. It has a high input-to-output ratio, a clean interface, and a result that compresses honestly. Sweeping a set of documents, checking many sources, auditing a codebase for one specific pattern. Those all work well in parallel because the answer really does fit in a paragraph.

Deciding does not delegate the same way. When the judgment lives in weighing the results against each other, splitting the work moves the difficulty rather than removing it. You end up with a merge step that is doing all the actual thinking, under the worst context conditions in the run.

The honest version of this is that we did not learn it from a diagram. We learned it from runs that came back confident and wrong, where every individual branch turned out to be fine on inspection.

Frequently asked questions

Is fanning out to subagents a bad idea? No. It is a strong pattern for the right shape of work, and the performance gains reported by teams running it are real. The point is that the fan-out is not the risky part, so that is not where your design attention should be concentrated.

Does a bigger context window fix the merge problem? It helps and it does not solve it. Recall still degrades with length, and cost and latency still scale. A clean small context beats a large full one.

How many subagents is too many? Cap it deliberately rather than discovering the limit through a bill. Multi-agent runs can consume many times the tokens of a single-agent equivalent, so the ceiling should be a decision, not an accident.

What is the cheapest improvement I can make today? Give your subagents a structured output format. It is usually a small change and it converts the merge from interpretation into assembly.

---

Most of the multi-agent advice available right now is about how to split work up. That part is largely solved. The part still worth engineering is what happens when the pieces come back, because a system that fans out beautifully and merges carelessly will produce answers that are confident, coherent, and wrong.

If you are building something that has to hold up in production, we are happy to talk through the architecture.