ReWOO is a plan-first architecture for Tool-Augmented LLMs that separates task decomposition from tool execution: a planner writes the whole tool-use plan before seeing observations, workers execute the specified calls, and a solver integrates the resulting evidence. Its central claim is not that observations are useless, but that repeatedly injecting observations into every reasoning step creates prompt redundancy, cost, latency, and failure modes that can be avoided when the task is sufficiently predictable.
Coverage note: verified through May 18, 2026.
Definition
ReWOO stands for Reasoning WithOut Observation, introduced by Xu et al. in the 2023 paper ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models. The name is slightly misleading unless read carefully: ReWOO does not solve without observations. It plans without observations, then executes tools, then solves using the collected evidence. The “without observation” claim applies to the planner’s reasoning phase, not to the whole system. arXiv
The architectural pattern is:
User task → Planner: produce a complete plan with evidence variables → Worker(s): execute tool calls and bind results to variables → Solver: combine original task + plan + evidence into final answer
In contrast, ReAct Agents use an interleaved loop:
Thought → Action → Observation → Thought → Action → Observation → ...
ReAct’s strength is adaptivity: the next reasoning step can respond to the latest observation. ReWOO’s strength is compilation: the plan is explicit, inspectable, cheaper to execute, and less exposed to observation-induced drift. ReAct’s paper defines the paradigm as generating reasoning traces and task-specific actions in an interleaved manner so that actions can gather information and reasoning can update plans; ReWOO deliberately breaks that loop for efficiency. arXiv+2research.google+2
Background: why observation-dependent agents became expensive
Tool-using LLM systems emerged because base language models are limited by stale knowledge, weak arithmetic, no access to private databases, and no ability to act in external environments. The broader Augmented Language Models literature treats reasoning as decomposing hard tasks into subtasks and tool use as calling external modules such as search engines, calculators, code interpreters, or APIs. arXiv
ReAct was the influential early agent pattern because it joined reasoning and acting in the same loop. A model writes a reasoning trace, chooses an action, receives an observation from an external source, and uses that observation to decide the next step. This is a natural fit for open-ended environments, embodied tasks, web navigation, and partially observed problems, because the agent can revise its plan as the world responds. arXiv
Xu et al.’s critique is that the same interleaving is often wasteful in stateless API settings. Each new LLM call must be reconditioned on the context prompt, examples, prior reasoning traces, prior tool calls, and prior observations. If the task takes five steps, the context is not paid for once; large parts of it are paid for repeatedly. The ReWOO paper identifies this as prompt redundancy and argues that it becomes a practical bottleneck for multi-step augmented language model systems. arXiv
The deeper methodological issue is Separation of Concerns. In ReAct, one model invocation is simultaneously doing planning, tool selection, observation interpretation, exception handling, and answer synthesis. In ReWOO, those responsibilities become separate modules. The planner designs a blueprint; the worker executes calls; the solver synthesizes evidence. That separation is the paper’s most durable contribution, independent of whether the exact ReWOO prompt format becomes standard. arXiv
Algorithmic structure: Plan–Work–Solve
1. Planner
The planner receives the task, tool descriptions, and demonstrations. It emits a sequence of interleaved Plan: lines and evidence-binding lines such as #E1 = Wikipedia[query] or #E2 = LLM[prompt using #E1]. Each evidence variable is a placeholder for a future tool result. Later steps can reference earlier placeholders before the actual evidence exists. Xu et al. describe this as a sequence of tuples (Plan, #E), where each #E stores evidence from a designated worker call. arXiv
A typical ReWOO plan looks like:
Plan: Search for background on entity A.#E1 = Wikipedia[entity A]Plan: Extract the relevant attribute from the evidence.#E2 = LLM[What is the relevant attribute? Context: #E1]Plan: Search for background on the extracted attribute.#E3 = Wikipedia[#E2]Plan: Answer the original comparison question.#E4 = LLM[Compare #E2 with #E3 for the requested property.]
This format turns reasoning into a symbolic-ish dataflow graph. The plan is not merely prose; it defines variables and dependencies. That makes ReWOO closer to an Agent Workflow Graph than to ordinary chain-of-thought prompting.
2. Worker
The worker stage executes the tool calls named by the planner. It substitutes available evidence variables into later calls and records results under the planned #E identifiers. In the original ReWOO design, workers may include search, Wikipedia retrieval, WolframAlpha, calculator tools, private-document search, a separate LLM call, or application-specific tools. Xu et al. used different tool sets across HotpotQA, TriviaQA, GSM8K, StrategyQA, PhysicsQA, SportsUnderstanding, and SOTUQA. arXiv
A minimal implementation looks like this:
def rewoo(task, tools, planner_llm, solver_llm): plan = planner_llm.generate_plan(task, tools) evidence = {} for step in topological_order(plan.steps): tool_input = substitute_variables(step.tool_input, evidence) evidence[step.evidence_id] = tools[step.tool_name](tool_input) return solver_llm.solve(task=task, plan=plan, evidence=evidence)
If the plan is strictly sequential, the worker executes sequentially. If the plan contains independent tool calls, execution can be parallelized. This point is important: ReWOO exposes the dependency structure needed for parallelization, but the original paper’s main experiments emphasize token efficiency rather than measured latency gains from parallel execution. Later systems such as LLMCompiler make the parallelism explicit by generating a dependency-aware function-calling plan and scheduling ready tasks in parallel. arXiv+2Proceedings of Machine Learning Research+2
3. Solver
The solver receives the task, the planned steps, and the collected evidence. It produces the final response. Xu et al. explicitly note that the solver should use the evidence “with caution,” because long retrieved passages may contain irrelevant material. This makes the solver a synthesis and filtering module, not a blind concatenation step. arXiv
This matters for Retrieval-Augmented Generation. ReWOO does not assume every retrieved observation is trustworthy. It reduces observation exposure during planning, but the final answer is still grounded in tool outputs. The solver is where observation returns.
Token economics: why ReWOO can be cheaper
The paper’s core efficiency argument is simple: ReAct repeatedly resends the same context, examples, and accumulated trace. For a task with k reasoning steps, each new call includes earlier thoughts, actions, and observations. Since observations can be long, the prompt can grow rapidly. Xu et al. formalize this with a token decomposition showing that observation-dependent reasoning repeats the question, context, exemplars, and accumulated trajectory across calls. arXiv
ReWOO instead pays for:
Planner prompt + task + examples+Solver prompt + task + plans + evidence
The worker calls may consume tokens when an LLM is used as a tool, but the planner itself is not restarted after every tool observation. This makes the cost scale more like a compiled workflow than an interactive transcript. The paper argues that the saving grows with task complexity, especially when context prompts and demonstrations are large. arXiv
The key insight for Prompt Efficiency is that observations are not free context. They are often verbose, partially irrelevant, and paid for repeatedly in interleaved agents. ReWOO treats them as data to be collected and passed to a final synthesizer, not as material that must condition every planning decision.
Empirical results
Xu et al. evaluated ReWOO against Direct Prompting, Chain-of-Thought, and ReAct across six public NLP benchmarks plus a curated State of the Union QA task. The main comparison is ReWOO vs. ReAct, because both are augmented language model systems with tools. The authors report that, averaged over six public benchmarks, ReWOO reduced token use by 64% while gaining 4.4 percentage points of accuracy over ReAct. arXiv
Reported ReAct vs. ReWOO results
| Dataset | ReAct accuracy | ReWOO accuracy | ReAct tokens | ReWOO tokens | Main takeaway |
|---|---|---|---|---|---|
| HotpotQA | 40.8 | 42.4 | 9,795.1 | 1,986.2 | Roughly 5× token reduction with small accuracy gain |
| TriviaQA | 59.4 | 66.6 | 4,212.9 | 1,340.9 | ReWOO substantially improves both accuracy and cost |
| GSM8K | 62.0 | 62.4 | 1,874.3 | 1,089.3 | Similar accuracy, lower token use |
| StrategyQA | 64.6 | 66.6 | 1,686.3 | 1,287.1 | Small gain, moderate token reduction |
| PhysicsQA | 64.1 | 66.0 | 2,163.3 | 1,225.7 | Small gain, lower token use |
| SportsUnderstanding | 58.6 | 61.3 | 1,720.0 | 854.2 | Better accuracy and about half the tokens |
| SOTUQA | 64.8 | 70.2 | 1,840.3 | 1,048.8 | Better on curated document/tool QA |
Source: Xu et al. Table 2. The paper’s prose says ReWOO outperforms ReAct on SOTUQA by 8% absolute accuracy, but the table values shown in the paper imply a 5.4-point gain, so the table should be treated as the more concrete record. arXiv+2arXiv+2
The strongest headline result is HotpotQA: ReWOO reports 42.4 accuracy against ReAct’s 40.8 while using 1,986.2 tokens instead of 9,795.1. The abstract summarizes this as 5× token efficiency and a 4% accuracy improvement on HotpotQA, though “4%” appears to be relative or rounded rather than the absolute table difference. arXiv
Robustness under tool failure
The paper also tested a tool-failure condition where all tools returned “No evidence found.” ReAct’s HotpotQA accuracy dropped by 40.8 points, effectively collapsing from its normal reported accuracy, while ReWOO dropped by 29.2 points. ReWOO still degraded badly; the claim is relative robustness, not immunity. arXiv
The appendix gives a useful failure analysis. In 100 sampled HotpotQA failures, ReAct had more “Bad Reasoning” failures and 18 “Token Excess” failures, while ReWOO had zero “Token Excess” failures but more “Tool Inefficacy” and “Answer Miss” failures. The authors observed that bad tool responses could derail ReAct into repeated tool-calling loops, while ReWOO’s plan often remained reasonable but could be based on false assumptions about what tools would return. arXiv
That distinction is central. ReWOO reduces one class of failure—context bloat and observation-driven drift—but exposes another: brittle up-front assumptions.
Parameter efficiency and planner distillation
A secondary contribution is that ReWOO’s planner can be trained separately because it does not need tool observations during planning. Xu et al. generated planner traces from GPT-3.5/text-davinci-style models, filtered successful examples, and fine-tuned a 7B LLaMA/Alpaca-derived planner. They report that the specialized 7B planner could match a much larger GPT-3.5 planner on several tasks in their setup. arXiv
This is one of the most interesting implications for Self-Improving Systems. If planning, execution, and solving are separable, each module can be logged, evaluated, distilled, and improved independently. A production system can train a better planner without retraining tool wrappers or the solver; it can replace a search worker without changing the planning prompt; it can benchmark solvers on fixed plan/evidence pairs.
Methodological contribution: separation of planning from tool use
ReWOO’s methodological contribution is not merely “use fewer tokens.” It reframes an agent as a pipeline with distinct failure surfaces:
| Component | Responsibility | Typical failure | Debugging handle |
|---|---|---|---|
| Planner | Decompose task; select tools; define dependencies | Missing step, wrong tool, impossible assumption | Plan validation, schema checks, plan critique |
| Worker | Execute tool calls; bind evidence variables | Tool failure, bad retrieval, malformed output | Tool logging, retries, typed outputs |
| Solver | Synthesize final answer from task + plan + evidence | Wrong inference, overtrusting evidence, ignoring evidence | Answer checks, citation checks, verifier model |
This is clean engineering. It aligns with Modular Agent Architecture and Typed Tool Interfaces. A ReAct trace is often easier for a human to read as a story, but harder to decompose into independently testable units. ReWOO’s plan can be inspected before tools run, workers can be measured against expected output contracts, and solvers can be evaluated on fixed evidence bundles.
There is also a philosophical angle relevant to AI Agency. ReAct treats cognition as situated and reactive: thought changes as the world pushes back. ReWOO treats cognition more like compilation: infer the structure of the task, bind external facts later, and synthesize. Neither picture is universally correct. Each encodes a different theory of how much the agent can know before acting.
Relationship to plan-and-execute agents
ReWOO belongs to the broader family of Plan-and-Execute Agents, but it is more specific than the generic plan-and-execute pattern. Generic plan-and-execute systems usually create a high-level task list, then an executor agent handles each step, often with its own tool-use loop. LangChain’s planning-agents writeup describes this as a planner that generates steps and executor(s) that invoke tools, with optional replanning after execution. LangChain
ReWOO differs in two ways. First, its plan includes tool calls, not just subtasks. Second, it includes variable assignment, allowing later tool calls to depend on earlier results without invoking a planner again. LangChain’s comparison explicitly notes that ReWOO permits variable assignment in the planner output and can execute a task list without replanning each time. LangChain
| Pattern | Planning style | Tool execution | Observation use | Best fit |
|---|---|---|---|---|
| Chain-of-Thought | One-shot reasoning trace | Usually none | Internal only | Closed-book reasoning |
| Self-Ask | Decompose into follow-up questions | Optional search | Sequential subquestion answers | Multi-hop QA |
| ReAct | Interleaved thought/action/observation | Tool call each loop | Every step conditions on observations | Exploration, web, embodied tasks |
| Plan-and-Execute | Up-front high-level plan | Executor handles each step | Often replans after execution | Long tasks with recoverable failures |
| ReWOO | Up-front tool-specific plan with variables | Worker binds evidence variables | Planner avoids observations; solver uses evidence | Predictable multi-tool workflows |
| LLMCompiler | Up-front dependency-aware function plan | Parallel scheduler | Replans or joins depending on design | Low-latency multi-function calling |
Self-Ask is an important predecessor because it explicitly asks and answers follow-up questions before answering the original question, and can plug search into those follow-up questions. But Self-Ask does not provide ReWOO’s planner-worker-solver separation or general tool-binding architecture. arXiv
Plan-and-Solve prompting is another predecessor: it first devises a plan, then carries out subtasks. Its goal is mainly to improve zero-shot chain-of-thought reasoning and reduce missing-step errors, not to architect a tool-using agent with workers and evidence variables. ACL Anthology
LLMCompiler is a later close relative. It explicitly targets parallel function calling with a planner, task-fetching unit, and executor. Its ICML 2024 paper reports latency speedups up to 3.7×, cost savings up to 6.7×, and accuracy improvement of roughly 9% compared with ReAct. In design terms, it takes ReWOO’s “compile the workflow” intuition and pushes it toward dependency-aware scheduling. Proceedings of Machine Learning Research
What ReWOO gets right
1. It makes plans inspectable
A ReWOO plan can be reviewed before execution. That matters for workflows involving cost, risk, or user approval. In a ReAct loop, the plan emerges over time; in ReWOO, the plan is an artifact. This supports Human-in-the-Loop Agents, policy checks, tool permissioning, and static validation.
2. It minimizes repeated context
The empirical token savings are the most concrete result. ReWOO’s HotpotQA token use was about one-fifth of ReAct’s in the reported setup, and the average public-benchmark result was a 64% token reduction. arXiv
3. It isolates observation noise
In ReAct, every tool result becomes part of the next reasoning context. Bad retrieval can derail the subsequent plan. ReWOO postpones observation exposure until the solver stage, so one noisy observation is less likely to mutate the entire future trajectory. The paper’s failure analysis supports this: ReAct failure cases included repeated loops after bad tool outputs, while ReWOO’s failures were more often bad assumptions or final-answer misses. arXiv
4. It creates a path toward smaller specialized models
Because the planner does not need live tool observations, it can be distilled from traces. This does not prove general small-model agency, but it is a plausible engineering path: specialize a planner for workflow decomposition, use deterministic or typed tools for execution, and reserve large models for hard synthesis. arXiv
5. It reveals the agent as a graph
Even when written as a list, ReWOO is a dependency graph. #E4 depends on #E2 and #E3; independent #E calls can run concurrently; failed nodes can be retried; typed nodes can be validated. This anticipates the graph-based direction of modern agent frameworks such as LangGraph and compiler-like function-calling systems. LangGraph documentation emphasizes durable, stateful orchestration for agents, while LangChain’s planning-agents article places ReWOO beside plan-and-execute and LLMCompiler. docs.langchain.com
Limitations
1. Planner quality is the bottleneck
If the planner omits a needed step, chooses the wrong tool, or assumes a tool will return information it cannot return, the worker has no opportunity to fix the plan unless the implementation adds replanning. ReWOO’s solver can sometimes compensate, but only after the evidence has already been collected. Xu et al. explicitly observe cases where ReWOO assumes a retrieved page contains a fact, then later extraction fails because the fact was absent. arXiv
2. ReWOO is weak in highly uncertain environments
The paper’s own limitation section uses an AlfWorld-style embodied task: the agent must find a vase in an environment where it does not know which container holds it. Without observations, the planner may have to enumerate many possible locations. Xu et al. note that in such cases, the number of planner steps can approach the worst-case complexity of observation-dependent reasoning. arXiv
This is the core reason ReAct remains relevant. If the world state is unknown and must be discovered through interaction, observations are not pollution; they are the task.
3. It cannot adapt mid-task without extra machinery
Pure ReWOO has no native “observe → revise plan” loop. That is acceptable for stable information-gathering workflows, but risky for live web tasks, API workflows with unexpected errors, code execution, negotiation, robotics, or tasks where tool results change the objective. Production systems often add a replanner, validator, or fallback ReAct loop, turning pure ReWOO into a hybrid.
4. Tool overload still hurts
Xu et al. found that adding extraneous tools can reduce ALM performance. In a HotpotQA ablation, performance degraded as irrelevant tools were added; their qualitative analysis found tool misuse such as using Yelp to search for a celebrity. ReWOO does not magically solve tool selection. It makes tool selection explicit, which helps debugging, but a bad tool menu still confuses the planner. arXiv
5. The empirical scope is limited
The paper’s experiments are mostly QA, math, science, and curated document tasks. Those are useful but not definitive for production agents. The evidence is strongest for predictable multi-step reasoning with tool calls, not for open-ended autonomous work. The comparison against ReAct is meaningful, but it does not settle the architecture question for agents that operate over hours, modify files, browse changing websites, or interact with humans.
ReWOO as “compile-time reasoning”
A helpful mental model is:
ReAct = interpreted agent loopReWOO = compiled agent workflowLLMCompiler = dependency-aware compiled workflow with scheduling
ReAct interprets the task step by step. ReWOO compiles the task into an execution plan. LLMCompiler extends the compiler analogy by scheduling function calls and exploiting parallelism. Proceedings of Machine Learning Research
This analogy clarifies the tradeoff. Compilers are fast when the program is well specified. Interpreters are flexible when the environment is uncertain. A ReWOO-style plan is efficient when tool dependencies are foreseeable. A ReAct loop is safer when each action reveals information that materially changes the next action.
Engineering implications
For AI Engineering, ReWOO suggests several design practices:
| Design practice | ReWOO lesson |
|---|---|
| Emit explicit plans | Make the model’s intended workflow available before execution |
| Use variables and dependencies | Treat tool outputs as typed dataflow nodes, not transcript text |
| Separate planner and solver prompts | Planning and synthesis are different jobs |
| Validate plans before execution | Catch missing dependencies, unavailable tools, unsafe actions |
| Cache recurring plan skeletons | Reuse stable decompositions across similar tasks |
| Parallelize independent nodes | Use dependency analysis where possible |
| Add replanning for uncertainty | Do not force ReWOO on exploratory tasks |
| Measure token, latency, and accuracy separately | Lower cost is not automatically better behavior |
The most production-relevant version of ReWOO is probably not the literal paper prompt. It is the pattern: plan first, bind tool results into variables, solve later, and replan only when necessary.
Open question: plan-first or interleaved reasoning?
There is no settled dominant architecture. The literature and frameworks point toward hybrids rather than a single winner. Surveys of LLM-based autonomous agents distinguish planning without feedback from planning with feedback, and note that planning without feedback is simpler but better suited to shorter or more predictable tasks, while planning with feedback is more capable for complex long-range tasks. arXiv
Plan-first approaches are likely to dominate where tasks have stable structure: report generation, multi-source research with known sources, ETL-style workflows, document QA, batch API calls, compliance prechecks, and cost-sensitive automation. Their advantages are inspectability, lower repeated context, easier caching, and easier orchestration.
Interleaved approaches are likely to dominate where tasks are exploratory: web navigation, debugging, coding with unknown errors, robotics, games, live operations, and adversarial or changing environments. Their advantage is adaptation. ReAct’s original motivation was precisely that reasoning traces help update plans and handle exceptions while actions gather new information. arXiv
The probable long-term pattern is hierarchical control:
Planner creates a coarse plan → Static subtasks run ReWOO/LLMCompiler-style → Uncertain subtasks run ReAct-style → Verifier checks results → Replanner handles failures → Solver synthesizes final output
That hybrid preserves ReWOO’s separation of concerns without pretending that all reasoning can happen before observation. In other words, ReWOO is less likely to replace ReAct than to become one of the control-flow primitives inside larger Agent Orchestration systems.
References
Xu et al. 2023 — ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models. Primary paper introducing planner-worker-solver ReWOO, token-efficiency experiments, tool-failure analysis, and planner specialization. arXiv
Yao et al. 2023 — ReAct: Synergizing Reasoning and Acting in Language Models. Primary comparison point for interleaved thought-action-observation agents. arXiv
Wang et al. 2023 — Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. Relevant predecessor for explicit plan-then-solve reasoning. ACL Anthology
Mialon et al. 2023 — Augmented Language Models: a Survey. Survey framing augmented language models as systems combining reasoning and tool use. arXiv
Schick et al. 2023 — Toolformer: Language Models Can Teach Themselves to Use Tools. Related tool-use work on training models to decide when and how to call APIs. arXiv
Press et al. 2023 — Measuring and Narrowing the Compositionality Gap in Language Models. Introduces Self-Ask, a structured decomposition method that can plug in search. arXiv
Kim et al. 2024 — An LLM Compiler for Parallel Function Calling. Compiler-style successor pattern emphasizing dependency-aware parallel function execution. Proceedings of Machine Learning Research
LangChain Engineering — Plan-and-Execute Agents. Engineering comparison of plan-and-execute, ReWOO, and LLMCompiler patterns. LangChain
Wang et al. 2024 — A Survey on Large Language Model based Autonomous Agents. Survey taxonomy for agent planning modules, including planning with and without feedback. arXiv
Companion entries
Core theory: Tool-Augmented LLMs, Augmented Language Models, Separation of Concerns, Prompt Redundancy, Reasoning Traces, Observation-Dependent Reasoning
Agent architectures: ReAct Agents, Plan-and-Execute Agents, LLMCompiler, Agent Workflow Graph, Modular Agent Architecture, Agent Orchestration
Practice: Typed Tool Interfaces, Planner-Executor-Solver Pattern, Human-in-the-Loop Agents, Tool Reliability, Retrieval-Augmented Generation, Prompt Efficiency
Evaluation: Agent Evaluation, Token Cost Benchmarks, Tool-Failure Robustness, Long-Horizon Planning, Plan Validation
Counterarguments and open questions: Plan-First vs Reactive Agents, When Observations Improve Reasoning, Brittleness of Upfront Planning, Hybrid Agent Control Loops, Self-Improving Systems