Planner-Executor Agent Architecture
Separate the agent into a planner that decomposes a goal into an ordered set of steps and an executor that carries each step out. Planning once up front (instead of one step at a time, as in ReAct) buys coherence on long-horizon tasks and cuts the number of expensive planning calls.
Where ReAct Agent Architecture decides the next action every turn, plan-and-execute commits to a multi-step plan first, then runs the steps. The planner is typically a larger/stronger model invoked rarely; the executor is a cheaper model (or a tool-runner) invoked per step. A replanner revises the remaining plan when a step's result invalidates assumptions. This split mirrors how a senior engineer writes a design before delegating tasks. Source: compiled from Wang et al., Plan-and-Solve, arXiv:2305.04091
Components
- Planner — turns the goal + context into a structured plan (list of steps, often with dependencies). Output is usually structured so the runtime can iterate it.
- Plan store — the current plan + per-step status (pending/running/done/failed). The durable state of the agent.
- Executor — runs each step, often itself a small ReAct loop or a single tool call.
- Replanner — given results so far, decides: continue, revise remaining steps, or finish.
- Aggregator — composes step outputs into the final answer.
Control flow
Tradeoffs vs ReAct
| ReAct | Planner-executor | |
|---|---|---|
| Planning calls | Every step | Once + replans |
| Coherence on long tasks | Drifts | Higher (global plan) |
| Adaptivity to surprises | High | Needs explicit replan |
| Cost control | Hard | Route strong→planner, cheap→executor |
| Best for | Short, exploratory | Long-horizon, decomposable |
Design implications
- Independent steps parallelize. A plan with a dependency graph lets the runtime fan steps out (a map-reduce over executors) within a bounded concurrency limit.
- Plans are checkpoints. Persisting the plan + step status is what makes the agent resumable; this is the bridge to Durable Agent Execution Architecture.
- Replanning is the failure-recovery seam. Without it, a single bad step dooms the run; with it, the agent self-heals.
- Model routing is the cost lever. Strong model for the rare planning call, cheap model for the many executions, keeps the budget sane.
Recursion turns the executor into another planner-executor for sub-goals, the shape Kevin captures in Recursive Agent Orchestration.
Architecture Position
| Axis | Value |
|---|---|
| Family | Agent runtime and control plane |
| Boundary owned | Agent split between planning, execution, verification, and replanning. |
| Read with | ReAct Agent Architecture, Reflection and Self-Critique Agent Architecture, Durable Agent Execution Architecture |
| Use this page when | separating strategic planning from tool execution |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Agent runtime and control plane family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Agent split between planning, execution, verification, and replanning. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured the planner/executor/replanner split, control-flow diagram, the comparison table against ReAct, and implications for parallelism, checkpointing, recovery, and model routing. Source: compiled from Wang et al., Plan-and-Solve, arXiv:2305.04091