The Parallelization pattern distributes tasks across multiple LLM calls that can run simultaneously. This approach is particularly effective for processing multiple independent items or when different aspects of a task can be handled concurrently, significantly reducing overall processing time.
How it works
Task Decomposition: Break the problem into independent subtasks
Concurrent Execution: Dispatch all subtasks to LLM instances simultaneously
Result Aggregation: Collect and merge outputs from all calls
Synthesis: Combine results into final unified output
Key trade-offs
Latency: Reduced for batch workloads, increased for single items
Cost: Higher per-request but potentially lower total time
Consistency: May vary across parallel calls
Complexity: Requires result aggregation logic
Use cases
Batch processing of multiple documents or data points simultaneously
Multi-aspect analysis where different perspectives can be evaluated in parallel
Concurrent generation of multiple variations or alternatives
Distributed content processing for large-scale data analysis
Build This Pattern
Copy this prompt and paste it into Claude Code, OpenCode, Codex, or Cursor to implement this pattern.
Build a parallel LLM processing system that fans out tasks and aggregates results.
ROLE: You are a parallel processing system that distributes tasks to multiple LLM workers, handles partial failures, and aggregates results into coherent outputs.
CONSTRAINTS:
- Default worker count: 3; configurable per task with maximum of 10 workers
- Worker timeout: 15 seconds per worker; configurable per task
- Minimum worker threshold: if fewer than half succeed, return error instead of degraded result
- Workers must be isolated: failure in one worker does not affect others
- Aggregation must handle variable-length outputs from workers
TOOL CALLING:
- Use function calling for: dispatch_task(task_data, worker_count?, temperature_range?), aggregate_results(worker_results[], strategy?), get_worker_stats(task_id?)
- Each tool returns structured JSON with processing data and metadata
STRUCTURED OUTPUT:
- Worker result must return JSON: { worker_id: string, status: 'success' | 'timeout' | 'error', output?: string, error?: string, latency_ms: number, temperature: number }
- Aggregated result must return JSON: { task_id: string, strategy: string, worker_count: number, successful_workers: number, aggregated_output: string, worker_results: [{ worker_id: string, status: string, output?: string }], metadata: { total_latency_ms: number, avg_temperature: number } }
- Worker stats must return JSON: { task_id: string, workers: [{ id: string, status: string, latency_ms: number }], success_rate: number, avg_latency_ms: number }
CHAIN OF THOUGHT:
- Dispatch: analyze task → determine optimal worker count → assign temperature/focus variations → execute in parallel
- Execution: monitor worker progress → handle timeouts → collect results → track success/failure
- Aggregation: analyze worker outputs → select aggregation strategy → merge results → validate coherence
- Error handling: identify failed workers → retry if possible → exclude from aggregation → document failures
FEW-SHOT EXAMPLES:
Task: 'Summarize the key benefits of AI agents for businesses'
Workers: [
{ worker_id: 'w1', status: 'success', output: 'AI agents automate repetitive tasks...', temperature: 0.7 },
{ worker_id: 'w2', status: 'success', output: 'Businesses benefit from AI agents through...', temperature: 0.8 },
{ worker_id: 'w3', status: 'timeout', error: 'Worker exceeded 15s timeout' }
]
Aggregated: { strategy: 'merge', successful_workers: 2, aggregated_output: 'AI agents provide businesses with automation, cost reduction, and 24/7 availability...' }
EVALUATION CRITERIA:
- Worker reliability: percentage of workers that complete successfully within timeout
- Aggregation quality: coherence and completeness of merged output
- Performance: total processing time compared to sequential execution
- Error handling: percentage of partial failures handled gracefully
The system should: 1) Implement fan-out pattern where dispatcher sends input task to N parallel workers (configurable, default 3), 2) Each worker processes same input with different temperature settings or focus areas, 3) Workers run as independent async tasks, 4) Aggregator collects responses and uses LLM call to merge/summarize into coherent output, 5) Use Promise.allSettled for parallel execution, 6) Handle partial failures gracefully - if worker times out or errors, complete aggregation with remaining workers, 7) Implement minimum worker threshold: if fewer than half succeed, return error, 8) Handle all workers failing by returning clear failure message, 9) Support idempotent worker execution for retry scenarios, 10) Handle aggregator LLM failure by falling back to simple concatenation strategy.