Planning
Having the agent write out the steps for a goal before acting, then executing and re-planning when a tool result contradicts the plan.
Planning means the AI agent writes a to-do list before it starts. For "move our 40 API endpoints to the new login system", the plan might be: list the endpoints, group them, change one group, run the tests, repeat.
A written plan keeps the agent on track over long tasks and lets a person check the approach before anything changes. A good agent also rewrites the plan when a step surprises it.
A packing list before a trip: it stops you forgetting things, and you still change it when the forecast turns.
Assuming a longer, more detailed upfront plan is better. A plan written before any facts are gathered goes stale at the first surprise; frequent cheap re-plans beat one elaborate plan.
Three shapes. Plan-then-execute: one call emits a step list, executors run each step (often on a cheaper model), and a re-planner fires only on failure — Plan-and-Solve prompting (Wang et al., 2023) is the zero-shot form. Interleaved: the The agent loop (ReAct) re-plans every turn (ReAct). Hierarchical: a planner hands sub-goals to workers (Orchestrator–worker pattern). Reasoning models plan implicitly inside their reasoning tokens, which shrinks the gain from a separate planning call but not the value of an inspectable plan.
An explicit plan is an artefact: it can be shown for Human in the loop approval, kept as a todo list the agent ticks off (coding agents such as Claude Code do this), and checkpointed for Durable execution & checkpointing. Failure modes are over-commitment (executing a stale plan) and planning before facts are known. The fix is cheap re-planning triggered by surprises — a failed test, an empty search, a schema mismatch — not a longer upfront plan.
For tasks over ~10 steps: one planning call that writes a numbered todo list into state; execute steps with the same or a cheaper model; re-plan on any failed check or empty result; show the plan for approval when the task writes to shared systems. Cap re-plans at 3 per run.
Code migration: "Move 40 endpoints from v1 to v2 auth." Plan: (1) list endpoints, (2) group by router — 6 groups, (3) migrate and test one group at a time, (4) run the full suite. After group 2, tests show a shared requireSession middleware breaks under v2. The agent re-plans: fix the middleware first, then the remaining 4 groups. Without the re-plan it would have patched the same bug 4 more times (≈ 30 extra turns, ≈ $2).
Recommend plan-then-execute when steps are mostly known and the plan is worth approving; interleaved planning when every result changes the next step. Say how you'd trigger re-planning: on a failed check, not on a timer.
The follow-up: "do reasoning models make planning obsolete?" — no; they make a separate planning call less necessary, but you still want a visible todo list for approval, progress and resume.
Numbers worth knowing
- Planning-call overhead
- 1 extra call, ~1–3k output tokensplan of 5–15 steps
- Re-plan budget
- ≤3 per runmore usually means the goal is underspecified
How to decide
| When | Do this |
|---|---|
| Task is long (10+ steps) and touches shared systems | Plan-then-execute with the plan shown for approval. |
| Each tool result changes what to do next | Interleaved planning inside the loop; no separate planner. |
| Sub-tasks are independent and parallelisable | Hierarchical: planner + workers. |
Cost maths
Plan-then-execute cost = plan call + Σ steps on executor model + re-plans. Example at $3 / $15 per M for the planner and $1 / $5 for an executor (illustrative, Oct 2026): plan 6k in / 1.5k out = $0.04; 12 steps × (10k in, 400 out) on the executor = $0.14; one re-plan = $0.04. Total ≈ $0.22 vs ≈ $0.47 running all 12 steps on the planner model.
Operating it
- More than 30% of runs re-plan at least twice
- Plans routinely exceed 20 steps
- Humans reject >15% of proposed plans
- Re-plans per run (alert when p95 > 3)
- Plan-approval rejection rate (alert > 15%)
- Steps completed vs planned at exit (alert on runs exiting with unfinished steps marked done)
When it goes wrong
A data-migration agent finished "successfully" but left 3 of 9 tables unmigrated.
Row-count reconciliation the next morning.
The plan was written from a stale schema listing; when step 4 found three new tables, the agent continued executing the original plan instead of re-planning.
Plan steps now carry preconditions; any precondition mismatch forces a re-plan, and the final step diffs actual vs planned tables.
Related terms
Sources
- Plan-and-Solve Prompting — Wang et al., 2023paper
- ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022paper
- Building effective agents — Anthropic (Schluntz & Zhang), 2024blog
Check yourself
Three questions. Every option is explained once you answer.