Planning & Task Decomposition
An agent that picks each step as it goes adapts well and tends to wander. Planning has it lay out the steps first. Used well, planning cuts steps and mistakes; used on every task, it adds a slow, costly stage that simple tasks never needed.
Buildbot learns to make a checklist
Buildbot's coding agent handled one-file fixes well and fell apart on tasks like "add pagination to the API and update the tests." It would edit one file, lose track, forget the tests and declare victory. It completed 41% of multi-step tasks.
They added a planning step: before acting, the agent writes an ordered checklist (change the endpoint, add pagination logic, update tests, run the suite), works through it and replans when something doesn't go as expected. Multi-step completion rose to 68%, and the checklist made progress visible to both the agent and the team.
Two ways to control an agent
ReAct (reason and act) has the model write a short thought before each action: think, act, observe, repeat. Each step uses the latest information, which is good when the path depends on what you find. With no overall plan, though, it can wander or lose the thread on long tasks.
Plan-and-execute has the model write the whole plan first ("1. get X, 2. use X to work out Y, 3. format Z") and then carry it out. It's more direct and often uses fewer calls on multi-step tasks, because it isn't rethinking the whole strategy every turn. The risk is that a plan made before you know what you'll find can be wrong, and following a wrong plan closely fails badly.
The trade-off, measured
On 30 multi-step research tasks, the two patterns split cleanly. On structured tasks with known sub-steps, like comparing four products on price, rating and shipping, plan-and-execute averaged 5.1 steps against ReAct's 7.8. On discovery tasks, where step 2 depends on a surprise in step 1, fixed plans went stale: plan-and-execute succeeded 61% of the time and ReAct 84%. Neither wins everywhere. A good middle path is to plan first and replan whenever a result makes the plan wrong.
Add a planning step when the task has several connected sub-steps you can name in advance. Skip it for short tasks and very exploratory ones. On long tasks, let the agent replan; a plan is a starting guess.
Decomposition also keeps context small
Splitting a big task into named sub-tasks helps with more than ordering. Each sub-task can run with only the context it needs and pass forward a short result, instead of one long conversation carrying every intermediate output. That's the same fight against growing context that the next chapter covers from another angle.
Compare ReAct and plan-and-execute
Run the same structured task both ways and count model calls. On a task with known sub-steps, planning should finish in fewer calls. Give a one-line reason.
Starter code
TASK = "Compare 3 laptops on price, rating, and weight, then pick the best value."
# Mock world: 3 lookups exist; the "answer" needs all three then a decision.
DATA = {"A":{"price":900,"rating":4.4,"weight":1.3},
"B":{"price":1100,"rating":4.6,"weight":1.1},
"C":{"price":800,"rating":4.1,"weight":1.5}}
def react_steps():
# ReAct re-decides each turn: look up A, think, look up B, think, look up C,
# think, then decide -> ~7 model calls (one per thought+act, plus final).
return 7
def plan_steps():
# Plan-and-execute: 1 planning call enumerates "look up A,B,C then decide",
# then executes them without re-deciding strategy -> ~5 model calls.
return 5
# TODO: if USE_REAL_API, implement both for real with the Anthropic SDK:
# ReAct: loop with a "think then act" system prompt.
# Plan: first call returns a JSON list of steps; execute each.
# Then print the two counts and the ratio.
r, p = react_steps(), plan_steps()
print(f"react {r} steps, plan {p} steps (plan/react = {p/r:.2f})")
# => react 7 steps, plan 5 steps (plan/react = 0.71)
# Live version sketch (plan-and-execute):
# plan = client.messages.parse(model="claude-opus-4-8", max_tokens=400,
# messages=[{"role":"user","content":f"List the steps to: {TASK}"}],
# output_format=Plan).parsed_output # Plan: list[str]
# for step in plan.steps: execute(step) # no strategy re-derivation
You should see 7 steps for ReAct and 5 for plan-and-execute, about 0.71 as many. When the sub-steps are known in advance, planning removes the "what next?" decision on every turn and the rereading that comes with it. Don't conclude that you should always plan. Imagine laptop B being discontinued halfway through: the fixed plan would keep trying to price a product that's gone, while ReAct would change course.
To go further, add a check after each step: "Does the plan still hold?" Replan only on "no," and count how often that fires on a structured task compared with a discovery task.
For a "customer was charged twice" ticket (check the charges, refund one, note the account, reply), Ridgeline's agent writes a short plan and works through it. When a refund fails, it replans instead of going straight to the reply.
Read the original ReAct paper. It's short and readable, and it's cited in almost every agent discussion. Being able to compare ReAct with plan-and-execute, with the trade-off in a sentence, is a common interview expectation.
If an agent handles simple requests well and falls apart on longer ones, a planning step is often the fix, and it's cheap to try. Ask the team whether the agent writes a plan it can be checked against. A visible plan also makes failures easier for people to review.
Quiz · Chapter 4
- A task has clear, connected sub-steps you can name in advance. Which pattern likely uses fewer calls?
- On discovery tasks, ReAct succeeded 84% of the time and plan-and-execute 61%. Why?
- What does "plan, then adapt" mean?
- Apart from ordering, how does decomposition help with cost?
- What does adding a planning step to a one- or two-step task usually do?