The previous lesson is not an argument against multi-agent systems. It is an argument against multi-agent systems applied to the wrong task shape.
There is a class of task where fan-out is not optional, not an architecture flourish, but the correct primitive.
The task shape looks like this: a large space needs to be explored, the exploration units are independent of each other, and the synthesis at the end is cheaper than the exploration itself.
That shape is real and common. When you see it, a single agent is the wrong choice — not because it cannot do the job, but because it will do it slowly and with worse coverage than N parallel agents can.
Anthropic's research-system essay is the clearest published argument for this regime. The task was: given a research question, explore a large document space and synthesize findings.
No single agent can read everything in time. Multiple agents can divide the space, explore in parallel, and hand their findings to an orchestrator.
The context fragmentation problem from Lesson 2 does not apply here because the agents are not supposed to share context. They are supposed to cover different ground. Fragmentation is a problem when agents must build on each other's work. It is not a problem when agents are working in parallel on non-overlapping pieces.
The picture
A grid of task shapes that fan out well.
Research across a document corpus: each agent reads a subset, produces a finding, synthesis is additive.
Parallel evaluation of candidates: each agent scores one candidate independently, scores are aggregated.
Multi-perspective synthesis: each agent argues a position from one viewpoint, the orchestrator compares positions.
Broad search: each agent explores one branch of a decision tree, the orchestrator picks the best branch.
The shared property across all four: minimal cross-agent dependency. Each agent can complete its work without knowing what the others are doing. The agents are not collaborating; they are dividing.
That is the distinction that makes fan-out safe. When agents must collaborate — when the output of one changes what the others should do — fan-out introduces the context fragmentation problem from Lesson 2. When agents are dividing, that problem does not arise.
Why it matters now
Anthropic's research-agent counter-essay is the clearest published argument for when multi-agent wins. The important word is "when."
The essay does not argue that more agents are better. It argues that a specific task shape — explore many things in parallel, synthesize at the end — is exactly the regime where context fragmentation does not matter, because the agents are not supposed to share context.
The distributed computing literature has been naming this pattern for thirty years under the term "embarrassingly parallel": work that can be divided into independent units with no inter-unit communication. The term is not pejorative. It means the parallelism is obvious and the coordination overhead is near zero.
When you have embarrassingly parallel work, single-threading it is the waste.
The cost of fan-out is real — coordination overhead, quota management, debugging complexity — but it is fixed. The benefit scales with N. When N is large and the units are truly independent, fan-out wins on every dimension that matters.
A source you should trust
- Anthropic, "How we built our multi-agent research system" (2024). Primary source. Read with the task-shape framing from this lesson active; notice the specific properties of the task that made fan-out right.
- The map-reduce literature broadly. Distributed computing has thirty years of practice on identifying embarrassingly parallel work. MapReduce (Dean and Ghemawat, 2004) is the canonical framing. Borrow it. The map phase is your fan-out; the reduce phase is your synthesis.
A recipe
A four-question test for "is this a fan-out task?":
- Can the work be split into N independent units, where each unit has a clear boundary and does not require knowledge of what other units are doing?
- Does each unit complete without needing to know the results of any other unit before finishing?
- Is the synthesis at the end cheaper than the parallel exploration? If the synthesis is itself the expensive step — reconciling N conflicting results, resolving inter-unit dependencies — the fan-out did not save you anything.
- Is the variance across units high enough that exploring them all adds genuine value, rather than finding that most units produce the same output?
If yes to all four, fan-out is right. If no to any one of them, return to Lesson 2.
The smell of it going wrong
The most common error is designing a fan-out for work that has hidden cross-unit dependency. The units look independent on the whiteboard but are not in the problem. The agents begin in parallel, and then one of them produces output that should have changed how another one proceeded. At that point the system is not parallel — it is just wrong and fast.
The second error is a synthesis step larger than the exploration. When the synthesis agent has to do more work than any of the exploration agents, the bottleneck is the synthesis, not the exploration. You did not speed up the job; you moved the bottleneck to the end and added coordination overhead on top.
The third error is small N. A fan-out of two or three agents introduces all the coordination overhead of multi-agent design — handoff contracts, quota management, observability requirements — for a parallelism gain that barely matters. Single-agent with efficient sequential processing is usually faster for N less than five, assuming the task fits comfortably in one context window.
A judgment call from real work
PL parallel-triage of GitHub issues passes all four questions cleanly.
Each issue is independent: fixing one does not require knowing the state of any other. The variance is high: some issues are trivial, some require multi-file changes, and there is no way to know which is which without reading them. The synthesis — reviewing the resulting PRs — is cheap relative to the per-issue exploration. The fan-out factor is large: backlogs routinely have twenty or thirty items, making parallelism genuinely valuable.
The design reflects this: one subagent per issue, spawned in its own worktree, no cross-talk, parent collects the results. The agents are not collaborating. They are dividing.
Contrast with a fan-out that would not work: refactoring the PL content-collections schema across all MDX files simultaneously. The changes interact — the schema change propagates to every file, and two agents making conflicting assumptions about the new schema produce merge conflicts and incoherent output. That is a sequential task, even though it touches many files. The four-question test catches it on question one.
Apply lever, risk, rollback. Lever: fan-out multiplies exploration coverage without multiplying calendar time. Risk: if the task has hidden dependencies, fan-out produces parallel-but-wrong, which is harder to debug than sequential-and-wrong. Rollback: if the fan-out proves incorrect, the single-agent fallback is always available; the cost is the time spent designing the multi-agent system, not a sunk architectural investment.
Rules from this lesson
- Fan-out is correct when the task shape is embarrassingly parallel; the four-question test is cheap, use it before committing to N agents.
- Cross-unit dependency is the disqualifier; if units cannot complete without knowing what other units are doing, it is not a fan-out task.
- Synthesis cost matters; a synthesis step larger than the exploration step erases the parallelism gain entirely.