Plan-and-Execute: Separating Planning from Execution
Plan-and-Execute is the architecture that refuses to invent every next step only after the last tool call. It first produces a multi-step plan for the goal, then walks that plan with an executor that may use tools, and only replans when reality diverges from the plan.
The payoff is fewer exploratory tool calls, clearer audit trails, and plans humans can review before expensive work starts.
Summary
- Split agent work into a planning phase that outputs ordered steps and an execution phase that carries those steps out, with optional bounded replanning.
- Insight: Complex goals waste money when a pure ReAct loop rediscovers the same structure every turn; an explicit plan reuses structure and makes progress measurable.
- Key Concepts: planner, executor, step, replan, verification, plan artifact.
- When to Use: Multi-step research, code changes with a known checklist, ops runbooks, report generation with a fixed outline, any task where partial progress should be visible as completed steps.
- Limitations/Trade-offs: A bad early plan steers the whole run; rigid plans break in highly uncertain environments unless replan policy is designed carefully.
- Related Topics: ReAct loops, hybrid architectures, stopping conditions, multi-agent orchestration.
Foundations
Planning is not unique to agents. Classical AI separated planning from acting for decades. LLM agents revive that split because models can draft decent plans in natural language or JSON, and tool-rich environments make unguided exploration expensive.
In Plan-and-Execute:
- The planner receives the user goal, constraints, and optional environment snapshot.
- It emits a plan artifact - usually an ordered list of steps with success criteria.
- The executor performs step 1 using tools or sub-calls, records results, then continues.
- A replan hook may rewrite remaining steps when a step fails checks or new information invalidates the plan.
Analogy: Plan-and-Execute is packing for a trip with a checklist (passport, tickets, chargers) rather than wandering the house deciding what to grab after each drawer you open. If the airport app shows a cancelled flight mid-checklist, you replan the transport step - you do not throw away the whole packing idea.
goal + constraints
|
[Planner] --> plan: [s1, s2, s3, ...]
|
[Executor] --s1--> result1
| --s2--> result2 (fail?) --> [Replanner] --> new plan
|
final synthesis / answerMechanics & Interactions
What a good plan contains
- Ordered steps that are each small enough to execute without a second hidden plan inside (or that explicitly spawn a nested loop).
- Dependencies ("step 3 needs the file path from step 1").
- Per-step success checks ("tests pass", "three sources cited", "ticket status is resolved").
- Explicit non-goals so the executor does not expand scope.
How execution differs from ReAct
The executor still may call tools, and a single step may even run a short ReAct sub-loop. The difference is authority: the high-level sequence is committed until a replan event, so the model is not free to invent a brand-new strategy on every observation.
When to replan
Common triggers:
- Step verification fails after retries.
- Tool returns "not found" for a resource the plan assumed exists.
- User updates the goal mid-run.
- Cost or time budget for the current plan is exhausted.
Always bound replan count. Unbounded replan is ReAct with extra ceremony.
Why this reduces wasted tool calls
On a ten-source research task, pure ReAct may issue redundant searches while rediscovering outline structure. A planner that says "cover A, B, C; for each: search, read, note claims" turns tool use into filling known slots.
Context management
Keep the full plan short and stable in context. Pass only the current step, recent results, and a compressed progress summary into the executor. Dumping every raw tool payload into the planner on each replan recreates context bloat.
plan = planner(goal) # structured list
for step in plan:
result = executor(step, tools)
if not verify(step, result):
plan = replan(goal, plan, result) # boundedAdvanced Considerations & Applications
Human-in-the-loop plans
Plan-and-Execute is the natural place for approval gates: show the plan before spending money on tools or before any irreversible action. That is harder to do cleanly in free-form ReAct because there is no single artifact to approve.
Planner vs executor model tiers
Many teams use a stronger (or slower) model for planning and a cheaper model for routine step execution. That only works if steps are well specified and verification is strict; weak executors amplify ambiguous plans.
Static plans vs LLM plans
Not every plan must come from a model. Product workflows can supply a fixed plan template (always: gather context, draft, lint, test, summarize) and only use the LLM inside steps. That hybrid often beats fully free-form planning for productized agents.
Failure modes unique to this pattern
- Optimistic plans that assume tools and data that do not exist.
- Over-granular plans (40 micro-steps) that cost more than ReAct.
- Under-granular plans ("solve the ticket") that push all hard work into one step.
- Replan thrash when verification is flaky.
| Approach | Strength | Weakness | Best fit |
|---|---|---|---|
| Pure Plan-and-Execute | Clear milestones, reviewable | Brittle without replan | Structured multi-step jobs |
| Plan + ReAct per step | Flexible inside structure | Nested complexity | Long jobs with messy tools |
| Fixed template plan | Deterministic product UX | Less adaptive | Repeatable business workflows |
Common Misconceptions
- "Planning means the agent never adapts." Bounded replan and per-step verification are part of serious Plan-and-Execute designs.
- "A longer plan is always better." Excess steps multiply failure points and tokens; aim for verifiable milestones.
- "The planner should also call every tool." Heavy tool use during planning often blurs phases; prefer a light environment snapshot, then execute.
- "Plan-and-Execute replaces stopping conditions." You still need max steps, replan caps, timeouts, and success contracts.
- "If ReAct works in the demo, planning is unnecessary." Demos hide cost curves that appear at multi-step production volume.
FAQs
What problem does Plan-and-Execute solve that ReAct struggles with?
It prevents rediscovering task structure on every turn, which cuts redundant tool calls and makes progress visible as completed steps with checks.
What should a plan artifact look like?
An ordered list of steps with enough detail to execute, optional dependencies, and a success check per step - JSON or numbered natural language both work if the host parses them reliably.
Who executes the steps - the same model or another component?
Either. Some systems use one model for both roles with different prompts; others use separate models or even non-LLM executors for deterministic steps.
How many times should an agent replan?
Set a small hard cap (often 1-3 for interactive agents). If replans keep firing, fix tools, verification, or the goal rather than raising the cap endlessly.
Can execution of a step still be ReAct?
Yes. Nested ReAct with a tight turn budget is a common way to handle messy tool work without abandoning the outer plan.
When is Plan-and-Execute the wrong default?
When the environment is so uncertain that any multi-step plan is guesswork - pure ReAct or a single-tool workflow may waste less on dead plans.
How do I verify a step without another expensive model call?
Prefer deterministic checks: tests passed, schema valid, HTTP 200, required fields present. Use a model judge only when the success criterion is inherently semantic.
Should users see the plan?
For high-cost or high-risk agents, yes - plans are the best approval surface. For low-risk chat helpers, an internal plan may be enough if logs capture it.
How does Plan-and-Execute interact with multi-agent systems?
The plan can assign steps to specialists ("research agent does steps 1-2, writer does step 3"), combining phased control with handoffs.
What is the difference between a plan and a prompt checklist?
A prompt checklist is static text. A plan artifact is runtime state the host advances, verifies, and may rewrite - it is part of control flow, not only instructions.
Why do plans sometimes make agents worse?
If the planner is wrong and replan is weak, the executor faithfully does the wrong work. Bad plans need better environment snapshots, constraints, and verification - not longer plans.
How should I log Plan-and-Execute runs?
Log the plan version, current step index, verification outcomes, replan reasons, and final stop condition. That sequence is your primary debug timeline.
Related
- The Three Core Agent Architecture Patterns, Compared - pattern map
- ReAct: Reasoning and Acting in an Interleaved Loop - interleaved alternative
- Multi-Agent Handoff: Specialist Agents Passing Work to Each Other - plans that assign specialists
- Hybrid Architectures: Combining Planning, Reaction, and Delegation - blending plan + ReAct
- When to Choose ReAct vs Plan-and-Execute vs Multi-Agent - selection guide
- Planning vs Reacting: Two Philosophies for Agent Decision-Making - philosophy-level contrast
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.