ReAct vs Plan-and-Execute Loops in Production
ReAct adjusts as it goes, but Plan-and-Execute costs less once the plan is locked in.
Two agent architectures dominate production systems right now, and picking between them is not a matter of taste. ReAct and Plan-and-Execute make different bets about when an agent should think, and those bets carry real consequences for cost, latency, and how badly things break when a tool returns something the agent didn't expect. Most teams get this decision backwards: they pick a framework first and assume the reasoning pattern comes bundled in.
It doesn't. LangGraph, CrewAI, the OpenAI Agents SDK: these are plumbing. The reasoning pattern running through that plumbing is the actual architecture, and it answers three questions no framework answers for you. When does the agent plan? How many model calls does each task burn through? What happens the moment something fails?
Get those answers wrong and the trouble doesn't show up at prototype stage. It shows up in production, under load, when the fix means tearing the loop apart and rebuilding it, not tuning a parameter. One scope note before diving in: this is about single-agent architecture. Multi-agent orchestration is a real, separate problem, and it only makes sense to tackle once a single agent is solid on its own.
How the ReAct loop works and why it is the right default
ReAct, introduced by Yao and colleagues in 2022, runs on a simple loop: Thought, Action, Observation, Thought again, repeating until the agent has enough to give a final answer. It reasons, takes an action (usually a tool call), reads what came back, then reasons again based on that result.
That loop is why ReAct earns the default slot, and nothing else here should displace it without a reason. It adjusts as it goes. A tool fails, returns garbage, or comes back with something nobody asked for, and the agent re-reasons on the very next step instead of pushing forward on a plan that no longer matches reality.
There's a quieter benefit that matters just as much in production: every thought gets logged. When something breaks, there's a trace showing exactly what the agent believed at each step and why it picked the action it picked. In finance or healthcare, that trail is often required. That's the gap between fixing a bug in ten minutes and staring at a black box wondering what happened.
SWE-agent, built at Princeton in 2024, shows this pattern doing real work. It reads files, runs shell commands, and edits code to close out actual GitHub issues, using a thought-action-observation loop pulled straight from ReAct. Each edit depends on the compiler error the previous edit produced. That's the exact shape of problem ReAct was built for: you cannot know step three until you've seen the result of step two.
The pattern is everywhere now. LangGraph ships create_react_agent (recently folded into the more general create_agent), LangChain has it built in, NeMo supports it. Pick a framework today, and ReAct is the floor everyone builds on top of.
Where ReAct breaks under real load
ReAct's biggest strength, reasoning one step at a time, is also its biggest liability. The agent has no map of the whole task. It can't step back and ask whether the last five actions are converging on the goal or quietly drifting away from it. Nothing in the loop watches for that, and nothing stops it either.
That gap gets expensive fast. In November 2025, four LangChain agents ran for eleven straight days on a failed action with no termination condition in sight. Total bill by the time anyone caught it: $47,000. The fix isn't complicated, a per-tool call cap alongside the usual global step cap, but somebody has to think to add it, because ReAct's loop has no built-in instinct to ask whether it should still be running.
On the ALFWorld benchmark, ReAct beat the paper's named imitation-learning and reinforcement-learning baselines by 34 percentage points. Real result, but it's a result for that benchmark, under that prompting setup. A benchmark ceiling shows what's possible under controlled conditions, not what margin holds up in a messier production environment with real users and real tool failures.
Task-completion numbers from one practical head-to-head make the tradeoff concrete: ReAct hit around 85% accuracy on complex tasks, Plan-and-Execute hit around 92%. Seven points isn't nothing. Whether it's worth restructuring your loop over depends entirely on what that restructuring costs upfront, which is the actual question this piece is building toward.
How Plan-and-Execute restructures the loop and what that costs upfront
Plan-and-Execute splits the job into two roles instead of one continuous loop. A Planner, usually the more capable and more expensive model, breaks the goal into a sequence of subtasks once, upfront. An Executor then works through that sequence step by step. The Executor doesn't need to be fancy: a smaller LLM, a ReAct agent scoped narrowly to one subtask, or in plenty of cases just deterministic code.
That split changes the cost math. Instead of paying for an expensive model at every step, teams pay for it once, at planning time, then run the cheaper model repeatedly for execution. One reported cost comparison found ReAct averaging 2,000 to 3,000 tokens and $0.06 to $0.09 per complex task, while Plan-and-Execute averaged 3,000 to 4,500 tokens and somewhat higher cost per task. Plan-and-Execute costs more per task on paper, but once the plan exists, each execution step tends to run cheaper, since it isn't asking a frontier model to reason from scratch every time.
There's a second advantage that has nothing to do with cost: the plan is readable before a single tool gets touched. That opens the door to a Verifier, human or automated, checking the plan for logical holes, security exposure, or policy violations before the agent takes any action it can't undo. A paper out of SAP and Oxford (arXiv:2509.08646, September 2025) goes further, arguing Plan-and-Execute resists indirect prompt injection in a way ReAct structurally can't, because separating planning from execution keeps the control flow locked down where a step-by-step loop leaves it exposed.
Devin, Cognition's 2024 system for long-horizon coding tasks, runs plan-first and adjusts when execution requires it. Different scale of problem than SWE-agent, longer horizon, more moving parts, but the same underlying bet: commit to a plan, then adjust only when execution proves it wrong. LangGraph's stateful graphs, CrewAI's declarative tool scoping, and AutoGen's Docker sandboxing all implement this pattern their own way. The pattern doesn't care which framework runs it.
Where Plan-and-Execute breaks and how re-planning gates fix it
The plan gets written before the agent has seen a single piece of real tool output. That's the whole weakness in one sentence. If step 2 comes back with something the planner didn't anticipate, step 3 is already sitting there, written, and now wrong.
The fix is a re-plan gate: after every K steps, or whenever a step's output crosses some confidence threshold, the planner stops and checks whether the remaining steps still make sense. OpenSearch's plan-execute-reflect implementation does this after every completed step, and it can add steps, drop steps, or rewrite what's left based on what it just learned. LangGraph's stateful graph structure is designed to support this kind of re-planning integration.
None of that comes free, though. Every re-plan trigger is another expensive call to the Planner model, and if the gate fires too often, the system has just recreated ReAct's per-step cost problem while keeping Plan-and-Execute's added complexity stacked on top. Tuning when the gate fires, not just whether one exists, is the actual engineering work here.
There's a security wrinkle too. A re-plan gate is a new attack surface. If a tool's output can trigger a re-plan, a poisoned or manipulated response can steer the agent's remaining steps somewhere it shouldn't go. The SAP/Oxford paper's answer isn't to avoid re-planning; it's to pair re-planning with task-scoped tool access and sandboxed execution. Re-planning solves staleness. It doesn't solve trust in the data feeding it.
Variants that push the trade-offs further: LLMCompiler and ReWOO
Two variants take the Plan-and-Execute idea and push it in opposite directions: one toward speed, one toward token efficiency. Neither is a starting point, and treating either as one is the mistake to watch for.
LLMCompiler, from Kim and colleagues at ICML 2024, adds parallelism. Instead of a flat list of steps, the planner builds a dependency graph (a DAG) of function calls. A task-fetching unit watches that graph and dispatches each call the moment its dependencies are satisfied, so multiple executors run at the same time instead of waiting in line. The paper reports maximum gains of up to 3.7x lower latency, 6.7x lower cost, and roughly 9% better accuracy compared with ReAct, with a 3.6x speedup also reported. Those top numbers show up on workloads with real parallel structure: independent subtasks that don't need to wait on each other. A task that's inherently sequential won't see anywhere near that improvement, because there's nothing to parallelize.
ReWOO (Xu and colleagues, 2023) goes the other direction: it strips planning and execution apart even further. The planner writes out every step in one pass, using placeholder variables for results it hasn't seen yet, something like #E1 = Search[query] followed by #E2 = Search[hometown of #E1]. A worker fires off all the tool calls, and a solver stitches the final answer together at the end. On HotpotQA, ReWOO showed roughly 5x better token efficiency and a 4% accuracy gain over ReAct, achieved by consolidating LLM calls rather than reasoning step by step.
Committing to a full plan before seeing any results creates the exact catch you'd expect: if a tool returns something the plan didn't account for, everything downstream that depended on it is wrong, and there's no room to correct mid-run. Both variants are what you reach for after a working Plan-and-Execute agent has been profiled and the bottleneck turns out to be parallelism or token cost specifically, not before.
Reflexion as the add-on for repeated failure modes in either pattern
Reflexion functions as a supplementary loop, something bolted onto whichever base pattern is already running. The agent attempts a task, reflects in plain language on what went wrong, then tries again carrying that reflection forward. On HumanEval, this pushed coding pass rates from 80% up to 91%, a jump that step-count limits or better prompting alone won't get you.
That gain costs more as it scales, since every retry is a full run of the task, start to finish. Reflexion is the priciest pattern here on a per-task basis, and it only earns its keep when failure modes repeat in a predictable, well-defined way. For open-ended exploratory work, ReAct's step-by-step adaptability already covers the same ground for a fraction of the price.
Put together, the evidence points one direction: ReAct as the single-agent default, full stop. Reflexion layers on top when failures repeat. Plan-and-Execute swaps in only when planning itself is the bottleneck, not by default, not because it scores higher on one benchmark. Teams that reach for Plan-and-Execute first are usually paying for planning overhead they don't need yet.
Multi-agent setups get reached for before a single agent has hit its ceiling, and that's backwards too. Multi-agent coordination adds a lot of overhead and a lot more surface area for things to go wrong. Build the ReAct baseline first, measure it, then optimize from there.
How live web data changes which pattern holds up
Before any agent reasons over web content, something has to go get it: load the page past bot detection, render whatever JavaScript the page depends on, and hand back text that isn't full of nav bars and ad slots. That fetch-then-parse pipeline shapes both ReAct and Plan-and-Execute, and it decides which pattern actually holds up.
Exploratory retrieval favors ReAct. If the agent has no idea what page two will contain until page one's result comes back, a fixed plan is a liability, not a shortcut. The per-step observation loop is built exactly for that kind of uncertainty.
Structured extraction favors Plan-and-Execute. If the job is pulling five fields from forty known URLs, the plan gets written once, upfront, and the executor fires off those forty extractions in parallel. Known structure maps cleanly onto a DAG, and there's nothing to react to.
Both patterns share one failure mode that neither can reason its way out of: stale data. If the retrieval layer hands back cached or outdated content, the agent reasons perfectly well over information that's simply wrong. That's the RAG freshness problem again, wearing an agentic-tool-use costume this time. Neither ReAct's adaptability nor Plan-and-Execute's foresight fixes a retrieval layer that isn't actually live.
Web scraping tools that return clean, structured text instead of raw HTML cut down on one source of noise for both patterns. ReAct gets a cleaner observation to reason over at each step. Plan-and-Execute's executor runs into fewer parsing failures while working the plan. Neither problem disappears entirely, but the signal each agent works with gets a lot less noisy.
The production decision framework: matching loop to task structure
Start with the shape of the task. If step three genuinely can't be known until step two's result comes back, exploratory search, live debugging, back-and-forth dialogue, ReAct is the right call, and it should be the default assumption walking in. If the task breaks cleanly into subtasks with dependencies known before execution starts, report generation, extraction across several known sources, long-horizon coding work, Plan-and-Execute fits better. If those subtasks run largely independent of each other, that's LLMCompiler's territory.
Then weigh cost against that. ReAct's token spend scales with step count, roughly $0.06 to $0.09 per complex task in practical comparisons, and it climbs fast as tasks get longer. Plan-and-Execute starts higher per task, $0.09 to $0.14, but execution steps after the plan tend to run cheaper, so total cost depends heavily on how often the re-plan gate fires. ReWOO is the cheapest per token by a wide margin, but only pays off when the workload is stable enough that the plan doesn't need mid-course correction.
Latency follows the same logic. ReAct's latency adds up step by step, since each observation waits on a fresh model decision before the next action fires. Plan-and-Execute pays its latency cost upfront during planning, then moves faster during execution, especially with a smaller executor model or with LLMCompiler's parallel dispatch delivering up to 3.7x latency improvement compared with ReAct.
Failure tolerance closes the loop. Fine with wasted tokens on exploratory dead ends? Pick ReAct. Fine with the added complexity of re-planning when assumptions break mid-run? Pick Plan-and-Execute. Can't tolerate repeated quality failures on the same kind of task? Add Reflexion on top of whichever base pattern already fits. Can't tolerate the agent ever blindly executing a bad plan in a high-stakes domain? Pair Plan-and-Execute with a Verifier component and a human-in-the-loop gate before anything irreversible runs.
For core processes in finance or healthcare specifically, the evidence points toward hierarchical planning built on a state machine, not either pattern running solo. High-stakes, tightly regulated work calls for structure that neither loop delivers by default.
