Plan and Execute is a pattern that separates planning from execution. A planner agent decomposes a complex task into an ordered list of subtasks, and an executor agent carries them out one by one, with optional re-planning if intermediate results change the approach.
What problem does Plan and Execute solve?
Agents that decide what to do one step at a time can wander. The ReAct pattern works well for many tasks, but it has a structural weakness. Because the agent chooses its next action based only on what it has seen so far, it can explore unproductive paths, revisit the same information, or miss the most efficient route to a solution. Each step feels locally reasonable, but the overall trajectory can be inefficient.
Consider an agent asked to research a competitor landscape and produce a summary report. A purely reactive agent might search for one competitor, go deep on their pricing page, get distracted by a tangential product feature, search for another competitor, realize it forgot to check the first competitor's funding history, and backtrack. It eventually produces a result, but it made twice as many API calls as necessary and took three times as long.
The deeper issue is that reactive agents mix strategic thinking with tactical execution. The same agent is deciding both "what is the overall approach" and "what is the very next action." These are fundamentally different cognitive tasks. Combining them in a single loop means neither gets the attention it deserves.
How does Plan and Execute work?
Plan and Execute separates these two concerns into distinct phases with distinct roles. A planner agent looks at the full task and produces a structured plan, a sequence of steps that, when completed, will solve the problem. An executor agent then works through the plan one step at a time, focusing entirely on carrying out each step well.
The planner operates at a high level. It decomposes the task, identifies dependencies between steps, and produces something resembling a checklist or workflow. It does not execute anything. It thinks about what needs to happen and in what order.
The executor operates at a low level. It takes a single step from the plan, figures out how to accomplish it using available tools, and returns the result. It does not worry about the big picture. Its job is to do one thing well.
After each step completes, the system can optionally send the results back to the planner for review. The planner might revise the remaining steps based on what the executor discovered. Maybe the first research step revealed that one competitor was acquired last month, so the planner removes that competitor from the remaining analysis steps and adds the acquiring company instead. This replanning capability is what makes the pattern adaptive rather than rigid.
The separation has a practical benefit for token usage. The planner needs to see the full task description and the current state of progress, but it does not need to see the detailed execution traces. The executor needs the current step instructions and relevant tool outputs, but it does not need to carry the entire plan in its context. Each agent gets a focused context window with only the information it needs.
When should you use Plan and Execute?
This pattern fits best when the task has a clear structure that benefits from upfront decomposition.
Strong signals:
- The task involves multiple distinct phases that build on each other (research, then analysis, then writing)
- You can estimate the steps needed before starting execution
- The task is expensive in API calls, and wasted exploration hurts your budget
- You need a visible progress indicator, the plan itself serves as a progress bar
- The task benefits from human review of the plan before execution begins
Weaker signals where a simpler ReAct loop might be sufficient:
- The task is exploratory and the path to a solution is genuinely unpredictable
- The task is simple enough to complete in two or three steps
- The environment changes rapidly and plans become stale before they can be executed
What are the common pitfalls?
Rigid plans that do not adapt. If the planner creates a plan and the executor follows it blindly regardless of what it discovers, the system becomes brittle. A step might fail or return unexpected results that invalidate the rest of the plan. Without replanning, the executor wastes effort on steps that no longer make sense. Always include a feedback loop where execution results inform the planner.
Over-planning. Some tasks do not decompose neatly into sequential steps. Forcing a detailed plan on an inherently exploratory task adds overhead without benefit. The planner spends tokens producing a plan that will need heavy revision after almost every step. If you find yourself replanning more often than executing, the task might be better suited to a reactive approach.
Plan granularity mismatch. Plans that are too high-level give the executor insufficient guidance. Plans that are too detailed constrain the executor unnecessarily and bloat the planner's output. Finding the right level of granularity requires experimentation. A good rule of thumb is that each step should be accomplishable in one to three tool calls.
Planner hallucinating capabilities. The planner might include steps that assume tools or data sources the executor does not have access to. If the planner is not aware of the executor's actual capabilities, it will produce plans that cannot be executed. Share the tool inventory with the planner so it knows what is possible.
Cascading failures. When an early step fails, all downstream steps that depend on it will also fail. The system needs graceful handling of step failures, either retrying the failed step, revising the plan to work around the failure, or escalating to a human.
What are the trade-offs?
You gain structured progress, reduced wasted exploration, visible execution plans that can be reviewed before running, and cleaner separation of strategic and tactical reasoning.
You pay with the overhead of generating a plan (additional LLM call before any execution happens), the complexity of maintaining plan state and handling replanning, and the risk of rigidity if replanning is not implemented well.
Latency is front-loaded. The planning phase adds time before any visible work begins. For interactive applications, users might perceive the system as slow because nothing happens while the plan is being generated. Consider streaming the plan to the user as it is created.
Total token cost can be higher or lower than ReAct. If the plan is good and the executor follows it efficiently, you save tokens by avoiding wasted exploration. If the plan is poor and requires frequent revision, you spend extra tokens on both planning and replanning without saving on execution.
This pattern works best at the middle complexity range. Simple tasks do not need a plan. Extremely complex or novel tasks resist planning because the problem space is not understood well enough upfront. The sweet spot is tasks where you roughly know what needs to happen but the details require careful execution.
Goes Well With
Chain of Thought enhances the planner's ability to reason through task decomposition. By explicitly working through the problem structure before producing a plan, the planner creates better step sequences with fewer gaps and dependencies.
ReAct Loop serves as the execution engine within each step. While Plan and Execute handles the high-level structure, each individual step can use a ReAct loop to figure out the tactical details of how to accomplish it. This gives you strategic planning at the top level and flexible execution at the step level.
Multi-Agent Collaboration extends this pattern by assigning different plan steps to different specialist agents. The planner becomes a supervisor that delegates each step to the agent best suited for that type of work, combining the structure of planning with the expertise of specialized agents.
References
- Wang, L., et al. (2023). Plan-and-Solve Prompting. ACL 2023.
- Yao, S., et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS 2023.
Further Reading
- Wang et al., "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models" (2023) — Shows that explicitly decomposing problems into a plan before solving each step improves reasoning accuracy over standard chain-of-thought approaches. arXiv:2305.04091
