Back to course overview
Module 2Planning & reasoning 12 min

Multi-step planning

Plan-then-execute vs. react-as-you-go: when upfront plans pay, when they mislead, and the plan-as-artifact pattern that gives you both.

Your v0 agent improvises step by step — fine for four-tool tickets, shakier as tasks grow. The planning question every agent design must answer: should the model map the route before moving, or navigate turn by turn? Both are legitimate; the failure is not choosing deliberately.

The two modes and their failure shapes

  • Reactive (what you built): decide each step from the latest state. Adapts instantly to surprises; risks wandering — re-fetching known facts, chasing tangents, forgetting the goal on long tasks. Its failures look like inefficiency.
  • Plan-then-execute: first produce a numbered plan, then work through it. Focused and auditable — you can review a plan before any action runs (a safety gate Module 5 will exploit). Risks rigidity: plans built on wrong assumptions get executed anyway. Its failures look like confident wrongness.
  • The deciding variable is information. When the task's shape is knowable upfront (a refund case follows a known arc), plan. When each step's result determines the next (debugging, investigation), react. Most real agents: plan the skeleton, react within steps.

The plan-as-artifact pattern

The production version makes the plan a visible, updatable object — not a thought, a thing:

the patterntext
1. Agent's first move: emit a plan as structured steps
   [{"step": 1, "action": "get ticket + order facts", "status": "pending"}, ...]
2. Each turn: execute against the CURRENT step, then update its status
   (done / blocked / obsolete) — the plan lives in the conversation.
3. Surprise? The agent revises the plan EXPLICITLY — new steps appended,
   dead steps marked obsolete with a reason — never silently abandons it.

Why: focus (the plan re-anchors every turn) + auditability (the trajectory
shows what was intended vs. what happened) + a natural approval point
(a human can approve the PLAN before any write tool fires).
  • Right-size the granularity. Plan steps are milestones ('determine refund eligibility'), not keystrokes ('call lookup_order with HL-1042'). Over-planned plans go stale by step two.
  • Cap revisions. A plan revised every turn is reactive mode with paperwork; more than ~2 revisions means the task wasn't plannable — let the agent say so and switch modes.
  • Plans are also cost control: a 5-step plan with a 10-turn budget catches runaway loops early — 'on turn 8, still on step 2' is a signal your Module 6 evals will learn to read.
Where you've seen this

Task lists in coding agents, 'research plans' in deep-research products, the checklist your own tools show while working — all plan-as-artifact. It's the single most transferable agent pattern in current practice.