Plan-and-Execute vs ReAct

Introduction

In L127 (Task Decomposition & Planning) you learned to decompose a goal into a plan. This lesson answers the very next question: when do you actually do that reasoning — all upfront, or as you go?

That single choice defines the two most important agent architectures, and they sit at opposite ends of one axis:

ReAct (L111) — reason every step. Think, act, observe, then think again based on what you saw. Maximally adaptive.
Plan-and-Execute — reason once. Make the whole plan upfront, then just execute it. Maximally efficient.

The entire comparison reduces to one question: how often do you re-reason? Every step (ReAct), once (Plan-and-Execute), or once-plus-a-final-solve (ReWOO). Everything else — cost, latency, adaptability — follows from that.

In this lesson:

The three architectures — ReAct, Plan-and-Execute, and ReWOO — and their execution shapes
The core axis (re-reasoning frequency) and the cost ↔ adaptability trade-off
When to use which, the hybrid most production systems land on, and the 2026 reasoning-model twist

Scope: this is the architecture trade-off. Self-reflection / self-critique is L129 (Self-Reflection & Self-Critique), Tree-of-Thought / search is L130 (Tree-of-Thought & Search-Based Reasoning), and re-planning & recovery (adapting a plan when reality breaks it) is L131 (Replanning & Recovering From Failure) — we'll point there, not pile it in.

An infographic titled 'Plan-and-Execute vs ReAct'. Once you can decompose a task (L127), the next question is WHEN to reason — and the whole comparison collapses to one axis: HOW OFTEN DO YOU RE-REASON? REACT (L111) interleaves Thought, Action, Observation and re-reasons before EVERY action — it adapts instantly to each result, which is ideal for dynamic or exploratory tasks, but it costs a full model call per step, runs up tokens and latency, and can wander or loop on long tasks. PLAN-AND-EXECUTE reasons ONCE to produce a full multi-step plan, then an executor runs the steps cheaply (often with a smaller model) without re-reasoning — efficient, inspectable, and great for complex multi-step tasks with dependencies, but rigid because the plan was made before seeing any result. REWOO (Reasoning WithOut Observation) goes furthest: the planner writes EVERY step and tool call upfront using placeholder variables (#E1, #E2, #E3) for results it has not seen, the executor fills them in with no model calls, and a single Solver pass produces the answer — about 2 model calls total versus N for ReAct, 30 to 50 percent fewer tokens, perfect for predictable, structured, high-throughput workflows, but it cannot react if a result surprises it. THE TRADE-OFF: ReAct = maximum adaptability, maximum cost; Plan-and-Execute = one plan, efficient and inspectable; ReWOO = fewest calls, zero mid-plan adaptation. WHEN TO USE: ReAct for dynamic tasks where each observation strongly shapes the next step; Plan-and-Execute for complex, dependency-rich, latency-sensitive, parallelizable, or auditable tasks (LLMCompiler plans a DAG and runs it in parallel); ReWOO for repeatable, predictable pipelines where speed and token cost dominate. THE HYBRID that most production systems actually use: make a high-level plan first so the goal stays anchored, then execute it with ReAct-style adaptivity, re-planning when results demand it. THE 2026 NUANCE: reasoning models blur the line — a single ReAct step with a model doing extended thinking already contains a plan, so explicit plan-and-execute matters most for multi-tool, long-horizon, cost-sensitive, or inspectable systems; modern models also wander less in ReAct. Takeaway: pick the architecture by how much the next step depends on the last result — re-reason every step when you must adapt, plan once when the path is clear, and hybridize in between.

ReAct — Reason Every Step

You built ReAct from scratch in L111 (Building a ReAct Agent From Scratch), so just the essentials here. ReAct interleaves reasoning and acting: Thought → Action → Observation, looping, with the model re-deciding its next move after every observation.

# ReAct (L111): re-reason after EVERY observation
while not done:
    thought = model(history)        # ← a full model reasoning call EVERY step
    action  = thought.tool_call
    obs     = execute(action)       # the result shapes the NEXT thought
    history += [thought, action, obs]
# Adapts instantly to each observation — but that's N model calls for N steps,
# and on a long task it can wander, repeat itself, or loop.

Its superpower is adaptability. Because it reasons after seeing each result, it can change course the instant something unexpected happens — a search returns nothing, a value is surprising, a step fails. For dynamic, exploratory tasks where you genuinely can't know step 3 until you've seen step 2's result, nothing beats it.

Its cost is exactly that reasoning. Every step is a full model call — so an N-step task is N reasoning calls' worth of tokens and latency. And on long tasks, ReAct can wander (chase tangents), repeat itself, or loop — the global goal lives only in the growing transcript, which the model can lose track of. It's powerful, and it's the expensive, least-structured end of the axis.

Plan-and-Execute — Plan Once, Then Do

Plan-and-Execute flips the order: a planner reasons once to produce the entire multi-step plan, then an executor carries out the steps without re-reasoning each one.

# Plan-and-Execute: reason ONCE, then run the plan
plan = planner_model(goal)          # ← one big reasoning call (the capable model)
for step in plan.steps:
    result = executor(step)         # cheap — NO re-reasoning (often a smaller model)
    # if a result breaks the plan, you re-plan here — that's L131
answer = finalize(results)
# One plan call + cheap execution. Inspectable and efficient — but committed to a
# plan written before any result came back.

Three things make this attractive:

Efficiency. One expensive planning call, then cheap execution — you can even use a big model to plan and a small, fast model (or no model) to execute. Far fewer tokens than reasoning every step.
An explicit, inspectable plan. The plan is an artifact you (or a human, or a critic) can read and approve before anything runs — impossible with ReAct's just-in-time reasoning.
It keeps the global goal anchored. The whole structure is decided at once, so the agent is far less likely to wander off-task than ReAct.

The cost is rigidity. The plan was written before a single result came back. If step 2 returns something the plan didn't anticipate, a pure plan-and-execute just... keeps following the stale plan. (The fix — re-planning — is its own lesson, L131 — Replanning & Recovering From Failure.) It's the structured, efficient, less-adaptive end of the axis.

ReWOO — Reasoning Without Observation

ReWOO (Reasoning WithOut Observation, Xu et al. 2023) pushes plan-and-execute to its logical extreme: the planner writes every step and every tool call upfront — including calls whose inputs depend on results it hasn't seen yet — using placeholder variables for those future results.

# ReWOO (Reasoning WithOut Observation): plan EVERYTHING upfront, then execute + solve
plan = planner_model(goal)
#  Plan (placeholders for results not yet seen):
#    #E1 = search["countries by GDP"]
#    #E2 = search["capital of " + 3rd(#E1)]
#    #E3 = search["population of " + #E2]
evidence = execute_all(plan)        # fills #E1, #E2, #E3 — NO model calls here
answer   = solver_model(goal, evidence)   # one final reasoning call
# ~2 model calls total (plan + solve) vs ~N for ReAct → 30-50% fewer tokens.
# But it committed to the plan before seeing a single observation.

The trick is the #E variables: #E2 = search["capital of " + 3rd(#E1)] references #E1's result before it exists. The planner produces the whole dependency graph in one shot; the executor fills the variables in (with no model calls); then a single Solver call reads the filled-in evidence and answers.

Why it's compelling: it eliminates the per-step "internal monologue" entirely. Just ~2 model calls total (plan + solve) regardless of step count, which benchmarks put at 30–50% fewer tokens than ReAct on equivalent workflows (and far more on long traces). For predictable, structured, high-throughput pipelines — batch analysis, report generation over known sources — it's the efficient champion.

Its weakness is the flip side of its strength: committing to the entire plan before any observation means it can't react when a result is surprising or the environment is uncertain. No observations during planning = no adaptation. It's the cheapest, most rigid end of the axis.

See It — Three Architectures, One Task

The same task, three ways. Toggle between them and watch the trace shape and the metrics change:

The same multi-step task — “population of the capital of the country with the 3rd-highest GDP?” — run three ways. Toggle ReAct, Plan-and-Execute, and ReWOO and watch the trace SHAPE change: ReAct interleaves a Thought (a ↻ model call) before every Action and adapts at each observation (4 calls, highest cost); Plan-and-Execute reasons ONCE to make the whole plan then executes cheaply (1 call, efficient, but rigid); ReWOO plans every step with placeholder variables (#E1…), executes with no model calls, and solves once (2 calls, 30–50% fewer tokens, zero mid-plan adaptation). The metrics panel (reasoning calls · adapts mid-run · relative cost) makes the trade-off concrete: it all comes down to how often you re-reason.

Read the shapes against the metrics panel:

ReAct — a ↻ call before every action (4 reasoning calls), adapts at each observation, highest cost.
Plan-and-Execute — one Plan call, then cheap executes (1 reasoning call), efficient but committed.
ReWOO — a Plan with #E variables, execute-all, one Solve (2 calls), the fewest tokens, zero mid-run adaptation.

Same answer, wildly different cost and adaptability — entirely because of how often each one re-reasons.

The Core Axis & When to Use Which

Lay the three on the one axis — re-reasoning frequency — and the decision guide writes itself:

	ReAct	Plan-and-Execute	ReWOO
Re-reasons	every step	once (+ re-plan)	once + one solve
Model calls	~N (one per step)	1 + cheap execs	~2 (plan + solve)
Adapts mid-run	✅ instantly	⚠️ only via re-plan	❌ not at all
Cost / latency	highest	low	lowest
Best for	dynamic, exploratory	complex, dependency-rich, auditable	predictable, structured, high-throughput

Choose by one test: how much does the next step depend on the result of the last one?

High / unpredictable (each observation reshapes the plan; you're exploring) → ReAct.
Known structure, but you want efficiency + an inspectable plan + parallelism → Plan-and-Execute (and if the subtasks are independent, plan a DAG and run it in parallel — LLMCompiler, L123 — Parallel & Sequential Tool Calls/L119 — Orchestrator-Worker).
Predictable, repeatable, latency/cost-critical, results rarely surprise you → ReWOO.

Rule of thumb: the more the environment can surprise you, the more often you should re-reason. Calm, known path → plan once. Wild, unknown terrain → reason every step.

The Hybrid (What Production Actually Does)

In practice you rarely pick one pole and live there. The robust, common pattern is a hybrid that takes the best of both:

Make a high-level plan first (so the goal stays anchored and you get an inspectable structure), then execute it ReAct-style — reasoning at each step within the plan, and re-planning when a result invalidates it.

This is plan-and-execute with re-planning (the LangChain pattern), and it's deliberately the middle of the axis: you pay for some re-reasoning (not none, not every-step) in exchange for both a stable global goal and the ability to adapt. Concretely:

A planner drafts the steps. An executor runs each — using ReAct locally if a step is itself fuzzy.
After each step (or on failure), a quick check: does the plan still hold? If not, re-plan the remainder (L131).
For independent steps, parallelize (orchestrator-worker, L119 — Orchestrator-Worker; LLMCompiler's DAG, L123 — Parallel & Sequential Tool Calls).

The architectures aren't rival religions — they're dials. Production systems set the dial per task: more planning where the path is clear, more ReAct where it isn't.

The 2026 Nuance — Reasoning Models Blur the Line

There's a twist that's reshaping this whole comparison: modern reasoning models do a lot of planning inside a single step. When a model with extended thinking takes a turn, its hidden reasoning often is a plan — so one "ReAct step" can already contain decomposition, look-ahead, and self-correction that used to require an explicit external loop (the implicit-planning point from L127 — Task Decomposition & Planning, the test-time-compute idea from L120 — Evaluator-Optimizer).

Two practical consequences:

ReAct wanders less than it used to. Stronger models hold the goal better across steps, so the classic "ReAct loops forever" failure is rarer — though still real on long horizons.
Explicit architecture matters most at the seams. The framework choice (plan-execute vs ReAct vs ReWOO) earns its keep when you have multiple tools, a long horizon, hard cost/latency budgets, or an auditability requirement — i.e. when the orchestration across calls is the hard part, not the reasoning within one call.

Don't build a ReWOO pipeline for something a single reasoning-model turn handles. Reach for an explicit architecture when the task spans many model/tool calls — that's exactly where re-reasoning frequency becomes a real cost-and-reliability lever.

🧪 Try It Yourself

Reason through these, then use the comparator to confirm:

Predict: for a 6-step task, roughly how many model reasoning calls does ReAct make vs Plan-and-Execute vs ReWOO?
You're building a batch report generator over known data sources, run thousands of times a day. Which architecture, and why?
An agent debugs a flaky test — each run's output determines the next thing to try. Which architecture, and why?
Why can ReWOO use 30–50% fewer tokens than ReAct — what specifically does it not do?
What's the one-line description of the hybrid most production systems use, and where does it sit on the re-reason axis?

→ (1) ReAct ≈ 6 (a reasoning call per step); Plan-and-Execute ≈ 1 (plan) + cheap executes; ReWOO ≈ 2 (plan + solve). (2) ReWOO (or plan-and-execute) — the steps are predictable and repeatable, results rarely surprise, and cost/throughput dominate; you don't need per-step adaptation. (3) ReAct — it's dynamic: each observation (the test output) strongly shapes the next step, which is exactly what interleaved reasoning is for. (4) It doesn't re-reason between steps — no per-step "internal monologue"; it plans once, executes with no model calls, and solves once (~2 calls vs ~N). (5) Plan a high-level structure first, then execute ReAct-style and re-plan when needed — it sits in the middle of the axis (some re-reasoning, not none and not every-step).

Mental-Model Corrections

"ReAct vs Plan-and-Execute is good vs bad." Neither — they're ends of one axis (re-reasoning frequency). The right choice depends on how much the next step depends on the last result.
"Plan-and-Execute means you never adapt." Pure plan-and-execute is rigid, but the standard version re-plans when needed (L131); the hybrid adds ReAct-style adaptivity within the plan.
"ReWOO is just plan-and-execute." ReWOO goes further: it plans all tool calls upfront with placeholder variables and does no reasoning during execution — fewest calls, zero mid-plan adaptation.
"More reasoning is always better." Re-reasoning every step costs tokens, latency, and risks wandering. When the path is clear, planning once is better and cheaper.
"ReAct is obsolete / always loops." Modern reasoning models wander far less, and ReAct is still the best fit for genuinely dynamic tasks. It's a tool, not a relic.
"Pick one architecture for your whole system." They're dials you set per task — plan more where the path is known, ReAct more where it isn't; most production systems hybridize.
"A reasoning model makes the architecture irrelevant." It handles planning within a call; the architecture still governs orchestration across many tool/model calls — which is where cost and reliability live.

Key Takeaways

One axis explains all of it: how often do you re-reason? ReAct = every step, Plan-and-Execute = once, ReWOO = once + one solve.
ReAct (L111): interleaved Thought→Action→Observation — maximally adaptive, but ~N model calls, token-heavy, can wander. Best for dynamic / exploratory tasks.
Plan-and-Execute: reason once into a full plan, execute cheaply (big-model-plans / small-model-executes). Efficient + inspectable, but rigid without re-planning. Best for complex, dependency-rich, auditable tasks.
ReWOO: plan every step + tool call upfront with placeholder variables, execute with no model calls, solve once — ~2 calls, 30–50% fewer tokens, zero mid-plan adaptation. Best for predictable, high-throughput pipelines.
Choose by dependence: the more each step depends on the last result (and the more the environment can surprise you), the more often you re-reason.
Production hybrid: high-level plan first, then ReAct-style execution with re-planning — the middle of the axis; parallelize independent steps (LLMCompiler, L119 — Orchestrator-Worker/L123 — Parallel & Sequential Tool Calls).
2026 nuance: reasoning models plan within a step, so explicit architecture matters most across many tool/model calls (multi-tool, long-horizon, cost-/audit-sensitive).
Next — L129: Self-Reflection & Self-Critique — how an agent checks and improves its own reasoning and output.