The Five Workflow Composition Patterns
CoreDecide between a workflow and an agent architecture · Difficulty 2/5
Explanation
The Five Patterns
| Pattern | Structure | Fits |
|---|---|---|
| Prompt chaining | A fixed sequence of steps, each an LLM call on the previous output, optionally with programmatic "gate" checks between steps | Tasks that decompose cleanly into known, ordered subtasks |
| Routing | Classify an input, then direct it to a specialized follow-up prompt or model | Inputs that fall into distinct categories needing different handling |
| Parallelization | Run subtasks concurrently: sectioning (split into independent parts, known in advance) or voting (run the same task multiple times and aggregate) | Independent subtasks, or tasks that benefit from redundancy/consensus |
| Orchestrator-workers | A central LLM dynamically breaks a task into subtasks at runtime and delegates to worker LLMs | Tasks whose subtask breakdown can't be fully known in advance -- this is where a workflow starts to shade into an agent |
| Evaluator-optimizer | One LLM generates, another critiques, and the result is sent back to improve | Tasks where a generate-then-critique loop measurably improves quality |
All five patterns are still workflows: the code path that wires the LLM calls together is fixed, even though the content of each call is generated dynamically. The exception that blurs the line is orchestrator-workers, where the subtask breakdown itself is decided at runtime by the LLM rather than fixed by the developer in advance.
Choosing Among Them
Match the pattern to the task's shape: a strictly ordered pipeline calls for chaining; distinct input categories call for routing; independent, parallelizable work calls for sectioning or voting; a task whose subtasks can't be enumerated ahead of time calls for orchestrator-workers; and a task with a clear quality bar that benefits from iteration calls for evaluator-optimizer.
Common exam traps
- Confusing orchestrator-workers (subtasks decided dynamically at runtime) with parallelization sectioning (subtasks known in advance and split up front). The dividing line is *who decides the subtasks and when* -- a developer at design time (sectioning) or the LLM at run time (orchestrator-workers).
- Treating any multi-step LLM pipeline as automatically "an agent" just because it has several stages -- prompt chaining, routing, and parallelization are all still workflows with a fixed code path.
Key Takeaways
- Prompt chaining = fixed sequence of LLM calls, optionally gated between steps
- Routing = classify then dispatch to a specialized prompt/model
- Parallelization = sectioning (independent parts known in advance) or voting (repeat and aggregate)
- Orchestrator-workers = a central LLM decides subtasks dynamically at runtime and delegates them -- the pattern closest to an agent
- Evaluator-optimizer = one LLM generates, another critiques, and the loop repeats to improve quality
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.
The practice of directing requests to different Claude model tiers based on assessed complexity and requirements. A common pattern uses a fast, cheap model (Haiku) to classify task complexity, then routes to Sonnet or Opus accordingly.
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.
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.
Related Concepts
Workflows vs. Agents: The Core Architectural Decision
A workflow orchestrates LLM calls through predefined code paths; an agent lets the LLM direct its own steps and tool use dynamically
Manager/Supervisor Agents and Subagent Delegation
A manager/supervisor agent coordinates subagents, each with its own context window, returning only condensed results