ReAct versus plan-and-execute, and the hybrid that production uses
The ReAct note described an agent that decides one step at a time. The alternative is to decide all the steps first and then carry them out. The two differ in when reasoning happens relative to action, and that single difference sets what each is good at. This note compares them, says which tasks each wins, and then describes the three-role hybrid that most production agent systems settle on, with a walkthrough of it handling a task that does not go to plan.
ReAct interleaves: think, act, observe, and choose the next step from what was just observed. Plan-and-execute separates: a planner writes the full sequence up front, an executor runs it, and the results are joined at the end. Interleaving wins when step n+1 cannot be known until step n returns; planning wins when the task's shape is known, its parts are independent, or its horizon is long enough that an interleaved agent drifts. The hybrid, plan-execute-replan, gives a planner the big picture without tools, gives each step to an executor running a short ReAct loop in its own context, and sends the result to a replanner that revises what remains. It keeps the tool mess out of the plan and the plan out of the tools.
Contents
01Two ways to arrange reasoning and action
ReAct, interleaved thought 1 → action 1 → observation 1 │ thought 2 → action 2 → observation 2 → … → final answer each thought sees every observation so far and picks one next step plan-and-execute, decoupled 1. planner reads the task, writes [step 1, step 2, step 3, step 4] 2. executor runs step 1 → step 2 → step 3 → step 4 3. rejoin gathers the step results → final answer the plan is fixed before any tool runs
In ReAct the model plans exactly one step ahead and replans after every observation, for free, because the next thought is generated with the observation in context. In plan-and-execute the reasoning is front-loaded: one call produces the whole sequence, and the executor's job is to carry it out rather than to decide. The planner typically has no tools; the executor has tools and little judgement to exercise.
02What the difference changes
| ReAct, interleaved | Plan-and-execute | |
|---|---|---|
| Control flow | A loop whose next iteration is chosen at runtime | A sequence or graph fixed before execution |
| Context | One growing history holding every observation | The plan, plus a small per-step context for each executor call |
| Adaptation | Immediate; a failed tool or surprising result changes the very next step | None unless a replanning step is built in |
| Parallelism | Within a step only, when the model issues several calls at once; across steps each waits on the last | Independent steps in the plan can run concurrently |
| Cost per step | Rises as history grows; the whole context is resent each turn | Flat; each step sees only what it needs |
| Long horizons | Tends to drift, repeat itself, or lose the original goal | The plan is the goal, written down; the executor cannot wander far |
| Model choice | One model does everything | A strong model plans once, a cheaper one executes many times |
Every row follows from the one architectural fact: ReAct reasons after each observation and plan-and-execute reasons before any. The first buys adaptability and pays in context and cost. The second buys structure, parallelism and cheap execution and pays in rigidity.
03Where interleaving wins
ReAct wins on tasks where the next step genuinely cannot be written down until the last one has returned. The environment, not the task description, determines the path.
- Chained lookups. "Find the current CEO of the startup founded by the author of paper X." The search for the startup cannot be planned until the author is known, and the search for the CEO cannot be planned until the startup is. Any plan written in advance would be a plan to run searches with blanks in them.
- Debugging and diagnosis. A failing endpoint, a cluster that will not schedule pods. Each log line or inspection narrows the branch to follow next. The diagnostic tree is discovered, not designed, and a fixed plan would check the wrong things in the wrong order.
- Conversations that gather what they need. An assistant completing a transaction asks for whatever is missing, and what is missing depends on each answer. The loop is the natural shape of a dialogue.
- Short tasks in general. For two or three steps the overhead of planning exceeds the benefit, and the growing-context cost has no time to bite.
04Where planning first wins
Plan-and-execute wins when the shape of the work is visible from the task description, when the parts do not depend on one another, or when the task is long enough that an interleaved agent would lose its way.
- Fan-out over known items. "Summarise this week's news for these five competitors." The planner writes five identical sub-tasks, they run in parallel in their own contexts, and a final step merges them. A ReAct agent would do the five serially in one ever-growing context, with the fifth summary written while the first company's raw articles are still taking up space.
- Pipelines with a fixed topology. Extract the schema from one database, transform the column types, load into another, send a notification. The order is given; nothing discovered along the way changes it. Planning first means the long-running middle steps cannot distract the agent from the end.
- Cost-sensitive automation. A strong, expensive model writes the plan once. A fast, cheap model executes each step, most of which are routine tool calls that do not need the strong model's judgement. The expensive calls are few and the cheap calls are many.
- Anything that needs a reviewable plan. If a human should approve the approach before tools run, the plan has to exist as an object before execution. ReAct never produces one.
05The hybrid: plan, execute, replan
Each pure form fails in a characteristic way. A ReAct agent on a long task accumulates raw tool output until it drifts, repeats steps, or forgets what it was for. A plan-and-execute agent on a real environment hits the first thing the planner did not foresee, a blocked request, a missing field, an extra case, and either fails the step or carries on executing a plan that no longer fits.
The hybrid takes planning from one and adaptation from the other, at two different scales. Macro-level reasoning is done by a planner that sees the whole task and none of the tools. Micro-level reasoning is done by executors that see one step and all of the tools. And a replanner between them decides, after each step, whether the plan still holds.
┌────────────────────────────────────┐
│ planner │
│ task → ordered steps, each with │
│ what "done" looks like │
└────────────────┬───────────────────┘
▼
┌────────────────────────────────────┐
│ executor (one step, own context) │
│ local ReAct loop with tools: │
│ think → call → observe → … → result│
└────────────────┬───────────────────┘
▼
┌────────────────────────────────────┐
│ replanner │
│ reads the step result: │
│ done as expected → next step │
│ failed or surprised → rewrite │
│ the remaining steps │
│ nothing left → write the answer │
└────────────────────────────────────┘
06The three roles
The planner
Receives the task and produces a sequence or graph of sub-tasks, each with a short statement of what counts as done. It has no tools, by design: a planner that can browse starts browsing, and the plan dissolves into a ReAct loop. Its output is the master state of the run. This is the step to spend a capable model on, because a poor decomposition is not recoverable by good execution.
The executor
Takes one step and runs a short ReAct loop to complete it, with full tool access and a fresh context holding only the step's instructions and inputs. It is expected to handle local friction on its own: retry a failed request, try a different search term, parse a messy response, fall back to a second tool. When done, it returns a compact result, and its context, with all the raw tool output in it, is thrown away. A smaller, faster model usually does fine here, and several executors can run at once on independent steps.
The replanner
Reads each executor's result against the plan and makes one of three decisions. The step did what was expected: pass its result on and start the next. The step failed or turned up something the plan did not anticipate: rewrite, insert or drop the remaining steps. Nothing remains: synthesise the final answer from the accumulated results. This role is what turns a brittle sequence into a recoverable state machine, and it needs the same quality of judgement as the planner; in many implementations the planner and replanner are the same prompt called with different state.
07A walkthrough that does not go to plan
Task: "Analyse our top competitor's current pricing page, compute our price gap across their tiers, and post a summary to the pricing channel."
1. plan step 1 fetch the competitor's pricing page and extract the tiers step 2 compare against our price table and compute the gap per tier step 3 format the summary and post it to the channel 2. execute step 1 (executor, local ReAct) call fetch_page(competitor.com/pricing) obs HTTP 403, bot protection think "direct fetch blocked; use the rendering browser instead" call render_page(competitor.com/pricing) obs HTML retrieved think "three priced tiers, plus an Enterprise tier with no listed price" result tiers: [29, 99, 299], note: Enterprise tier, price on request the 403 was absorbed here; the plan never heard about it 3. replan the result contains something the plan did not expect: an unpriced tier step 2 compare the three priced tiers and compute the gap (kept) step 2b look up recent enterprise quotes for the competitor (inserted) step 3 format and post, including the enterprise estimate (amended) 4. execute 2 and 2b in parallel, independent of each other 5. replan both done; nothing surprising; proceed 6. execute 3 post the summary 7. replan nothing left; write the final report of what was posted
Two things happened that neither pure form handles well. A tool failure was handled entirely inside the executor, without touching the plan, which a pure plan-and-execute system would have failed on. And a discovery changed the plan, in a controlled way, with one step inserted and one amended, which a pure ReAct agent would have handled by wandering into the enterprise lookup mid-stream and perhaps forgetting to post the summary.
08Why the hybrid works
- Context isolation. In pure ReAct every raw page, database dump and stack trace lives in one window until the end. In the hybrid each executor's mess is discarded when its step completes, and only the compact result reaches the master state. The planner and replanner operate on a few hundred tokens of plan and results, not megabytes of observations.
- The right model for each job. Planning and replanning are infrequent and need judgement, so they get the strong model. Execution is frequent and mostly mechanical, so it gets the fast one. The cost profile is a few expensive calls and many cheap ones.
- Two levels of recovery. Small failures are handled locally by the executor's loop; large surprises are handled globally by the replanner. Neither has to deal with the other's class of problem.
- Parallelism where the plan allows it. Independent steps run concurrently, each in its own executor, something a single interleaved loop cannot do across steps.
- A plan you can show someone. The plan is an object. It can be logged, approved, resumed after a crash, and diffed when the replanner changes it.
The roles are a separation of concerns, not a deployment diagram. A single capable model can play all three with different prompts and different context, and current frontier models run a lighter version of the hybrid on their own: they write a task list in their first turn, work through it with tool calls, and revise the list when something changes. The explicit three-role version is what you build when you need the context isolation, the parallelism, or the reviewable plan that the single-context version cannot give you.
09Choosing, in practice
| If the task is… | Start with |
|---|---|
| Short, and each step depends on the last | ReAct, one loop, one context |
| Known in shape, with independent parts, or long | Plan-and-execute, with a replanning step from day one |
| Long and uncertain, or touches an environment that pushes back | The hybrid: planner without tools, executors with tools in their own contexts, replanner between |
| Something a person must approve before tools run | Anything with an explicit plan; never pure ReAct |
The honest default for a new agent is to begin with the simplest form that could work, measure where it fails, and add structure in response. Most agents that end up hybrid got there because a ReAct loop drifted on long tasks, or a plan broke on the first surprise, and the fix for each is one more role.
10Takeaways
- The difference is when reasoning happens. ReAct reasons after each observation; plan-and-execute reasons before any.
- Interleaving buys adaptation and pays in context. It wins when the next step depends on the last result.
- Planning buys structure, parallelism and cheap execution and pays in rigidity. It wins when the shape is known, the parts are independent, or the horizon is long.
- Pure forms fail predictably. ReAct drifts on long tasks; plans break on the first surprise.
- The hybrid separates scales. A planner without tools, executors with tools in isolated contexts, a replanner that revises the remaining steps.
- Local failures stay local; discoveries change the plan. That is the whole point of having both loops.
- Roles are not models. Start simple, add a role when a measured failure calls for it.