Workflow Composition Patterns & the Orchestrator-Workers Trap
AdvancedSelect among the augmented LLM, workflow, and agentic architectural patterns · Difficulty 4/5
Explanation
Most workflows are built by composing the augmented LLM using one or more of five recurring patterns.
The Five Composition Patterns
- Prompt chaining -- a fixed sequence of steps, each an LLM call on the previous output (with optional programmatic gate checks).
- Routing -- classify the input, then dispatch to a specialized prompt or model.
- Parallelization -- run subtasks concurrently (*sectioning*) or run one task several times and vote (*voting*).
- Orchestrator-workers -- a central LLM decides subtasks *at runtime* and delegates to workers (this is where a workflow shades into an agent).
- Evaluator-optimizer -- one LLM generates, another critiques and returns it for refinement.
Each pattern is still a workflow, not an agent, as long as the control flow itself is predefined in code -- even orchestrator-workers, where only the *content* of the subtasks (not the fact that delegation happens) is decided at runtime.
Common Exam Trap
> Trap: Confusing orchestrator-workers (subtasks decided dynamically at runtime) with parallelization sectioning (subtasks known in advance). The dividing line is *who decides the subtasks and when*.
In parallelization sectioning, the architect (or the code) already knows what the independent subtasks are before execution starts -- the workflow just runs them concurrently. In orchestrator-workers, a central LLM looks at the specific input and decides, at runtime, what the subtasks should be, then delegates. Both patterns involve delegating to multiple workers, which is exactly why they get confused on exam scenarios -- the test is whether the subtask boundaries were fixed in advance or discovered dynamically.
Matching Pattern to Task Shape
| Task shape | Pattern |
|---|---|
| Same fixed sequence every time | Prompt chaining |
| Input falls into distinguishable categories needing different handling | Routing |
| Independent subtasks known in advance | Parallelization (sectioning) |
| Same task run multiple times for confidence | Parallelization (voting) |
| Subtasks can't be enumerated until the input is inspected | Orchestrator-workers |
| Output quality benefits from a critique-and-refine cycle | Evaluator-optimizer |
Key Takeaways
- Five workflow composition patterns: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer
- Prompt chaining is a fixed sequence of LLM calls, each on the previous output, with optional gate checks
- Parallelization sectioning runs known-in-advance independent subtasks concurrently; voting repeats the same task and aggregates
- Orchestrator-workers has a central LLM decide subtasks at runtime -- this is where workflow shades into agent
- Exam trap: the line between orchestrator-workers and parallelization sectioning is who decides the subtasks, and when
Glossary Terms
A two-pass architecture where a generator produces output and a separate evaluator assesses it against explicit criteria. For true quality assurance, the evaluator must be a separate Claude instance with independent context — using the same instance creates confirmation bias.
A multi-agent architecture where a central coordinator manages specialized subagents using hub-and-spoke communication. The coordinator handles task decomposition, routing, and result aggregation. Subagents never communicate directly with each other, keeping the system auditable.
The process of breaking a complex task into smaller, independently executable subtasks that can be assigned to specialized subagents or processed sequentially. Good decomposition creates subtasks with clear boundaries, independent execution, and verifiable outputs.
A workflow composition pattern where a central LLM decides subtasks dynamically at runtime and delegates them to workers, in contrast to parallelization sectioning where the subtasks are already known in advance. It is still a workflow, not an agent, as long as the fact that delegation happens is fixed in code -- only the content of the subtasks is decided at runtime. This is the point where a workflow shades most closely into an agent, and the classic exam trap is confusing it with parallelization sectioning.
Related Concepts