Week 1-2

Chapter 2: Planning Patterns: Plan-and-Execute, ReWOO, HTN

When the ReAct loop wastes too many tokens re-planning every step, you need explicit planning patterns. This chapter covers Plan-and-Execute (plan once, execute many), ReWOO (decouple reasoning from observations to slash tool calls), Hierarchical Task Networks (compose plans from reusable pieces), evolutionary and Monte Carlo planning, and the rubric for when to plan vs. just react.

Chapter Overview

ReAct's strength is also its weakness: every iteration re-runs the planning process from scratch, paying for the full prompt + thought + action on every step. For tasks with many steps, this is expensive and slow. Planning patterns decouple the plan from the execution, so the model only does the hard reasoning once.

Three families dominate:

Plan-and-Execute (Wang et al., 2023) — a planner LLM emits a sequential plan up front, then a cheaper executor LLM (or even non-LLM code) carries out each step.
ReWOO (Xu et al., 2023) — decouple Reasoning from Observations entirely: the planner emits a DAG of steps with placeholder variables (#E1, #E2), all tools execute in a batch, and a final solver LLM combines results. Cuts tool calls dramatically.
Hierarchical Task Networks (HTN) — classical AI planning, adapted for LLMs. Compound tasks decompose into sub-tasks recursively until you reach primitive (executable) actions.

Plus two stochastic search techniques: evolutionary planning (mutate-and-select on candidate plans) and Monte Carlo Tree Search for plan exploration.

The big question this chapter answers: when should you plan up-front vs. plan-as-you-go? The answer depends on (a) how predictable the environment is, (b) how expensive failed steps are, and (c) how large your context budget is.

This chapter covers:

Plan-and-Execute fundamentals — the planner / executor split
ReWOO — DAG plans with placeholder variables, batched execution
Hierarchical Task Networks (HTN) — compound → primitive task decomposition
Evolutionary & Monte Carlo planning — when search beats greedy
When to plan vs. react — a decision rubric

Chapter Roadmap

Click any topic to jump in

Plan-and-Execute

Plan once, execute many — slash token cost on long, predictable trajectories.

The Planner / Executor SplitWhen the Plan Goes Stale

Two ways to express a static plan

DAGs (ReWOO) and trees (HTN)

ReWOO

DAG of placeholders, batched tool calls, single solver — constant token cost in the number of steps.

The Planner / Worker / Solver TriadWhen ReWOO Wins, When It Loses

HTN

Compound → primitive task decomposition — bounded depth, plan reuse, human-readable structure.

Compound vs Primitive TasksWhy HTN Is a Good Fit for LLM Agents

When the right plan is hard to find by greedy reasoning

Evolutionary & MCTS

When greedy planning misses the right plan — search the plan space when stakes are high.

Evolutionary PlanningMonte Carlo Tree Search (MCTS) for Plans

The full design space crystallizes into a rubric

Plan vs React Rubric

A 3-signal decision aid: predictability, cost of mistakes, latency budget.

Three SignalsThe Hybrid Default

Plan-and-Execute is the simplest planning pattern: one LLM call produces a complete sequential plan; a second loop executes the plan one step at a time. The planner does the expensive reasoning once; the executor is a thin wrapper that calls tools and feeds outputs back.

In this topic

1The Planner / Executor Split

2When the Plan Goes Stale

1 of 2

The Planner / Executor Split

$\text{plan} = \pi_\text{planner}(\text{goal}), \quad \text{plan} = [s_1, s_2, \ldots, s_n]$

The planner sees the user's goal and emits an ordered list of steps in natural language: "1. Look up the user's recent orders. 2. For each order, check the refund eligibility. 3. Refund the eligible ones. 4. Email the user a summary."

The executor then processes each step in order. For each step, it produces a structured tool call (or LLM completion), captures the output, and moves on. The executor does not re-plan unless a step fails — at which point it can either retry, ask the planner to re-plan from the failure point, or escalate to a human.

The big win: the executor's prompt at step $i$ is small (just the current step + the most recent observations), not the full ReAct trace. Token usage often drops by 5–10× compared to ReAct on long trajectories.

Example:

Compare token usage on a 10-step task between ReAct and Plan-and-Execute.

2 of 2

When the Plan Goes Stale

The Achilles' heel of Plan-and-Execute is the stale plan problem. The planner makes assumptions about what each step will return; if reality diverges, downstream steps become wrong.

Three mitigation strategies:

Trigger re-planning on failure. When a step throws an error or returns an unexpected result, kick back to the planner with the full failure context. The planner emits a revised plan from that point forward.
Adaptive batching. Don't commit to all $n$ steps up front. Plan the next $k$ steps, execute them, then re-plan. Tunes the plan/execute trade-off.
Conditional plans. Have the planner emit branching plans ("if step 2 returns more than 5 orders, do X; else Y"). Costs more planning tokens but reduces re-planning frequency.