Task Decomposition Strategies.

Task decomposition is the architectural step of breaking a complex request into ordered, delegable subtasks before an agent (or a chain of prompts) starts executing - the analysis happens up front, not as an emergent side effect of one giant prompt. Anthropic frames this as a choice along a spectrum: some tasks decompose cleanly into a fixed set known in advance (a workflow), while others require a dynamic decomposition that only an LLM orchestrator can determine at runtime, because the right subtasks depend on what earlier steps discover. The architect's job is picking which regime a given problem falls into, then applying the matching pattern, not defaulting to the more complex one.

In fixed decomposition, subtasks are pre-defined - but predictability and execution order are two separate questions. Predictable subtasks most often run as prompt chaining (a sequential workflow that trades a bit of latency for higher accuracy on each step, since each stage gets a focused prompt instead of one that has to do everything); the same predictability can just as validly run as parallelization/sectioning, where the pre-defined subtasks execute independently and simultaneously rather than one after another. "Fixed" describes whether the subtask list is knowable in advance, not whether it runs sequentially - that coupling is a common oversimplification. In dynamic decomposition (the orchestrator-workers pattern), a central LLM analyzes the unique task and determines the best subtasks to delegate to specialized worker LLMs at runtime - the subtask list is not known ahead of time, which is what separates it from parallelization or sectioning, where subtasks are pre-defined.

Start by classifying the regime. If a task can be easily and cleanly decomposed into fixed subtasks, hardcode it as a sequential prompt chain - it is cheaper, more predictable, and easier to debug than a dynamic system. Only escalate to orchestrator-workers when the subtasks genuinely cannot be enumerated in advance.

Dynamic decomposition puts the planning inside the loop. A lead LLM reads the query, decides which angles matter, and spins up parallel subagents, each with its own tools and an independent exploration trajectory, which minimizes overlap and path dependency between workers. Anthropic's production multi-agent Research system runs exactly this: the lead agent plans from the user query, decomposes it into parallel subagent tasks, and updates the decomposition based on intermediate findings rather than committing to a static plan.

Granularity is a real tradeoff, not a free dial. Coarser subtasks cut coordination overhead but risk one agent doing too much to verify cleanly; finer subtasks improve parallelism and auditability but raise the context-handoff cost between agents. Anthropic's guidance to start with the simplest workflow and escalate only when needed implicitly encodes this tradeoff - default to the coarsest split that stays independently verifiable.

Decomposition scales to long-running, human-off-the-loop work too. Anthropic's C-compiler experiment split one large goal (a Linux-capable C compiler) across 16 parallel Claude agents over roughly 2,000 sessions - at that scale, the harness has to structure the decomposition so agents can make progress in parallel without stepping on each other's work, not just split the task once and walk away.

A softer framing worth holding loosely. Decomposition is sometimes described as splitting by meaning or intent (semantic decomposition) rather than by string or token boundaries (lexical splitting). That framing captures the underlying orchestrator-workers idea well, but the exact phrase is not independently verified against a single citable Anthropic source, so treat it as a mental model rather than a quoted principle.

Decomposition also works as a single-prompt technique, not just a multi-call architecture (CCAOF-D1-O2). Everything above assumes decomposition happens across separate calls or agents - fixed prompt chaining or dynamic orchestrator-workers. At the prompting level, an architect or associate can ask Claude, inside one turn, to explicitly break a complex request into an ordered list of subtasks before acting on them - a numbered plan, or steps enumerated in XML tags - the same instinct as chain-of-thought prompting, applied to structuring the request itself rather than to reasoning about a single answer. This needs no orchestration infrastructure at all: it is a prompt-engineering move (structure the ask so Claude decomposes it explicitly) that sits underneath, and is compatible with, the fixed-vs-dynamic architectural choice - a single well-decomposed prompt can still be one step in a fixed chain, or one call inside a dynamic worker.