Plan, then execute
Plan, then execute is an agent design pattern where a model first creates an ordered task plan, then a separate loop carries out each step, observes results, and decides whether to continue, revise, or stop. It separates high-level decomposition from low-level tool use and response handling.
This pattern exists because a single prompt often mixes too many concerns: deciding the strategy, choosing tools, interpreting tool output, and remembering what has already been done. On multi-step tasks, that can lead to skipped work, repeated actions, or a model reacting locally without preserving the overall goal. A plan gives the agent a working map before it starts taking actions.
Concretely, the planner produces a short ordered list such as inspect logs, reproduce the issue, isolate the dependency, patch, test, and deploy. The executor then takes the next item, calls the relevant tool or model, records the observation, and checks whether the original plan still makes sense. If the result contradicts the plan, the loop can replan instead of blindly continuing.
The tradeoff is that planning is not magic. A poor plan can make the agent confidently pursue the wrong path, and an overly detailed plan can burn tokens, add latency, and become stale as soon as reality diverges. It helps when steps depend on previous results or tools may fail. It is usually wasteful for simple lookups, formatting tasks, or obvious single actions.
Engineers meet plan-then-execute when building agent graphs, workflow orchestrators, support bots, coding agents, research assistants, or tool-using systems that need more structure than a chat loop. In practice, the important design choices are the plan format, how much state the executor records, when observations trigger replanning, and what stopping condition prevents endless correction.
Common questions
- Does plan-then-execute make an agent more reliable?
- It can, but only when the task benefits from decomposition and feedback. The pattern improves visibility and gives the agent a chance to preserve progress, but it does not guarantee good reasoning. Reliability depends on plan quality, tool results, state management, replanning rules, and whether the task actually needs multiple dependent steps.
- How is this different from a normal agent loop?
- A normal loop often decides the next action directly from the current prompt and latest observation. Plan-then-execute adds an explicit planning phase before acting. The executor still loops over actions, but it is guided by a provisional roadmap and can compare each observation against that roadmap before continuing or replanning.
- When should I avoid plan-then-execute?
- Avoid it when the next action is obvious, the task is a single transformation, or the cost of extra model calls outweighs the benefit of structure. Common examples include simple retrieval, summarisation, classification, and direct tool calls. In those cases, planning often adds ceremony without improving the result.