1.6 Design task decomposition strategies for complex workflows

Key points

1. 1

   Prompt chaining breaks a task into a fixed sequence of focused LLM calls with programmatic checks between steps. It suits work whose steps are known in advance and repeat every time: a standard multi-aspect code review (security, style, tests), a classify-extract-validate-post extraction pipeline. Benefits: consistent depth, predictable cost, easy debugging and auditing.

2. 2

   Adaptive (dynamic) decomposition lets a coordinator generate the next subtasks from what the previous step discovered. It suits open-ended work whose shape is unknown up front: incident investigation, "add comprehensive tests to a legacy codebase", research on a broad topic.

3. 3

   Signals that a fixed pipeline is the wrong choice: steps run that are irrelevant to most inputs, real causes fall outside the predefined steps, and patching by adding one more fixed step keeps happening. Signals that an autonomous agent is the wrong choice: 95%+ of inputs follow the same path, cost has climbed, and auditors cannot reconstruct the sequence.

4. 4

   Hybrid is often best: run the predictable majority through a fixed chain with gates and route the genuinely open-ended minority (documents with attachments, unusual incidents) to an adaptive path or a human.

5. 5

   Attention dilution: one pass over many files (a 14- or 22-file PR) produces uneven depth, missed obvious bugs and contradictory verdicts on identical code. A bigger context window does not fix attention quality, and running the same pass three times and voting suppresses real findings.

6. 6

   The fix for large reviews is two levels of pass: per-file passes that see only their file plus a shared explicit rubric (local issues), then a separate integration pass that receives the per-file findings and cross-file signals (renamed symbols, changed signatures, data flow) to catch cross-file defects.

7. 7

   Consistency between per-file passes comes from the shared rubric and the integration pass, not from giving every pass the whole diff; widening each pass's context reintroduces dilution and scope creep.

8. 8

   For open-ended codebase tasks, decompose as: map structure (entry points, dependency graph, shared modules), identify high-impact and high-risk areas, build a prioritised plan, then revise the plan as dependencies are discovered (a shared utility with 60 dependents jumps to the front; an untestable global needs a refactor subtask first).

9. 9

   Adaptive decomposition needs two things: a coordinator that re-plans between steps and owns the plan, and subagent outputs structured to carry the leads (findings, open questions, suggested next queries). Peer-to-peer coordination between subagents produces ownerless loops.

10. 10

    Too-narrow decomposition is a coordinator failure, not a subagent failure: if "creative industries" is split into three visual-arts subtasks, every subagent can succeed and the report still misses music, writing and film. Check the coordinator's decomposition first when coverage is missing.

11. 11

    Brute-force parallelism (one subagent per file, every conceivable subtask up front) is not decomposition; it multiplies cost and removes the feedback that should prune and direct the work. Parallelise independent subtasks once the plan says they are worth doing.

12. 12

    Common distractors: "switch to a larger context model", "make developers submit smaller PRs", "ask the agent in the prompt to follow the order", and "add a fifth fixed step" all avoid changing the decomposition itself.

Read the source

• Anthropic — Building effective agents
• Anthropic — How we built our multi-agent research system
• Agent SDK — Subagents