Docs / Patterns / Planning

Patterns

Planning

Have the agent break a goal into steps before it acts, work the plan, and revise it as it learns — so a multi-step task doesn't wander or lose the thread.

Updated Jun 26, 2026

The plain tool-use loop decides one step at a time: look at the state, pick the next action, repeat. That is enough for short tasks, but on a long one it tends to wander — the agent fixes the thing in front of it and loses the overall thread. Planning is the fix: before acting, the agent breaks the goal into steps, then works that plan rather than improvising each move.

For example, “migrate this codebase to a new API” is not one action. Without a plan, the agent updates one file, then another, and gradually loses track of which files are done and what the migration even required. With a plan, it first enumerates the files and the steps, then works through them, so the scope stays visible and nothing is silently skipped.

Forms it takes

  • Plan, then execute. Produce the whole plan up front, then carry it out. Clearest when the steps are knowable in advance.
  • Interleaved planning. Plan a little, act, then revise the plan with what you just learned. Better when the task reveals itself as you go (i.e., you cannot see all the steps from the start).
  • Decomposition into subgoals. Split the goal into pieces small enough to hand off — often to worker agents, which is where this meets multi-agent orchestration .

A practical trick ties these together: write the plan down as a checklist the agent keeps and updates. That artifact externalizes “what is left” out of the conversation, so it survives even when the agent’s context fills up — a plan is, in part, memory you can see.

Where it helps, and where it does not

  1. A plan made up front goes stale. The agent learns things mid-task that change what the right plan is, so let it replan rather than march a now-wrong plan to the end. A plan it cannot revise is worse than no plan.
  2. Planning has a cost. For a one- or two-step task it is pure overhead; reach for it when the goal is genuinely multi-step.
  3. A plan is not correctness. A confident plan can be confidently wrong, so for a big task review the plan before the agent runs it — not just the result afterward.

Approve the plan, not just the output

For anything large or hard to undo, have the agent show its plan first and approve it before it acts. Fixing a wrong plan costs a sentence; undoing a wrong execution costs much more.

Where to go next

Source: content/patterns/planning.md · maintained in the nuilab-agenticai repository.