The planner–executor pattern

Two ways to structure an agent’s steps

ReAct, covered earlier in this roadmap, interleaves reasoning and action one step at a time: the agent thinks, acts, observes the result, and thinks again, with every decision made fresh in light of what just happened. That is one way to structure an agent’s steps. The planner–executor pattern is another: split the agent into two distinct roles. A planner — one LLM call — looks at the task and produces the entire sequence of steps needed to complete it, up front, before anything runs. An executor — a loop with no planning responsibility of its own — then works through that sequence, carrying out each step, possibly calling tools, until the plan is done.

A worked plan

Take the task “Book a flight to Denver next Friday and email the confirmation to my manager.” A planner given this task, before touching any tool, might produce something like:

1. Search flights to Denver for next Friday.
2. Select the cheapest option under $400.
3. Book the selected flight.
4. Retrieve the manager’s email address from contacts.
5. Compose and send a confirmation email.

The executor then works through these five steps in order, calling the flight-search tool for step one, a booking tool for step three, a contacts lookup for step four, and an email tool for step five — none of which requires the executor to decide what to do next, only how to carry out the step it’s already been handed. Compare this to a ReAct loop tackling the same task: it would reason about step one, act, observe the flight results, then reason fresh about what to do next, and so on five separate times, each with its own full reasoning pass.

The efficiency case for planning ahead

Because the entire sequence is decided in a single planning call, the planner–executor pattern typically needs far fewer LLM calls for reasoning — one planning call instead of one reasoning call per step — and the resulting plan is a clear, inspectable artifact. You can read the five-step list above and know exactly what the agent intends to do before it does any of it, which makes the whole run easier to log, debug, and even show to a user for approval before execution starts. A ReAct loop, by contrast, only reveals its intentions one step at a time, as it goes.

Where a fixed plan breaks

The same upfront commitment that makes planning efficient is also its weakness. Suppose step one above returns no flights under $400 at all — only options above $600. The plan’s step two, “select the cheapest option under $400,” is now impossible to satisfy as written, because the planner made that assumption without knowing real prices. A rigid executor that simply marches through the fixed plan has no good way to handle this: the plan was built on information that turned out to be wrong, and nothing in the plan itself tells the executor what to do when that happens.

Replanning: getting both properties

The common fix is replanning: after a step executes, instead of blindly continuing to the next item on the original list, the system calls the planner again, handing it the new information and asking it to produce an updated remaining plan. In the flight example, after seeing that nothing is under $400, a replan might change step two to “select the cheapest option regardless of budget and flag the price difference to the user,” then continue from there. This costs an extra LLM call wherever a replan happens, so it isn’t free — but it only pays that cost when something actually changed, rather than on every single step the way a full ReAct loop does, landing the design between the two extremes: close to the efficiency of a fixed plan, with most of the adaptability of reasoning fresh at every step.

Choosing between the two

Neither approach is strictly better. A ReAct loop suits tasks where each step’s outcome is genuinely unpredictable and the next action depends heavily on it — open-ended research, for instance. The planner–executor pattern, especially with replanning, suits tasks that are structured enough to lay out in advance but long enough that paying for fresh reasoning at every single step would be wasteful. Recognizing which shape a task has is itself part of designing the agent well.