Prompt Chaining vs Dynamic Decomposition: Choosing a Pattern

1.Fixed sequential pipelines: prompt chaining

Any complex workflow raises the same first question: do you already know the steps? When you do, the simplest structure is a fixed pipeline. Anthropic calls this prompt chaining. The task is broken into an ordered sequence, and each LLM call works on the output of the call before it. The code, not the model, decides what happens next, so every input takes the same path.

Anthropic's guidance says chaining is the right fit when the steps are known ahead of time and don't change from one input to the next. Its examples include writing marketing copy and then translating it, and writing an outline, checking it against criteria, and then writing the document from it. Between steps you can add programmatic checks, which Anthropic calls gates, to confirm the process is still on track before the next call runs.

Why split a task that one call could try all at once? Because each smaller call is easier to get right. The price is latency: the calls run one after another, so the chain takes longer than a single call. The Claude prompting guide adds an operational benefit. Because every step is its own request, you can inspect the intermediate output, score it, or send the flow down a different branch before going on. Its most common example is self-correction: draft, then review against criteria, then refine.

Code review is a natural fit for chaining, because the steps are the same for every change: analyze each file individually, then look at how the files fit together. Claude Code's workflow docs give this shape as an example prompt: review every file changed in a PR for correctness issues, then merge the per-file findings into one ranked summary. The audit-routes workflow script does the same thing in code. One agent lists every route file, a pipeline then runs a separate audit agent on each file, and the script collects the results. Each per-file pass is a local analysis. Nothing in it depends on any other file, so its prompt stays small and focused.

The reason to keep the per-file passes separate from the integration pass is attention. Anthropic's guidance on building agents says that for complex tasks with multiple considerations, models generally perform better when each consideration is handled by a separate LLM call, so attention stays on one aspect at a time. Claude's multi-agent guidance describes the failure mode of the alternative: a model that has to reason while holding thousands of tokens of irrelevant material in context suffers diluted attention and lower response quality. One review call over a large diff has exactly that problem. Splitting a large code review into per-file local analysis passes, then running a separate cross-file integration pass over the per-file findings, gives each call only what it needs. The integration pass reads compact summaries rather than raw files, the same way the support agent in Anthropic's example receives a short order summary instead of the full order history.

Sources1234

2.Dynamic decomposition: plans that grow from findings

Some tasks can't be planned upfront, because the right next step depends on what the last step found. Anthropic's orchestrator-workers pattern is built for this. A central model analyses the input, decides which subtasks are worth doing, hands them to worker models, and combines their results. The cookbook stresses that the subtasks are not fixed in advance. The orchestrator chooses them from the specific input.

Anthropic's multi-agent Research system shows why this matters for open-ended investigation. People doing research change their approach as they discover things, and the agent has to do the same, choosing which directions to follow based on what it has found so far. The lead agent writes down a plan, starts subagents on specific questions, reads what they return, and then decides whether more research is needed. If it is, it can start more subagents or change its strategy. The plan changes as the work goes on.

Adaptive decomposition also needs a way to stop. Claude Code's workflow examples include finding flaky tests by running the suite repeatedly and stopping once two rounds in a row find nothing new. Nobody knows at the start how many rounds that will take, because the stopping rule depends on what each round finds. Scoping matters too. Claude Code's best-practices guide warns that an unscoped instruction to "investigate" can lead Claude to read hundreds of files and fill its context. The fix it gives is to scope the investigation narrowly or to hand the exploration to subagents.

The same shape applies to open-ended coding tasks, not only to research. Anthropic's guidance notes that in coding, the number of files that need to change and the nature of the change in each one likely depend on the task, which is why it lists coding products that make complex changes across many files as an orchestrator-workers use case. Take the instruction "add comprehensive tests to a legacy codebase". Nobody can list the subtasks on day one. The workable decomposition follows the lead agent's process. First map the structure, the way the audit-routes workflow starts by asking an agent to list every file before any file is audited. Then identify the high-impact areas, the modules that matter most or are covered least. Then create a prioritized plan, as the LeadResearcher thinks through its approach and saves its plan before it starts any subagents. The plan is not final. When a worker discovers that a module can't be tested until a hidden dependency is stubbed, that finding creates new subtasks and the plan adapts, exactly as the lead agent reads what its subagents return and decides whether more work is needed. The cookbook describes this as two phases, analysis and planning followed by execution, with the orchestrator deciding at runtime what subtasks to create.

Sources56371

3.Matching the pattern to the workflow

The choice comes down to whether you can predict the steps. Anthropic's advice is to start with the simplest solution and add complexity only when it earns its place. Workflows give predictability and consistency on well-defined tasks. Agents fit when you need flexibility and decisions made by the model. The orchestrator-workers cookbook lists when not to use dynamic decomposition, and one case is when the subtasks are predictable and can be defined in advance.

This gives a simple test for exam scenarios. If every input always gets the same steps in the same order, a dynamic orchestrator has nothing to decide, and it only adds cost and variation. If you can't know at the start which areas are affected, which leads matter, or how many rounds are needed, a fixed chain can't encode the path, and you need a plan that changes as findings arrive. Dynamic setups can also go wrong in their own way. Anthropic reports that early versions of its research agents made errors such as starting 50 subagents for simple queries.

Two kinds of workflow come up again and again, and each has a default pattern. A predictable multi-aspect review has known aspects that are the same every time. Claude Code's best-practices guide shows one: review a rate limiter implementation for edge cases, race conditions, and consistency with existing middleware patterns. Reviewing each changed file and then merging the findings is another. Selecting prompt chaining here, or parallel sectioning where the aspects are independent, gives each aspect its own call, which Anthropic says is where models do better. An open-ended investigation is different. Researching a topic, or finding why a system misbehaves, has no known step list. Anthropic's research team notes that in open-ended problems it is very difficult to predict the required steps in advance, and that a linear, one-shot pipeline cannot handle them. Selecting dynamic decomposition here means a lead or orchestrating model decides the subtasks at runtime. Anthropic adds a cost check: multi-agent systems use about 15× more tokens than chats, so the task must be valuable enough to pay for that, and most coding tasks have fewer truly parallelizable pieces than research does.

Sources1567

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.An orchestrator that picks subtasks at runtime is always an upgrade over a fixed pipeline.Why is that wrong?

   When every input gets the same known steps, the runtime planner has no real decision to make and only adds cost, latency and unpredictability. Anthropic says to prefer the simpler fixed pattern here.

   Covered in Matching the pattern to the workflow

2. 2.An open-ended investigation can be fully planned upfront if the planner is careful enough.Why is that wrong?

   In open-ended work, what you find at each step decides where to look next. A fixed plan can't include steps that depend on findings nobody has made yet.

   Covered in Dynamic decomposition: plans that grow from findings

3. 3.Reviewing a large diff in a single call is better because the model can see every file at once.Why is that wrong?

   One call holding many files spreads attention across everything and dilutes it. Anthropic's guidance is that each consideration handled by its own call performs better, so per-file passes followed by a separate integration pass beat one big pass.

   Covered in Fixed sequential pipelines: prompt chaining