1. The planner receives the goal and any context, then generates an ordered list of steps (the plan), typically in structured form (JSON / list). 2. The executor picks the first unfinished step and carries it out — usually as a ReAct loop (thought → action → observation) with tool access. 3. The step result is appended to the running state (scratchpad). 4. (Re-planning variant) The planner judges whether the plan is still valid in light of the new observation — if not, it generates a new plan for the remaining task. 5. The loop continues until the plan is exhausted or the planner emits a completion signal. The final answer is synthesized from the collected observations.
Purely reactive agent loops such as ReAct tend to lose track of the long-term goal, multiply redundant tool calls, and burn tokens of the strong LLM on every single reasoning step. Plan-and-Execute introduces global context (an explicit plan) and lets a cheap executor model handle routine steps while the expensive planner is invoked sparingly.
A strong LLM that produces an ordered list of steps from the user goal. Typically runs once up front and optionally again during re-planning.
Official
An agent (usually a ReAct loop) that carries out one plan step with tool access. May run on a cheaper / smaller model than the planner.
Official
Optional component that evaluates the plan after each step and emits an updated list of remaining steps or a completion signal.
Official
Set of tools (search, calculator, APIs, code) available to the executor; the planner may be aware of this set when constructing the plan.
Official
Working memory accumulating the goal, plan, completed steps, and their observations; shared between planner and executor.
The planner generates steps the executor cannot perform (missing tool, wrong signature). Causes error loops and wasted tokens.
Rigid plan execution after contradictory observations leads to nonsensical final steps.
Re-planning after every step on a strong model dramatically increases cost — sometimes exceeding plain ReAct on a single model.
Very granular steps yield plans with hundreds of items (state explosion); very coarse steps yield steps the executor cannot perform atomically.
Yao et al. propose interleaving reasoning and actions — the direct conceptual predecessor in which planning and execution are fused into a single loop.
Yohei Nakajima releases a minimal agent with a separate task-creator and task-executor — the first popular open-source implementation of Plan-and-Execute.
Wang et al. formalize the split into planning and execution phases for zero-shot CoT, showing gains over "Let’s think step by step".
Harrison Chase introduces a reference implementation of the pattern in LangChain — LLM planner + ReAct executor + optional re-planner.
Xu et al. propose a variant where the planner generates the full plan as variables and tool execution and synthesis are separated — drastically reducing token usage.
Kim et al. extend Plan-and-Execute with a dependency graph between steps and parallel execution of independent tool calls.
Model used to generate the plan. Usually a strong reasoning model (e.g. GPT-4 / Claude Opus / o1).
Model executing single steps. Often cheaper / faster than the planner.
When to trigger re-planning: never / after every step / only on failure / on scope change.
Hard cap on plan steps / executor iterations; safeguard against loops.
Set of tools exposed to the executor; constrains what the planner can plan at all.
Two distinct stages (planning, execution) with different compute profiles — often run on different models.
The planner drives the flow by selecting subsequent steps and routing them to executor tools; in the re-planning variant it can reroute after an observation.
Plan steps are usually executed sequentially (step n+1 depends on the observation from step n). Variants such as LLMCompiler detect independent steps and execute them in parallel.
An orchestration pattern — runs on any infrastructure that hosts the chosen LLMs.
