Plan-and-Execute

A plan-and-execute agent writes its whole plan before it acts. A planner, usually the most capable model you have, reads the task once and returns a numbered list of steps, each naming a tool and its inputs. An executor, which can be a small model or ordinary code, then works through the list and stores each result. The planner is called again only to assemble the answer, or when a step goes wrong badly enough to make the rest of the plan false. The ReAct pattern does the opposite and decides one step at a time, so the choice between them is the first architecture decision on most agent builds.

What the planner hands the executor#

The plan is a contract. Each step names a tool and its arguments, and dependencies are marked so that steps with nothing in common can run at the same time. ReWOO made the contract precise with placeholders: step 3 can refer to #E2, the output step 2 has not produced yet, so the whole plan exists before any tool runs.

Keep the executor the dull half of the system. It walks the list, fills in the placeholders, makes the tool calls and keeps the results. Where a step needs language work, such as summarising a page or pulling fields out of it, a small model does it, because the planner already wrote down what the step is for. ReWOO pushed this far enough to move the planning behaviour of the 175B GPT-3.5 into a 7B LLaMA for specific task types.

Take "build a pricing comparison for our top four competitors". The planner returns four steps: pull the competitor list from the CRM, fetch each pricing page, normalise tiers and currencies, draft the table. The four fetches in step 2 depend on nothing but step 1, so they run together. The capable model is called twice, once to plan and once to write the table. A ReAct agent on the same job makes a model call before every fetch, and each of those calls reads the whole history again.

Why the bill and the clock both drop#

In an interleaved loop every step appends an observation, and every later call reads all of them. Total input therefore grows with the square of the step count, while plan-and-execute keeps the expensive model near two calls however long the list gets. ReWOO measured 5x token efficiency and a 4 percent accuracy gain over ReAct on HotpotQA, a benchmark of questions that need two or more lookups, because observations never pass back through the reasoning model.

LLMCompiler treated the plan as a dependency graph rather than a list. The planner streams out a graph of tool calls, and a scheduler runs every node whose inputs are ready. Against ReAct it reported up to 3.7x lower latency, up to 6.7x lower cost and up to about 9 percent better accuracy. Fan-out steps stop queueing behind a model that has nothing to decide between them. Parallel tool calls in the provider APIs and loops written by CodeAct agents get the same effect by other routes.

The plan is also something a person can read before anything happens. You can show it for approval, check it against a tool allowlist, or price it before it runs. An interleaved agent shows its intent only by taking the next action.

On the DevOps agent we run against live AWS, a request becomes a structured spec and an explicit chain of tool calls, and an engineer approves an architecture diagram of the result before anything is applied. Engineers who had refused to let an agent near production came to let it own routine cloud changes, and the credit goes to the review surface rather than the model.

When the plan goes stale#

Plan first when the structure of the task is knowable before you start: report generation, data pipelines, migrations, wide fan-out, and regulated work where someone signs off on the steps. Interleave when the environment answers back. Debugging is the standard counterexample, because step two depends on what the stack trace in step one says, and browsing and open research behave the same way.

The failure to watch for is a stale plan executed faithfully. The executor keeps working through steps whose premise died two steps earlier and spends tool calls on a situation that no longer exists. On our executive operations agent, which acts inside the user's authenticated applications, page state can move between planning and acting, so it runs a think, act and observe cycle per step. A critic then chooses continue, retry or escalate, because one bad observation would otherwise carry through every later step. Count your replans: if nearly every step triggers one, you have rebuilt ReAct with extra machinery and should run the simpler loop.

What should wake the planner#

Production systems succeed or fail on the replan branch, and four triggers cover most of what should wake the planner:

• A step fails after the executor's own bounded retries.
• A step succeeds but contradicts a later premise, such as the CRM returning seven competitors instead of four.
• The run passes its token, cost or wall-clock budget.
• Every step finished and a checker still judges the goal unmet.

Repair at the smallest scope that works. Retry the step first. Then patch the tail: hand the planner the finished steps, the failure and only the remaining plan, so it rewrites what is left instead of starting again. In the pricing example one blocked fetch becomes a single inserted step that searches for cached pricing, and steps 3 and 4 stand.

Cap full replans and escalate to a person past the cap, because an uncapped replan turns a two-call design back into one call per step. The DevOps agent follows the same rule in its validation loop: a template that will not come clean after bounded revision goes back as a request the agent cannot safely fulfil.

The replan rate as a health signal#

Once the agent is live, the replan rate tells you whether you chose the right shape. Near zero means the steps never change, and a fixed workflow with no planner would do the job with fewer moving parts. Near one per step means the environment decides the next action, and ReAct fits better. Keep the planner when the rate sits in between, and log every trigger that fired, because that log shows which tool or premise breaks most often. The same split scales up in multi-agent orchestration, where the planner becomes an orchestrator and replanning becomes reassigning a step to another agent.