Planning › Task Decomposition

The foundation of planning is decomposition: breaking a complex goal into simpler subgoals that are individually tractable. This is where most planning agents begin, and it is the step that most strongly determines whether the plan will succeed. A bad decomposition cannot be rescued by a good executor; it produces failures that look like execution problems but originate in planning.

Decomposition makes individual steps easier and makes the structure of the problem explicit. An agent that has decomposed "write a research report on climate change" into "gather sources", "extract key findings", "organize by theme", and "write the report" has a shared vocabulary for discussing what needs to happen, a framework for monitoring progress, and a natural scaffold for recovery if any piece goes wrong. Without decomposition, failure is monolithic: either the whole task succeeds or it fails. With decomposition, failure is local: one subtask fails, and the rest of the structure remains intact.

Goals naturally form hierarchies. "Write a research report on climate change" decomposes into "gather sources", "extract key findings", "organize findings by theme", and "write the report". Each of these decomposes further: "gather sources" breaks into "search academic databases", "search news archives", and "identify expert opinions". At the bottom of the hierarchy are leaf tasks that correspond to concrete actions: run a search query, fetch a URL, extract text from a document.

Hierarchical decomposition has a critical property: the planner can reason at the appropriate level of abstraction for each decision. High-level sequencing decisions, such as what major phases to tackle first, do not need to know the details of low-level implementation. Low-level execution does not need to be aware of the strategic reasoning that led to the current subtask. This separation of concerns makes planning tractable. When you are writing the "gather sources" phase, you do not need to think about how you will format the final report. When you are formatting the final report, you do not need to remember exactly how you ran each database query.

In practice, LLM planners implement hierarchical decomposition through prompting. The model is asked to break the goal into top-level steps, and then each step is recursively expanded as needed. The depth of decomposition is controlled by whether a subtask is "atomic", meaning directly executable as a tool call, or "composite", meaning it still requires further breakdown. Atomic tasks are the leaves of the tree. Composite tasks are internal nodes that the planner must continue breaking down before they can be executed.

The key challenge in hierarchical decomposition is knowing when to stop. Decomposing too deeply produces a plan with hundreds of trivially small steps that creates coordination overhead without benefit. Decomposing too shallowly produces vague instructions that the executor cannot act on directly. A search step that says "search for relevant sources" is too vague; a search step that says "search Google Scholar for papers on climate feedback loops published after 2020" is appropriately specific. Calibrating this granularity requires the planner to have some knowledge of the executor's capabilities, which in practice means knowing what tools are available and what each tool can reliably do.

Not all subtasks need to be completed in order. Understanding which tasks are independent enables parallelism that dramatically reduces wall-clock time on multi-agent systems, and also simplifies reasoning about the structure of the plan.

Sequential dependency occurs when the output of one task is the input to another. Searching for relevant documents must precede summarizing those documents. The search results are a required input to the summarization step. No amount of parallel execution can change this: you cannot summarize a document before you have it.

Independent tasks, by contrast, can be run in any order or simultaneously. Searching three different databases for background on a topic does not require the first search to complete before the second begins. The databases are separate systems with no shared state, and the results of one search are not inputs to the others. A parallelized planner can dispatch all three searches at once and wait for all results before proceeding, potentially completing three steps in the time it would take a sequential planner to complete one.

Identifying independence correctly is non-trivial for LLMs, and errors in either direction are costly. A planner that wrongly treats a sequential dependency as parallel will attempt to use outputs before they exist, generating errors or hallucinations. A planner that wrongly treats parallel tasks as sequential wastes time by running them one after another. In practice, LLMs tend to be conservative, defaulting to sequential orderings even when parallelism would be safe. Explicit prompting to reason about data dependencies before assigning step orderings significantly improves the quality of parallelism detection.

Parallelism is useful only in multi-agent or multi-threaded execution environments. A single-threaded planning agent running one step at a time gains nothing from identifying parallel steps during execution, though it can be confident it is not missing a dependency constraint when it runs them sequentially. In systems with multiple worker agents or parallel tool execution, correctly identifying independent steps translates directly into shorter task completion times. For long research tasks with many independent information-gathering steps, the wall-clock time reduction from parallelism can be substantial.

The strategies available for task decomposition range from purely instructive (tell the model how to decompose) to structurally guided (ask the model to reason about dependencies explicitly). The right strategy depends on the complexity of the task and the quality of the model's knowledge about the domain. For familiar, well-structured domains, simple chain-of-thought decomposition usually suffices. For novel or loosely specified tasks, more structured approaches improve reliability by forcing the model to reason about what it does not yet know before committing to a path.

Several prompting-based decomposition strategies have emerged in practice:

Chain-of-thought decomposition instructs the model to think step-by-step before acting. The model writes out a sequence of steps, and this sequence becomes the plan. This is the simplest approach and works well for relatively straightforward tasks where the subtasks are obvious from the goal description. Its weakness is that it does not force the model to reason about dependencies or parallelism; steps are listed in the order the model thinks of them, which may not be the most efficient execution order.

Least-to-most prompting decomposes by asking the model first what the easiest sub-problem to solve is, solving it, then asking what the next easiest problem is given the previous solution. This builds up a plan from the bottom, which is particularly useful when earlier steps reveal knowledge that changes how later steps should be formulated. The technique was introduced specifically to address compositional reasoning tasks where simpler components must be understood before more complex ones can be tackled.

Divide-and-conquer decomposition splits the problem into roughly equal halves, solves each independently, and combines the results. This pattern appears naturally in tasks like comparing two large documents (compare the first halves, compare the second halves, then synthesize) or processing long inputs that exceed the context window. It is especially useful when the goal has natural symmetry or when partial results can be combined without requiring a single global pass over all information.

Goal decomposition prompting explicitly asks the model to list the preconditions of the goal, what must be true before the goal can be achieved, then identify what actions establish those preconditions, and recurse. This maps closely to backward-chaining search in classical planning and is effective for tasks with clear prerequisite structures. A goal like "publish a blog post" has preconditions including "have a written draft" and "have an approved title", each of which has its own preconditions, making backward-chaining a natural decomposition strategy.

Plan-sketch refinement asks the model to produce a rough outline first, then refine each outline item into an executable step. This two-pass approach trades one additional LLM call for substantially more coherent plans, because the first pass establishes the global structure and the second pass fills in details that are consistent with that structure. The risk of local incoherence, where individual steps are fine but do not fit together as a whole, is significantly lower with this approach.

Beyond the specific strategy used, a good decomposition shares several characteristics that distinguish high-quality plans from poor ones. Understanding these properties helps both in evaluating model-generated plans and in designing prompts that elicit better decompositions.

A good decomposition is complete: every step needed to achieve the goal is present, with no implicit assumptions that would require the executor to figure out something the plan did not specify. Incompleteness is a common failure mode, particularly for steps near the end of a plan where the model implicitly assumes that earlier steps have generated everything needed.

A good decomposition is non-redundant: no step repeats work done by an earlier step. Redundancy often appears when a plan is generated without careful attention to what information each step produces. If step two already retrieves the text of a source document, step five should not retrieve it again just to check a different fact.

A good decomposition has well-specified interfaces: each step's output is defined clearly enough that the next step can use it without guessing. "Search for information about X" has an unclear output interface. "Search for information about X and return the three most relevant passages" has a clear one. Well-specified interfaces are especially important at the boundaries between parallel branches that must be combined into a synthesis step.

A good decomposition is appropriately granular: steps are neither so large that they require the executor to make sub-decisions that should be in the plan, nor so small that the coordination overhead dominates the work. Calibrating granularity requires the planner to have a model of executor capability, which in practice means knowing what tools are available and what each tool does reliably.