Plan-and-Execute: Separating Planning from Action
The auditable alternative to ReAct. Plan first in one expensive call, execute many cheap steps, re-plan only when reality disagrees with the plan.
An agent pattern in which one LLM call decomposes the user goal into an ordered plan of sub-tasks; a separate executor (often a smaller model or a ReAct loop) runs each sub-task; and an optional re-planning step revises the plan when execution reveals it was wrong.
Compared to ReAct, plan-and-execute makes fewer total LLM calls per task, produces an auditable plan before any action is taken, and is easier to checkpoint between steps. The trade-off is reduced adaptability: the plan is committed early, and revising it costs an additional planning call.
Contrast with ReAct
ReAct interleaves reasoning and acting one step at a time. The model decides the next action based on the most recent observation; there is no commitment to a multi-step plan. Plan-and-execute commits to the full plan up front; the executor runs each step in order. Each pattern is best at what the other is worst at.
When to use it
Plan-and-execute fits when the task has these properties: the plan is reasonably stable (the steps you would write down in advance match the steps you actually need), tool latency is high (each action is slow enough that the cost of a fast planning call disappears against execution time), and pre-commit auditability matters (a human can sanity-check the plan before any action is taken).
Cases that benefit empirically: data-pipeline construction, multi-stage code-generation tasks, structured research with a known outline, and any task that touches downstream systems where rollback is hard. The LangChain blog’s original post on planning agents is the cleanest accessible treatment, and AutoGen’s GroupChatManager pattern is a close cousin.
Re-planning
The most consequential design choice in a plan-and-execute system is what happens when an action returns surprising results. Three options recur in production architectures.
- Fail-fast. Abort the task and return the error. Right when the cost of a wrong outcome exceeds the value of completing the task.
- Local-patch. Modify the plan at the failure point: change the failing step, leave the rest of the plan intact. Right when the failure is local and the rest of the plan is sound.
- Full-replan. Discard the existing plan and start over with the new information. Right when the failure invalidates the plan’s premise.
Failure modes
Three failure patterns recur in plan-and-execute systems. Each maps to a specific mitigation.
- Plan hallucination. The planner emits a plan that cannot be executed: it references tools the agent does not have, or assumes external state that does not exist. Mitigation: validate the plan against the tool inventory before execution begins.
- Brittle sequencing. Step 2 assumes a specific output shape from step 1 that step 1 does not produce. Mitigation: typed state objects between steps, or a validation gate after each step.
- Over-specification. The plan is too rigid to adapt to even small environmental variations. Mitigation: encourage the planner to emit higher-level steps and let the executor decide the details.
Framework implementations
The pattern is supported across the major orchestration frameworks. Documentation links for reference only.
- LangGraph - graph-based; plan-and-execute is straightforward to model as a state graph with a planner node and an executor sub-graph. docs
- AutoGen - GroupChatManager with a designated planner agent. docs
- CrewAI - hierarchical process configuration explicitly designates a manager role. docs
- LlamaIndex Agent Workflows - workflow-style execution suits stable plans. docs
Frequently asked questions
When does plan-and-execute beat ReAct?
When the plan is reasonably stable, the tools have high latency, and pre-commit auditability matters. Plan-and-execute makes one expensive planning call up front and then cheap execution calls; ReAct makes a planning-style call before every action. For tasks like a 12-step data-pipeline build where each step is slow, the amortisation argument favours plan-and-execute.
What happens when the plan turns out to be wrong?
Three options: fail-fast (abort and return), local-patch (revise just the failing step and continue), or full-replan (start over with the new information). Production systems usually use local-patch for recoverable errors and full-replan for foundational ones. The decision logic is part of the orchestration layer.
Is plan-and-execute the same as the LangChain blog post?
The LangChain blog popularised the term and the implementation in 2023, but the pattern itself is older. Classical AI planning (STRIPS, hierarchical task networks) shares the decompose-then-act structure, and the BabyAGI and AutoGPT projects of early 2023 both demonstrated planner-executor architectures before the formal naming. The LangChain post is the most accessible modern treatment in the LLM context.
Does plan-and-execute use ReAct internally?
Often, yes. In a typical implementation, the planner emits an ordered list of sub-tasks; for each sub-task, an inner ReAct loop handles the actual tool selection and execution. The pattern is composable: plan-and-execute outside, ReAct inside.
- ReAct - the inner loop within each executor step
- Reflection - critique the plan or the result before continuing
- Multi-Agent - the planner can be its own specialist agent
- Orchestration tooling - frameworks that support plan-and-execute
Sources and Further Reading
- LangChain, Planning Agents blog post (2023).
- Q. Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, arXiv:2308.08155 (2023).
- L. Wang et al., A Survey on LLM-based Autonomous Agents, arXiv:2308.11432 (2023).
- S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 4th ed., Pearson, 2020. Ch. 11 on classical planning.
- Anthropic, Building effective agents (2024).