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.