Parallel (fan-out / fan-in)
The same input goes to several workers at once; results are merged at the end.
Shape：One to many, then many to one
When to use it
When subtasks are independent, divisible, and the merge rule is clear. E.g. asking three models the same question and comparing, or splitting a sector into twenty companies researched at once.
When not to
When subtasks have ordering dependencies, or when merging requires judgement rather than concatenation. Then parallelism just splits one hard problem into many invisible ones.
How it fails
- Attribution errors at the merge. Worker A's numbers end up inside worker B's conclusion — a real incident class this site has measured.
- Cost multiplies without quality gaining. Parallelism raises throughput, not any single worker's accuracy.
- Nobody handles deduplication or conflict. If two workers disagree and the merge just concatenates, the contradiction ships as-is.
Design notes
The merge layer carries more responsibility than the workers: it must attribute, deduplicate and resolve conflicts. Every merged datum should carry a pointer to which worker and which source produced it, or failures cannot be traced.
Origin
2025-06-13
Anthropic publishes the engineering internals of its multi-agent research system
https://www.anthropic.com/engineering/built-multi-agent-research-system