Decide all the tool calls in one planning pass, execute them without stopping to reason after each result, then synthesize the answer in a final pass.
ConceptWhat it is
ReWOO — short for Reasoning WithOut Observation — is a plan-then-execute agent pattern that separates thinking from doing. Instead of the interleaved loop of ReAct, where the model reasons, calls one tool, reads the result, and reasons again for every single step, ReWOO asks the model to lay out the entire plan of tool calls in one pass. Each planned step names the tool, its arguments, and an evidence variable (for example E1, E2) that later steps can reference before any tool has actually run.
The pattern exists to cut cost and latency. In ReAct, every observation is fed back into a growing prompt and triggers another expensive LLM call, so a five-step task means five or more model invocations over ever-longer context. ReWOO splits the work across three roles — a Planner that writes the whole blueprint once, a Worker that runs the tools to fill in the evidence, and a Solver that reads the plan plus all gathered evidence and composes the final answer. The model is invoked about twice regardless of how many tools run, and independent steps can execute in parallel.
How it worksThe mechanics
A task arrives and the Planner produces a full, ordered blueprint in one LLM call — a list of steps, each binding a tool call to an evidence variable, with later steps allowed to reference earlier variables as placeholders. The Worker then walks the blueprint deterministically, executing each tool (search, retrieval, calculator, API) and substituting the real results into the evidence slots; steps that do not depend on one another can be dispatched concurrently. Once every variable is filled, the Solver takes the original task, the plan, and the complete evidence set and generates the answer in a second LLM call. No model reasoning happens between tool executions, which is exactly why the bulky observations never re-enter the prompt.
At a glanceSee it
How ReWOO still chains dependent steps without an observation loop — a later step's arguments are placeholder variables that get spliced with an earlier step's evidence before its tool runs, so one upfront plan can encode a whole dependency chain.
Why the no-loop design pays off — ReAct re-sends the full tool spec and the whole growing observation history on every step, while ReWOO pays for tool descriptions once at plan time and feeds the solver only the evidence.
When to use itWhere it fits
- Tasks that decompose cleanly upfront — the needed tool calls are knowable before you see any results
- High-volume or latency-sensitive workloads where trimming LLM calls and token spend materially matters
- Pipelines with independent sub-queries that benefit from parallel tool execution
- Settings where you want an auditable, inspectable plan before anything runs
When NOT to use itLimits & anti-patterns
- Exploratory or branching problems where each result reshapes what to do next
- Long-horizon tasks that need mid-course correction or recovery when a tool returns something unexpected
- When a wrong early assumption would silently propagate through the whole plan to a confident-but-wrong answer
- Interactive agents that must react to real-time feedback from a user or a changing environment
Trade-offsAdvantages & costs
Advantages
- Token-efficientobservations are not fed back through the model at each step, so context stays small
- Fewer LLM callsroughly plan-once plus solve-once — which lowers cost and often latency
- Independent steps parallelize, shrinking wall-clock time
- The explicit plan is transparent and reviewable before execution, aiding debugging and governance
Trade-offs & costs
- No mid-course correction — the plan is fixed once written, so surprises in tool output cannot redirect it
- Quality hinges entirely on the Planner's foresight; a flawed plan runs to completion and still yields an answer
- Poor fit for tasks whose next step genuinely depends on the content of the previous result
- Needs engineering for variable substitution, dependency ordering, and tool-failure handling that ReAct gets for free from its loop
ExampleIn the real world
Consider a research assistant asked, "Which of these three vendors has the lowest published price, and what is that in euros?" The Planner emits a blueprint in one pass: E1 = look up vendor A price, E2 = look up vendor B price, E3 = look up vendor C price, E4 = fetch the current dollar-to-euro rate, then Solve = compare E1, E2, E3 and convert the minimum using E4. The Worker fires the three price lookups and the rate lookup concurrently — none depends on another — and fills in the evidence. The Solver then reads the plan and the four results and returns the cheapest vendor with its euro price. Four tool calls ran, yet the model was invoked only twice.
ToolsHow to implement it
- LangGraph — its documentation includes an official ReWOO how-to that wires Planner, Worker, and Solver as graph nodes
- The original ReWOO reference implementation (Xu et al., 2023) released alongside the paper
- Any planner-executor orchestration framework (for example custom LangChain chains) can express the Planner-Worker-Solver split directly
Cost & effortWhat it takes
ReWOO's headline saving is call count: it uses on the order of two LLM invocations — one to plan, one to solve — no matter how many tool steps execute, versus ReAct's one invocation per step over a prompt that grows with every observation. That makes it markedly cheaper in tokens and often faster, especially when independent steps run in parallel. The engineering cost moves elsewhere: you must design a reliable plan format with evidence-variable substitution, resolve step dependencies, and handle tool failures explicitly, since there is no reasoning loop to catch and recover from a bad result. Budget effort for validating plan quality, because the pattern trades adaptability for efficiency.