ReAct vs Plan-and-Execute Agent Architectures

Loop shape is the decision. Not the framework, not the prompt template, not which vector database sits behind the retriever. ReAct and Plan-and-Execute answer the same three questions differently: when the agent plans, how many model calls a task costs, and what happens when something breaks. Get the shape wrong for the task and no amount of prompt engineering fixes it.

Take a travel-booking agent wired with ReAct. Asked to find a flight to Lisbon, book a hotel near the venue, and put both on a calendar, it works fine in the demo. Then the flight search comes back empty in production, and the agent spends the next four turns flailing: retrying the same search, second-guessing the city code, drifting further from the job. The hotel never gets booked. The calendar stays empty. Nothing failed loudly. The loop simply never held a model of the whole task, so it had nothing to fall back on when step one didn't cooperate.

That failure and its mirror image, a Plan-and-Execute agent locked into a stale plan, are the two shapes this piece maps. Both patterns are single-agent reasoning loops, not multi-agent orchestration schemes, and the distinction matters because the two problems get solved with different tools entirely.

How the ReAct loop is structured

ReAct comes from Yao et al.'s 2022 paper, the one that turned "give a language model a tool" into a repeatable architecture instead of a one-off trick. The loop itself is simple to state: Thought, then Action, then Observation, then back to Thought, repeatedly until the model decides it has enough to answer. One LLM call per step, no exceptions.

What makes this a genuinely different shape, and not just a smaller version of Plan-and-Execute, is that the plan never exists anywhere except inside that one call. There's no stored sequence of steps sitting in memory. Every turn, the model re-derives what to do next from the transcript so far. That sounds wasteful, and in a real sense it is, but it buys something concrete: each tool result gets folded back in before the next thought fires, so the agent can change direction the instant something surprising appears in the observation. A search that returns nothing, an API that errors out, a form field that doesn't exist, all of it gets seen and reacted to before the next move gets locked in.

On ALFWorld, the benchmark Yao's team used to test embodied task completion, ReAct beat the named imitation-learning and reinforcement-learning baselines by 34 percentage points in absolute success rate. That number belongs to one paper's benchmark and prompting setup, not a guarantee for every ReAct agent built since. Still, it's the number that got people paying attention.

On the tooling side, LangChain and LangGraph's create_agent (successor to the now-deprecated create_react_agent in langgraph.prebuilt) ships this loop out of the box. It hasn't become the default pattern across no-code agent platforms the way it has in code-first frameworks, so the availability varies by where someone's building. What ReAct does deliver everywhere it's used is a clean audit trail: every thought gets logged as a discrete step. In a regulated industry, that trace is essential. It lets a team explain a decision instead of guessing at it after the fact. It lets someone explain a decision instead of guessing at it after the fact.

Where ReAct breaks: the three failure modes that emerge from step-by-step reasoning

The myopia is structural. ReAct sees one step ahead because that's all the architecture gives it to see. It cannot optimize a path it never lays out.

Three specific failure modes follow from that. First, repeated reasoning: the model spends tokens re-deciding things a written-down plan would have settled once. Second, goal drift: each action looks locally sensible, and yet the accumulated sequence of locally sensible actions walks the agent away from what it was actually asked to do. Third, and the sneakiest of the three, faulty grounding: stale or conflicting context gets pulled in and trusted at every single step, produced by the fact that the "reasoning" part of the loop is technically sound while the premise it rests on is wrong the whole time. Fixing the reasoning still leaves a bad premise in place, producing a more confident wrong answer. It just produces a more confident wrong answer.

A cost curve builds beneath the accumulating context. Because context accumulates turn over turn, a 10-step task doesn't cost 10 uniform units: each call is longer than the last because it's carrying the full history forward, so costs grow as context accumulates. Ten steps means ten LLM calls, and each one is more expensive than the one before it. And if the model gets stuck, it can loop, calling the same tool with the same input over and over, burning tokens with nothing to show for it.

The failure runs in both directions. Teams have burned weeks building out Plan-and-Execute architectures, planners, executors, re-planning triggers, for tasks that a four-step ReAct loop would have handled without complaint. Over-engineering is its own failure mode, and it's just as real as the one it's meant to prevent. ReAct earns its keep on exploratory tasks, on tool calls with unpredictable output, on anything where step two genuinely cannot be known until step one comes back.

How Plan-and-Execute separates planning from execution

Plan-and-Execute draws a hard line ReAct never does. A planner model call looks at the full objective and produces an ordered list of steps as an actual data structure, something that can be printed, inspected, and handed off. Then an executor works through that list, one step at a time.

The two roles split cleanly by capability requirement. The planner needs to be the large, expensive model, the one capable of reasoning over an entire multi-step objective and getting the sequence right. The executor doesn't. It can be a smaller, faster model, a ReAct agent scoped down to a single sub-task, or in plenty of cases just deterministic code mapping a task description straight to a function call. Del Rosario et al.'s 2025 framing of this split is useful precisely because it makes the cost structure explicit: pay for intelligence once, at planning time, and let cheaper machinery carry out the rest.

Some implementations add a third role, a Verifier, sitting between planner and executor. A human expert or a separate checking agent reviews the plan before anything runs. That planning-verification-execution pattern matters most where a bad plan executed blindly does real damage, financial transactions, infrastructure changes, anything hard to undo.

LangChain's original 2023 reference implementation used a language model as planner paired with an action agent as executor. It was upfront about the tradeoff: more model calls overall, offset somewhat by using a smaller model for execution. That first version built one plan at the start and never revisited it, a limitation that later designs have tried to work around with explicit re-planning loops.

The upside of the explicit plan is inspectability. Before a single tool gets called, someone (or something) can look at the full task breakdown and the tool selections and catch a bad call before it costs anything. ReAct never offers that window, because the plan lives inside the model and only reveals itself one thought at a time. And the cost dynamic favors Plan-and-Execute on longer jobs: the big model gets invoked for planning and re-planning, while the mechanical middle steps run on smaller models or no LLM at all.

The natural next move, and the one that shows up in the most capable Deep Research systems currently in production, is a hybrid: Plan-and-Execute at the strategic layer, ReAct running inside each individual step. The plan sets the mission. ReAct handles the mess inside each leg of it.

Where Plan-and-Execute breaks: the three failure modes that stem from upfront commitment

Rigidity cuts both ways. It's what makes Plan-and-Execute predictable, and it's what breaks it when the plan going in was wrong and nothing exists to catch that.

Three failure modes, and they mirror ReAct's in an almost symmetrical way. Incorrect premise: stale or conflicting information at planning time shapes the entire step list from the start, and every step downstream can execute flawlessly while the end result is still wrong, because the plan was built on bad ground. Plan staleness: the plan starts from assumptions that were true when it was written, and the world changes underneath it mid-execution without anyone telling the plan. Step-level failure propagation: one step fails partway through, and without a re-planning trigger, every step after it runs on top of a broken foundation.

Re-planning requires deliberate implementation. It's a mechanism someone has to build and wire in deliberately, not a property that appears automatically once you've split planner from executor. LangGraph's stateful graphs support re-planning loops as a design pattern. CrewAI supports tool scoping as part of its design. AutoGen offers built-in Docker sandboxing for code execution, which has to be configured deliberately rather than enabled automatically.

Plan-and-Execute earns its place on stable, multi-step workflows: known dependencies, a task that decomposes cleanly upfront, conditions unlikely to shift mid-run. The over-engineering trap deserves repeating here, not just in the ReAct section: weeks spent building a planner-executor system for a task a short ReAct loop would have finished in an afternoon is a real cost, with the same weight as the pattern's genuine strengths.

The five dimensions that determine which loop shape fits a given task

Every agent architecture answers three questions. Does it plan upfront, plan at each step, or never plan in any explicit sense? How many LLM calls does a given task actually cost? And how does it handle things going wrong, adapting turn by turn, re-planning from scratch, or retrying with self-critique folded in?

Five dimensions make the comparison concrete. On planning approach, ReAct reasons and adjusts one step at a time, while Plan-and-Execute maps the whole task before execution starts. On workflow design, ReAct keeps reasoning and tool use inside a single repeating loop, while Plan-and-Execute splits planner from executor into two distinct roles. On adaptability, ReAct uses each tool result to decide the next move, while Plan-and-Execute only shifts course when a re-planning trigger actually fires. On latency, ReAct waits on a fresh model decision after every observation, while Plan-and-Execute pays an upfront planning cost but can move faster afterward with smaller executors or parallel branches. And on best fit, ReAct suits the unpredictable and exploratory, while Plan-and-Execute suits the stable and multi-step with dependencies known in advance.

None of this guarantees lower token spend, lower latency, or higher accuracy for either pattern. Del Rosario et al.'s 2025 work is direct about that: outcomes hinge on task length, how often conditions shift mid-run, which models sit in which role, prompt size, how slow the tools themselves are, dependencies between steps, retry counts, and how often re-planning actually kicks in. Choosing between the two isn't picking a winner, it's picking which failure mode is tolerable for the job at hand: accumulated cost and goal drift under ReAct, rigidity under ReWOO, retry cost under Reflexion, re-planning complexity under Plan-and-Execute. If the environment is likely to shift mid-task, ReAct's adaptability is worth its cost. If the dependencies are known and inspectability lets the plan be checked before execution, Plan-and-Execute's upfront structure earns the re-planning investment it demands.

Variants and extensions that shift the tradeoffs: ReWOO, LLMCompiler, and Reflexion

ReWOO takes Plan-and-Execute's separation further and strips out the waste. Plan once, using placeholders for values that won't be known until execution, run independent tools in parallel while dependent steps still go in sequence, then synthesize everything at the end. Two LLM calls, start to finish. That's roughly five times the token efficiency of a comparable ReAct run. The tradeoff, though: there's no mid-execution reasoning, so if a tool returns something the plan didn't anticipate, nothing in the loop is positioned to catch it.

LLMCompiler pushes on the parallelism angle specifically. It targets parallelism specifically, executing independent steps concurrently to cut LLM calls and reduce latency for agentic workloads where steps don't depend on each other in a strict chain.

Reflexion takes the opposite bet: slower, but self-correcting. After each attempt, the agent critiques its own output and carries that critique into the next try as memory. On HumanEval, a coding benchmark, that self-critique loop lifted pass rates from 80% to 91%. The cost is that every retry is a full run, not a cheap patch, so Reflexion earns its keep on long-horizon tasks where a failure is recoverable and worth paying to fix.

Tree-of-Thoughts sits apart from all three. It expands multiple reasoning branches through tree search, breadth-first or depth-first, scores the intermediate states, and backtracks when a branch dead-ends. That's the right tool for problems that genuinely need search and the option to reverse course, not sequential task execution.

Framework support for all this varies. LangGraph handles stateful graphs built for re-planning loops. CrewAI supports scoped tool assignment. AutoGen ships built-in Docker sandboxing for code execution. OpenAI's Swarm was archived in March 2025 in favor of the production Agents SDK. Microsoft, for its part, introduced Agent Framework as the recommended starting point for new builds, carrying forward ideas from Semantic Kernel and AutoGen.

Why both patterns depend on web-grounded, fresh context to reason correctly

Grounding fails differently depending on which loop shape is running, but it fails badly in both.

In ReAct, faulty grounding gets pulled in and trusted again at every turn. The reasoning itself might be flawless at each step, technically sound, logically consistent, and still built on a premise that was wrong from the first observation onward. Repeating good reasoning on top of a bad fact doesn't average out to a correct answer. It compounds the original error across every turn that follows.

In Plan-and-Execute, the damage happens earlier and is arguably harder to catch. Stale context at planning time corrupts the entire step sequence before execution even starts, and the executor can run every single step correctly and still land on the wrong outcome, because the plan itself was never sound.

This matters more in agentic systems than in a plain chatbot, because an agent doesn't just say something wrong, it acts on it. A hallucinated fact that would be a wrong sentence in a chat interface becomes a wrong booking, a wrong filing, a wrong trade instruction once an agent is taking real actions off of it. And stale information is harder to catch than an obvious guess, because it looks sourced. A March 2026 error in Google's AI Overview returned 5 PM Nigeria time for an 11 AM EST query, after the US had shifted to EDT, an answer that was internally consistent and confidently wrong because it was reasoning correctly about the wrong version of reality.

Grounding in live web search measurably narrows this gap. Web-grounded systems have shown accuracy gains of 25 to 40 percentage points over ungrounded baselines on factual recall and multi-hop reasoning tasks, with the largest gains occurring on queries that need current information or require cross-referencing several facts at once. It's part of why ReAct-style prompting, reasoning steps stated before any action fires, has become close to standard practice across agentic search systems generally, independent of which broader loop shape wraps around it.

Stamp every retrieved chunk with a fetch time. For anything time-sensitive, prices, personnel, legal status, software version numbers, treat live search as the primary source and let training data serve only as a fallback for knowledge that's genuinely stable over time.

What the retrieval layer must deliver for either loop shape to work at production scale

Neither loop shape survives production on a retrieval layer built for humans reading web pages.

The content needs to arrive machine-ready: structured, dense, selected for semantic relevance rather than formatted for a person scrolling through a browser tab. Freshness has to be explicit, a live fetch carrying a timestamp, so the agent isn't just getting content but getting a way to reason about how recent that content actually is. And reliability under load isn't optional at either end of the spectrum: a Plan-and-Execute planner needs to ground an entire step list in a single round-trip without the retrieval layer stalling out, and a ReAct loop calling search on every observation turn needs that same latency to hold steady call after call, not just on the first one.

Get that layer wrong, and the loop shape stops mattering. A ReAct agent reasoning cleanly on stale context and a Plan-and-Execute agent executing a flawless plan built on a bad premise end up in the same place: confident, structured, and wrong.