B3 · Parallelization
Family: Workflows
Independent subtasks run at the same time, then a step aggregates their results.
Principle
The work is split into pieces that do not depend on each other and handed to several simultaneous calls. A final step gathers the results. You save time, or you get several viewpoints on the same object.
The problem it solves
Handling independent subtasks one after the other needlessly lengthens the response time.
When to use it
- The subtasks are truly independent and latency matters.
- You analyse the same object from several angles, for example legal, technical and financial, or run guardrails in parallel with the answer.
When to avoid it
- The work is cumulative and ordered: each step depends on the previous one (B1).
- Model quotas are tight, shared state is uncoordinated, or no rule settles conflicts between branches.
- The subtasks are not known in advance and must be decided along the way: prefer the orchestrator-subagents pattern (E1).
Common pitfalls
The anti-patterns that misuse this pattern, best established first. Each sheet describes the symptoms, the public incidents and the remedies.
Loop, stopping and orchestration
- AP39 · Unchecked propagation — One agent’s output becomes the next one’s input unchecked, and a local error ends up in the deliverable.
Synonyms by vendor
- Parallelization (sectioning) (Anthropic)
- Concurrent / fan-out/fan-in / scatter-gather / map-reduce (Microsoft)
- Parallel fan-out/gather (« la pieuvre ») (Google ADK)
- Multi-agent parallel (Google Cloud)
- Collaborative pattern avec response mixer (Google (Agents Companion))
- Workflow (graphe de tâches acyclique) (AWS Strands)
Neighbouring patterns
Sources
- Building effective agents — Anthropic (E. Schluntz, B. Zhang), 2024-12-19
- How we built our multi-agent research system — Anthropic (J. Hadfield et al.), 2025-06-13
Content reviewed on 2026-10-02