A code change touches an unknown number of files, and which files only becomes clear once you read the task. Which pattern fits?
Why B is the answer
Orchestrator-workers
Orchestrator-workers suits work where subtasks cannot be listed in advance. The orchestrator breaks the task down at run time and combines what the workers return.
In detail
- The subtasks are not known until the work starts.
- An orchestrator breaks the task down at run time, then combines the results.
- The orchestrator should review the combined result, not only collect it.
Use case
An illustrative scenario, not a real incident.
A rename touches an unknown number of files. The orchestrator reads the task, lists the files, gives each to a worker, and combines the changes.
See it in different ways
flowchart TD A["Orchestrator"] --> B["Worker: file 1"] A --> C["Worker: file 2"] A --> D["Worker: file N"] B --> E["Combine results"] C --> E D --> E
mindmap
root((Patterns))
Prompt chaining
Fixed steps
Routing
Classify first
Parallelization
Sectioning
Voting
Orchestrator workers
Subtasks found at run time
Evaluator optimizer
Feedback loopsequenceDiagram participant P0 as Orchestrator participant P1 as Worker P0->>P0: Read the task and list files P0->>P1: Change this file P1-->>P0: Change done P0->>P0: Combine the results
Key point: Use orchestrator-workers when subtasks are unknown in advance.
Why the other options are wrong
- A. Parallelization with fixed sections
- Fixed sections have the same problem as fixed steps.
- C. Prompt chaining with fixed steps
- Fixed steps need to be known in advance.
- D. Routing to one specialist prompt
- Routing chooses one path. It does not spread work across unknown files.