Chapter 35Planning and Task Decomposition

Why Hard Goals Need Planning

Consider the goal "write a well-researched blog post about electric cars." No single tool call achieves it. It requires deciding what to cover, researching each part, organizing the findings, drafting, and revising — a sequence of distinct steps, some of which depend on the results of others. Complex goals like this overwhelm an agent that lurches from action to action with no structure. Planning gives the agent a way to manage that complexity: break the mountain into a staircase of manageable steps.

Task Decomposition: Breaking Down the Goal

The core skill is task decomposition: splitting a large goal into smaller subtasks that can each be tackled in turn. Helpfully, the model itself is good at this — you can simply ask it to break a goal into an ordered list of steps. This is often the agent's very first move on a complex task.

def make_plan(goal):
    prompt = (
        f"Break this goal into a short, ordered list of concrete subtasks: {goal}. "
        "Return one subtask per line, in the order they should be done."
    )
    return model_respond(prompt)

print(make_plan("Write a researched blog post about electric cars."))
# 1. Decide the key topics to cover.
# 2. Research each topic using search.
# 3. Organize the findings into an outline.
# 4. Write a draft from the outline.
# 5. Revise the draft for clarity.

Plan-Then-Execute

The most straightforward style is plan-then-execute: the agent makes a complete plan first, then carries out each step in order. Its strengths are structure and visibility — you can see the whole plan before anything runs, which is reassuring and easy to follow. Its weakness is rigidity: the plan is fixed at the start, so if reality differs from what the agent expected — a search comes back empty, a step reveals something surprising — the agent marches on with a plan that no longer fits. Plan-then-execute works best when the steps are predictable and unlikely to surprise you.

Plan-and-Adapt (Dynamic Planning)

The more flexible style is plan-and-adapt: the agent plans, but revises the plan as it learns. After each step it asks whether the plan still makes sense, and adjusts if not. You have already seen this idea — it is the spirit of ReAct (Chapter 32), where the agent reasons after every observation and changes course as needed. Plan-and-adapt handles messy, unpredictable goals far better than rigid planning, at the cost of being harder to predict and bound. The deep tension, which echoes through agent design, is between the structure of planning ahead and the responsiveness of adapting in the moment.

Decomposition in Code

A simple planning agent makes a plan, then executes each subtask in turn — ideally checking after each whether the plan should change.

def planning_agent(goal, tools):
    plan = make_plan(goal)            # decompose the goal into subtasks
    results = []
    for subtask in plan:
        result = run_agent(subtask, tools)   # the ReAct loop handles each subtask
        results.append(result)
        # plan-and-adapt: optionally revise 'plan' here based on what we learned
    return combine(results)

Notice the layering: the planner breaks the goal into subtasks, and each subtask is handed to the agent loop (Chapter 31) — often a ReAct loop (Chapter 32) — that solves it with tools. Planning sits above the agent loop, directing it.

When the Plan Meets Reality

Plans fail. A step does not work, a tool returns nothing useful, new information makes the original plan wrong. A capable agent must detect when a step has failed or the plan has gone off track, and respond — by retrying, choosing a different approach, or replanning from where it is. An agent that cannot notice its plan has broken will plow ahead uselessly. This is exactly why pure plan-then-execute is fragile and why adaptation matters: contact with reality is where rigid plans go to die.

Hierarchical Planning

For genuinely large goals, plans have plans inside them. Hierarchical planning decomposes a goal into high-level steps, and then decomposes each of those steps into smaller ones, recursively, until each piece is simple enough to do directly. "Write a report" becomes "research, then write," and "research" itself becomes "identify topics, search each, summarize." This mirrors how people tackle big projects — top-level milestones broken into tasks broken into actions — and it keeps each level of the plan manageable.

Planning + the Other Components

Planning is where the whole of Part VII comes together. It uses the model to decompose and reason about the goal, tools (Chapter 33) to execute each step, and memory (Chapter 34) to track progress and remember what has been done across a long task. A planning agent is the full architecture from Chapter 31 in motion: perceiving, reasoning, acting, observing — now organized around a structured goal rather than reacting step by step. Planning is the conductor that coordinates the other instruments.

Knowing When to Stop

As always (Chapter 31), bound the process. A planning agent can fall into over-planning — endlessly revising the plan without making progress — or into replanning loops that never converge. Set limits on steps and replans, detect when the goal is achieved, and recognize when the agent is stuck and should stop and report rather than spin. A plan is a means to finishing, not an end in itself.

Summary

Hard goals need planning because they cannot be done in a single step. Task decomposition breaks a goal into ordered subtasks, something the model itself can do. Plan-then-execute makes a full plan up front — structured and visible, but rigid when reality differs. Plan-and-adapt revises the plan as it learns, in the spirit of ReAct — flexible but harder to bound. Real agents must detect when plans fail and respond, and large goals call for hierarchical planning that decomposes recursively. Planning unites the model, tools, and memory of Part VII into a coordinated pursuit of a goal, and like every agent process it must be bounded to avoid rigid execution on one side and endless replanning on the other.

Planning, memory, and tools all repeatedly relied on one capability: retrieving relevant information. Chapter 36 — already part of your reading — covers retrieval-augmented generation in full, and Chapter 37 then builds the vector databases that make retrieval fast at scale, completing the core of agents.