Task Decomposition

Relation to "planning"

The two overlap heavily. By convention, task decomposition emphasises *how to cut* — dividing a big problem into sub-problems of the right granularity, with clear boundaries and explicit dependencies; planning also covers ordering those subtasks, allocating resources, and setting success criteria. Methods like Least-to-Most explicitly decompose first, then solve one by one.

What a good split looks like

• Each subtask can be independently verified as done.
• Dependencies between subtasks are explicit and acyclic.
• Granularity is moderate: too coarse and the subtask is still hard; too fine and coordination and re-assembly cost outweighs the benefit.

A bad split derails execution no matter how strong the model — errors accumulate along the dependency chain.

Common misconceptions

• Finer is not better; over-decomposition amplifies cumulative error and re-assembly cost.
• If the resulting subtasks cannot each be independently accepted, complexity has not really been reduced.

Related terms

Sources

1. Wei et al. — Chain-of-Thought Prompting (arXiv:2201.11903)
2. Zhou et al. — Least-to-Most Prompting (arXiv:2205.10625)