Task Decomposition & Planning

Welcome to Section 4 — Planning, Reasoning & Reflection. You've given your agent hands (tools, L121–L126 — Tools → Hands-On: Web Search + DB + Calculator); now you give it a mind for strategy. This section is about how an agent thinks about what to do — and it starts with the very first move of any capable agent: turning a vague goal into a structured plan.

Ask a model to "write a competitor analysis of our three rivals" in one shot and you'll get something — but it'll be shallow, unverifiable, and prone to losing the thread. Ask it to decompose the goal first — research each rival, synthesize, then write — and everything changes: the work becomes checkable, parallelizable, and far more reliable.

Task decomposition is planning. Break a complex goal into smaller, ordered, checkable subtasks — then execute them.

In this lesson:

• What decomposition is, and the four reasons it makes agents dramatically better
• Plan representations — the list, the DAG, the hierarchy
• How the plan gets made — decomposition-first vs interleaved (Least-to-Most, Plan-and-Solve)
• The honest reality: can LLMs actually plan? — and the 2026 reasoning-model nuance

Scope: this is the decomposition foundation for the section. The Plan-and-Execute vs ReAct trade-off is its own lesson (L128 — Plan-and-Execute vs ReAct); Tree-of-Thought / search is L130 (Tree-of-Thought & Search-Based Reasoning); and re-planning & recovery (what to do when reality breaks the plan) is L131 (Replanning & Recovering From Failure). Here we focus on building a good plan in the first place.

Decomposition is splitting a goal that's too big to do in one step into a set of subtasks small enough to each be done — and checked — reliably. The output is a plan: an ordered (or partially-ordered) set of subgoals.

It's how humans tackle anything non-trivial. "Plan a wedding" isn't an action — it's book a venue, send invitations, arrange catering, …, each of which decomposes further. You never hold the whole thing in your head at once; you work the tree.

For an agent, a subtask is ideally:

• Concrete — a clear action or sub-goal, not a vague aspiration.
• Checkable — you can tell when it's done and whether it succeeded (a checkpoint).
• Right-sized — small enough to do reliably, big enough to be worth a step (more on this granularity sweet-spot below).
• Dependency-aware — it knows what it needs before it can start.

Decomposition is the bridge from a one-shot prompt to a multi-step agent. Everything else in this section — reasoning, reflection, re-planning — operates on the plan that decomposition produces.

Decomposition isn't bureaucracy — each reason maps to a concrete failure it prevents:

1. It tames long-horizon tasks. Asked to do a 15-step job in one prompt, a model loses the thread — it forgets earlier constraints, skips steps, drifts off-goal. A plan keeps the whole arc explicit so each step stays anchored.
2. It mitigates error compounding (L114). One monolithic step is all-or-nothing; if it goes wrong, the whole thing is wrong. Subtasks give you checkpoints — verify each output before building on it, so a small error is caught early instead of cascading.
3. It unlocks parallelism. Once you know which subtasks are independent, you can run them at the same time — exactly the orchestrator-worker pattern (L119) and parallel tool calls (L123). "Research three rivals" becomes three concurrent jobs, not three sequential ones.
4. It keeps the model focused. Each subtask is a smaller problem with a smaller context — less to get confused by, easier to get right. And a plan is inspectable: you (or another agent) can read it and catch a bad step before spending tokens executing it.

The throughline: a plan converts a single fragile leap into a sequence of small, verifiable, sometimes-parallel steps. That's the difference between a demo and an agent that survives a real, long task.

A plan isn't always a flat checklist. There are three shapes, and choosing the right one is most of the skill:

• Linear list — "do A, then B, then C." Simple and fine when every step truly depends on the last. But it hides parallelism and over-serializes independent work.
• DAG (dependency graph) — each subtask declares what it depends on. Independent subtasks (no shared dependency) run in parallel; dependent ones form a chain, and the longest chain is the critical path (L123). This is the representation that matters most — it's a list that knows its own structure.
• Hierarchical / subgoals — a subtask can itself be decomposed recursively ("plan the trip" → "book flights" → "compare prices" → …). Useful for deep tasks; you expand a subgoal only when you reach it.

Here's a plan as a structured object — the model decomposes the goal into subtasks with dependencies:

That one depends_on field is the whole upgrade from a list to a graph. And once you have the graph, execution is mechanical — run it layer by layer, parallelizing within each layer:

Granularity is the heart of decomposition, so feel it. Below, the same goal is decomposed three ways — flip between them:

• Too coarse — one mega-step. The model has to research, compare, and write in a single shot: no checkpoints, no parallelism, maximum drift.
• Too fine — a dozen trivial micro-steps. The overhead explodes and the goal gets lost in the mechanics; one tiny failure derails the chain.
• Just right — five meaningful subtasks as a DAG: three independent research tasks fan out in parallel, the synthesis is the join, the write is the finish. That's a good plan.

When does the decomposition happen? There are two broad strategies, and the trade-off between them is deep enough to get its own lesson next (L128: Plan-and-Execute vs ReAct) — here's the foundation:

• Decomposition-first (plan-then-execute). Decompose the whole goal into subtasks upfront, then execute the plan. You get an inspectable, parallelizable plan and a clear structure — but it's made before you've seen any results, so it can't react to surprises. (Techniques: Plan-and-Solve; ReWOO plans all tool calls upfront for efficiency.)
• Interleaved (decompose as you go). Start with a partial decomposition, do the first subtask, and add or revise subtasks as you learn from results. More adaptive, but you lose the global view and can wander. (ReAct, L111 — Building a ReAct Agent From Scratch, is the extreme of this — it decomposes one step at a time.)

A classic decomposition-first technique worth knowing by name: Least-to-Most prompting (Zhou et al., 2022) — break a hard problem into a sequence of easier subproblems, then solve them in order, each step using the answers from the previous ones. It's decomposition and sequencing in one move, and it reliably beats trying to one-shot the hard problem.

The practical answer is usually a hybrid: make a high-level plan first (so the goal stays anchored), then execute it adaptively, revising when results demand it. We'll dissect exactly that in L128 (Plan-and-Execute vs ReAct).

Here's the nuance a world-class engineer holds that a beginner misses: LLMs are surprisingly unreliable planners — and surprisingly useful ones, at the same time.

The skeptical, well-supported view comes from Subbarao Kambhampati's work ("LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks," ICML 2024): an autoregressive LLM, by itself, cannot guarantee a valid plan and cannot reliably self-verify one. It produces plausible-looking plans that may contain invalid steps, impossible orderings, or unmet preconditions — and it's often overconfident that they're correct. Recent frontier models are better, but classical long-horizon planning is still not something to trust blindly.

But the same work shows the constructive path — LLM-Modulo: use the LLM as a brilliant idea generator (it proposes candidate plans and decompositions fast and creatively) and pair it with an external verifier or critic (a sound planner, a validator, tests, or even another model) in a generate → check → revise loop. The LLM proposes; something trustworthy disposes.

Practical takeaway: don't trust a generated plan's validity just because it reads well. For anything high-stakes, verify it — check preconditions, run a feasibility pass, or have a critic review it — before you execute. (Verification and reflection are L129 — Self-Reflection & Self-Critique; this is why they matter.)

There's a second twist that changes when you should reach for explicit decomposition. Modern reasoning models do a great deal of planning implicitly. When a model with extended thinking spends its reasoning budget before answering, a lot of that hidden work is decomposition — it's breaking the problem down in its head (this is the planning side of L111 — Building a ReAct Agent From Scratch's ReAct and the test-time-compute idea from L120 — Evaluator-Optimizer).

So explicit, external decomposition is not always worth the engineering. Don't build a five-node plan-and-execute harness for a task the model can comfortably one-shot — you'll add latency and brittleness for nothing.

Reach for explicit decomposition when the task is:

• Long-horizon — many steps, where the model would otherwise lose the thread.
• Multi-tool / multi-agent — the plan coordinates external actions (L119, L126 — Hands-On: Web Search + DB + Calculator).
• Parallelizable — you want independent subtasks to run concurrently.
• Inspectable / auditable — you (or a human) need to see and approve the plan before it runs.

Lean on implicit planning when the task fits in the model's working reasoning — a single well-posed question, a self-contained transformation. The art is matching the amount of explicit planning to the task; the next lessons (L128–L131 — Replanning & Recovering From Failure) are all about getting that match right.

Reason through these, then use the lab to confirm:

1. Predict: in the lab, which decomposition exposes parallelism, and why can those subtasks run at the same time?
2. A teammate decomposes "build the feature" into 18 micro-steps (open file, add import, …). What two problems will that cause?
3. You decompose a goal into 5 subtasks. What's the single field that turns that list into a DAG, and what does it unlock?
4. Your agent confidently produces a clean 6-step plan — and step 3 has an impossible precondition. What does the research say about why, and what should you do before executing?
5. When should you not bother building an explicit plan, and what's doing the planning instead?

→ (1) Just right — the three research rival subtasks have no dependencies on each other (depends_on: []), so nothing forces an order; they fan out in parallel (orchestrator-worker, L119 — Orchestrator-Worker). (2) Over-decomposition: huge overhead (a round-trip per trivial step) and the goal gets lost in the mechanics — plus one tiny step failing derails the chain. (3) depends_on — declaring each subtask's dependencies turns a flat list into a DAG, which exposes what can parallelize (independent) vs what must wait (the critical path). (4) LLMs generate plausible plans but can't guarantee validity or self-verify (Kambhampati) — they're overconfident. Verify the plan first: check preconditions / run a feasibility pass / have a critic review it (LLM-Modulo). (5) When the task is small enough to one-shot — a reasoning model is already decomposing it implicitly during extended thinking, so an explicit harness just adds latency and brittleness.

• "Planning = thinking harder." Planning is structuring — turning a goal into ordered, checkable subtasks. A plan is an artifact you can inspect, not just more reasoning.
• "More steps = better decomposition." No — there's a granularity sweet-spot. Too coarse and the model flails; too fine and overhead explodes and the goal is lost. Aim for a handful of meaningful subtasks.
• "A plan is a list." The best plans are DAGs — the depends_on structure is what reveals parallelism and the critical path. A list hides both.
• "The LLM's plan is correct because it looks correct." LLMs generate plausible plans they can't self-verify (Kambhampati). Check validity before executing — generate and verify.
• "Always plan explicitly." Reasoning models plan implicitly during extended thinking. Reserve explicit decomposition for long-horizon, multi-tool, parallel, or inspectable work.
• "Decomposition is the same as ReAct." ReAct decomposes one step at a time (interleaved); explicit decomposition can plan the whole structure upfront. The trade-off is L128 (Plan-and-Execute vs ReAct).
• "Decompose once and follow the plan." A plan made upfront can meet surprises — adapting and re-planning is real and important (it's L131 — Replanning & Recovering From Failure). A rigid plan is its own failure mode.

• Decomposition is planning — the first move of a capable agent: break a goal into smaller, ordered, checkable subtasks before (or while) acting.
• Four payoffs: tames long-horizon tasks, mitigates error compounding (checkpoints), unlocks parallelism (independent subtasks → L119 — Orchestrator-Worker/L123 — Parallel & Sequential Tool Calls), and keeps the model focused with an inspectable plan.
• Representations: list (over-serializes), DAG (the depends_on graph — exposes parallel vs critical path), hierarchy (recursive subgoals). Prefer the DAG.
• Granularity is the game: too coarse → flailing; too fine → overhead & lost goal; just right = a handful of meaningful subtasks by dependency.
• Two timings: decomposition-first (plan-then-execute, inspectable) vs interleaved (adapt as you go); Least-to-Most decomposes into easier subproblems solved in order. The trade-off is L128 (Plan-and-Execute vs ReAct).
• Honest reality: LLMs generate plausible plans but can't guarantee validity or self-verify (Kambhampati / LLM-Modulo) — verify before executing. And modern reasoning models decompose implicitly, so reserve explicit plans for long-horizon / multi-tool / parallel / auditable work.
• Next — L128: Plan-and-Execute vs ReAct — the deep trade-off between planning it all upfront and figuring it out as you go.