Task Decomposition

What it is

Dividing one unit of work into smaller units that can be assigned, executed, and verified on their own, together with the rule for putting their results back together. It answers what the pieces are, where their boundaries fall, and how they rejoin — not the order in which they run or who runs them.

Why it matters

Unit size decides almost everything downstream: whether a piece fits in a context window, whether a failure can be retried without discarding good work, whether two pieces can proceed at once, and how localised a mistake stays. It is the usual reason agent output arrives ninety percent correct and unusable — the defect sits inside a piece too large to fix without redoing it, or spans a boundary so that no single piece is wrong while the whole is.

Pieces are not a strategy

Dividing work produces a set and a rejoining rule; it says nothing about sequence. The same set of pieces can be executed in any order a dependency structure permits, or in none at all. Work that has been divided still needs something to decide what runs when, and a sequence over undivided work is a perfectly good strategy with nothing to divide. The two are usually performed by the same component, which is why they are so often conflated.

Key decisions

• Who divides: fixed code for a known shape, the model at runtime for an open-ended goal, or a human template for a recurring one.
• The stopping rule — what makes a piece small enough. Common criteria are fitting the context, producing one verifiable output, touching one tool, or costing under a threshold.
• Whether pieces are independent or share state, which determines whether they may run concurrently and whether their failures are isolated.
• How results rejoin: concatenation, a model-performed reduction, a structured merge, or a person.
• What happens when one piece fails — fail the parent, retry the piece, or re-divide because the boundaries were wrong.
• Whether the division is recorded durably so a retry resumes with the completed pieces rather than starting again.

Failure modes

• Boundaries are drawn where each piece lacks the context to be answerable; every result comes back hedged and the rejoining step invents the connective material.
• Pieces overlap, and two of them perform the same side effect — the record is created twice, the message is sent twice.
• The rejoining step receives a dozen outputs and a limited window, and summarises away exactly the specifics that justified dividing the work.
• Depth is unbounded, so a vague goal fans into hundreds of trivial pieces whose combined cost far exceeds doing the job in one pass.
• Boundaries follow document structure rather than meaning, splitting an argument across two pieces neither of which is correct alone.
• Dependencies between pieces are never declared, a scheduler runs them together, and the second one needed the first one's output.
• A failing piece is retried indefinitely because nothing considers that the division itself was the mistake.
• Pieces are sized for the model that existed when the code was written, and a context-window change leaves the division needlessly fine and expensive.

Related capabilities

• Planning Engine — orders and sequences the pieces produced here
• Parallel Execution — can only exploit pieces that are genuinely independent
• Shared State Management — where results land when they do not return inline
• Multi-agent Orchestration — distributes pieces across participants
• Termination Conditions — defines when enough pieces have succeeded

Applies: Production readiness · Design questions