When to reach for it
- The input is naturally segmentable and tasks are independent to reduce latency (sectioning).
- Robustness is more important than single execution costs (voting).
Parallelization.
Split the work. Run in parallel. Merge the results.
Independent subtasks are processed in parallel and either merged (sectioning) or the best result is selected via an aggregator (voting).
When it backfires
- Strong dependencies exist between segments.
- Semantic merging is difficult.
- Latency and token budgets are strictly limited.
The tradeoff
Lower latency and higher robustness are gained against increased integration complexity and multiple execution costs.
What it actually does.
Independent sub-tasks run at once, then combine.
Two ways this pattern will hurt you.
Chunks that aren't actually independent
The split creates chunks that share implicit context. Workers produce incompatible partial results that can't be merged.
Fix · Validate independence before splitting. If chunks share state, use a pipeline instead of parallelization.
Join logic assumes uniform chunk shape
One worker returns a list, another returns a dict. The join step crashes or silently drops data.
Fix · Define a schema contract for every worker output. Reject non-conforming responses before merging.
Where Parallelization is native.
Microsoft Agent Frameworkconcurrent agentsNative
Anthropic Cookbookdocumented as a recipeAdaptable
Next pattern