Plan-and-Execute

Plan-and-Execute splits an agent into two roles that ReAct fuses into one. A planner, usually your most capable model, reads the task once and emits the entire plan as a numbered list of steps. An executor, which can be a much smaller model or no model at all, then works through the steps one by one, calling tools and collecting results. The expensive model is consulted once at the start, maybe once at the end to assemble the answer, and otherwise only when a step fails badly enough to invalidate the plan. The lineage runs from Plan-and-Solve prompting (Wang et al., 2023), which showed that "first devise a plan, then carry it out" beats plain step-by-step prompting on reasoning benchmarks, through ReWOO and LLMCompiler, to the planner/executor loops most agent frameworks ship today.

The planner/executor split#

The planner's output is a contract: a list of concrete steps, each naming a tool and its inputs, ideally with dependencies marked so independent steps can run in parallel. ReWOO made the contract precise with variable placeholders: step 3 can reference #E2, the as-yet-unknown output of step 2, so the entire plan is written before a single tool runs. The model reasons about the shape of the solution without waiting to see intermediate data.

The executor is deliberately dumb. It walks the list, substitutes variables, fires the tool calls, and stores results. When a step does need language work, summarize this page, extract these fields, a small cheap model handles it; the planner's intelligence is already encoded in the step description. ReWOO demonstrated the ceiling of this idea by distilling the planning behavior of a 175B model into a 7B model for specific task types. A final solver call then stitches the collected evidence into the answer.

Walk through a real task: "build a pricing comparison for our top four competitors." The planner emits: 1) pull the competitor list from the CRM, 2) fetch each competitor's pricing page, 3) normalize tiers and currencies, 4) draft the comparison table. Steps 2's four fetches share no dependencies, so the executor runs them concurrently. Total frontier-model calls: one to plan, one to write the final table. A ReAct agent doing the same job would make a frontier call before every fetch, eight to ten calls, each one re-reading the entire accumulated history.

The cost and latency math#

The economics are the reason this pattern exists. ReAct's cost grows quadratically in practice: every step appends an observation to the history, and every subsequent frontier call re-reads all of it. Plan-and-Execute caps frontier usage at roughly two calls regardless of step count. ReWOO measured a 5x token-efficiency gain on HotpotQA with a 4% accuracy improvement over ReAct, precisely because observations never pass through the reasoning model.

LLMCompiler pushed on latency by treating the plan as a dependency graph rather than a list: a planner streams out a DAG of tool calls, and a scheduler executes every node whose inputs are ready, in parallel. Against ReAct that delivered up to 3.7x lower latency, up to 6.7x lower cost, and around 9% better accuracy on benchmark suites, since fan-out steps like "fetch all four pricing pages" stop being serialized through a model that has nothing to decide between them. Anthropic and other providers now bake the same instinct into parallel tool use, and CodeAct agents get it by writing the fan-out as a loop in generated code.

There is a quieter benefit: the plan is a reviewable artifact. You can show it to a human for approval before anything runs, lint it against a tool allowlist, or estimate its cost up front. An interleaved agent gives you no such checkpoint; you find out what it intends to do by watching it do it.

When upfront planning wins, and when it loses#

Plan-and-Execute wins when the task's structure is knowable before you start. Long-horizon jobs with many mechanical steps (report generation, data pipelines, migration scripts), tasks with wide parallel fan-out, and regulated workflows where someone must sign off on the steps all favor planning. The further the task horizon stretches, the worse interleaving gets, because ReAct re-decides everything at every step and compounds its per-step error rate across the whole trajectory.

It loses when the environment talks back. Debugging is the canonical counterexample: you cannot plan "fix the bug" as five upfront steps because step two depends on what the stack trace in step one says. Exploratory research, browsing, and any task where most information arrives during execution will invalidate upfront plans faster than you can amortize the planning call. A stale plan executed faithfully is the characteristic failure mode: the executor keeps marching through steps whose premise died two steps ago, burning tool calls on a world that no longer exists. If you find your system replanning after nearly every step, you have rebuilt ReAct with extra machinery and should use the simpler loop honestly.

Replanning triggers and failure handling#

The replan branch is where production systems earn their keep, and the design question is what wakes the planner. Four triggers cover most systems. Hard step failure: a tool errors or returns empty after bounded retries, two or three attempts with backoff, handled entirely by the executor. Contradicted assumptions: a step succeeds but its output breaks a premise of a later step, for example the competitor list comes back with seven names, not four. Budget breach: the plan exceeds its token, cost, or wall-clock allowance. Plan exhaustion: all steps completed but a checker judges the goal unmet.

When a trigger fires, prefer the cheapest repair that works. Retry the step first. Then attempt a local patch: hand the planner the completed steps, the failure, and only the remaining plan, so it rewrites the tail instead of starting over; in the pricing example, one blocked fetch becomes a single inserted "search for cached pricing" step while steps 3 and 4 stand. Full replans are the last resort, and they should be capped, two or three per task is a common production limit, with escalation to a human after that. Uncapped replanning is how a cheap architecture quietly becomes an expensive one. The same triggers compose upward: in multi-agent orchestration, the planner role becomes an orchestrator delegating steps to specialist agents, and replanning becomes reassignment.

Practical takeaways#

Choose Plan-and-Execute when steps are knowable in advance, parallelizable, or subject to approval; choose ReAct when the next action genuinely depends on the last observation. Route the planning call to your best model and the step execution to small models and plain code, since that split is where the 5x-plus savings live. Mark step dependencies so independent work runs concurrently. Define replan triggers explicitly, repair locally before replanning globally, and cap replans so cost stays bounded. And watch the replan rate as a health metric: near zero means you could ship a fixed workflow, near every step means you wanted ReAct all along.