Design task decomposition strategies for complex workflows

A complex workflow usually exceeds what a single model call can handle with uniform quality. There are two decomposition strategies, and picking the right one is the core skill this task tests.

Fixed sequential decomposition, also called prompt chaining, predefines the steps. Each step's output feeds the next, and the sequence is identical on every run. You use it when you already know, before execution starts, which aspects the work has to cover.

Dynamic (adaptive) decomposition generates the subtasks at runtime based on what earlier steps discover. The plan is not written in advance, it emerges. You use it when the shape of the work depends on what you find. The deciding question is simple: can you enumerate the subtasks up front? If yes, chain them. If the subtasks only become knowable after exploring, decompose adaptively.

In prompt chaining you split a task into a fixed pipeline of narrow, well-defined steps. Each call handles one subtask and passes structured output to the next. Because every step gets a clean, focused context, per-step accuracy rises and each stage is easy to test and debug in isolation.

The canonical pattern for code review is: analyze each changed file individually for local issues (a per-file pass), then run a separate cross-file integration pass that examines how the files interact. Splitting this way avoids attention dilution and prevents the contradictory verdicts you get when everything competes for attention in one prompt.

# Fixed pipeline: each step feeds the next
for f in changed_files:
    local[f] = review_file(f)          # per-file pass
integration = review_cross_file(local)  # cross-file pass
report = merge(local, integration)

Chaining suits any workload whose facets are known in advance: extract then validate then format, or review for correctness, then security, then style as distinct passes. The trade-off is added latency from sequential calls, which is acceptable given the reliability gain. Note that chaining is sequential and single-line; it is not the same as a coordinator fanning work out to parallel subagents.

When you cannot know the structure up front, the plan itself has to be produced at runtime. The agent explores first, generates subtasks from what it discovers, and adapts the plan as new dependencies surface.

The classic example is 'add comprehensive tests to a legacy codebase.' You cannot list the test files or priorities in advance. The right approach is to first map the codebase structure, then identify high-impact and high-risk areas (untested core modules, complex branching), then build a prioritized plan that reorders and expands itself as inter-module dependencies are discovered.

This is the orchestrator-workers pattern from Anthropic's agent guidance: a central step decomposes the problem based on the specific input rather than following a fixed script, delegates the discovered subtasks, and synthesizes the results. Adaptive decomposition is the right tool for investigations, migrations of unknown scope, and research where the questions to ask only emerge from earlier answers.

Cramming a large multi-part task into a single prompt causes attention dilution. The model spreads finite attention across everything, producing detailed feedback on some parts and superficial feedback on others, missing obvious issues, and even contradicting itself, for example flagging a pattern as a bug in one file while approving identical code in another file inside the same request.

This is closely tied to the 'lost in the middle' effect: content at the start and end of a long input is processed reliably, while material in the middle is under-weighted. The longer and more heterogeneous the input, the worse it gets.

Splitting the work into focused passes is the fix, not a bigger context window. A larger window lets more text fit but does not restore uniform attention across it, so dilution and contradictions persist. The per-file-plus-integration split gives each file a dedicated pass for consistent local analysis and reserves a separate pass for the genuinely cross-file concern, the data flow between modules.

Use a single decision heuristic: are the subtasks enumerable before execution? Predictable multi-aspect work (a PR touching a known set of files, a document pipeline with fixed stages) maps to prompt chaining. Open-ended work whose subtasks depend on discoveries (exploring a legacy system, investigating an incident, researching a broad topic) maps to dynamic decomposition.

The two are composable, and the strongest production shape usually combines them. Use adaptive decomposition (or plan mode in Claude Code) to explore and produce a concrete plan, then execute the resulting fixed steps as a chain. Investigation is dynamic, execution is chained.

Guard against both failure directions. Forcing a rigid pipeline onto exploratory work guarantees you miss whatever the fixed steps did not anticipate. Conversely, running an open-ended agent loop over work whose steps you already know adds cost and variance for no benefit. Match the pattern to the predictability of the task, not to habit.