ReAct vs ReWOO: reasoning without observation

When you wire an LLM to external tools, the control loop determines your latency, your token spend, and your failure modes. ReAct vs ReWOO is the decision between interleaving reasoning with live observations and drafting a full action plan before touching any tool. Both patterns solve the same problem—letting a model delegate to APIs—but they make opposite tradeoffs on context size and round-trips.

How the loops actually work

ReAct: thought, action, observation

ReAct prompts the model to emit a reasoning trace, then an action (tool call), then waits for the environment to return an observation. The observation is fed back into the same context, and the model decides the next step. The original paper used a specific prompt format; in practice you enforce it with a JSON mode or a regex parser.

# Minimal ReAct step loop
messages = [system_prompt, user_task]
while not done:
    resp = llm.chat(messages)
    thought, action = parse(resp)
    if action is None:
        break
    obs = tool_registry[action.name](**action.args)
    messages.append(assistant_msg(resp))
    messages.append(system_msg(f"Observation: {obs}"))

The model sees every intermediate result. That is powerful for branching logic but multiplies input tokens linearly with the number of steps. If a search returns ten documents, all ten sit in context for every remaining decision.

ReWOO: plan, then execute blind

ReWOO (Reasoning WithOut Observation) splits the process into two phases. A planner model emits a sequence of dependent tool calls with placeholders. An executor fills them in order, substituting previous outputs into later calls. The model never sees intermediate results during planning.

{
  "plan": [
    {"id": "p1", "tool": "search", "args": {"q": "population of France"}},
    {"id": "p2", "tool": "calc", "args": {"expr": "#p1 * 0.2"}}
  ]
}

The executor runs p1, captures the string, then runs p2 with the substitution. Only the final answer requires a second model call (if at all). The planner must anticipate the shape of p1’s output—if it returns a paragraph, #p1 * 0.2 will error. Production ReWOO adds schema hints to the planner prompt.

Head-to-head dimensions

Capabilities

ReAct handles reactive paths: if a search returns garbage, the next thought can pivot to a different query. ReWOO assumes the plan is correct; if p1 fails, the executor must either abort or have hardcoded retry logic. ReWOO excels when the dependency graph is known and tools are reliable. ReAct vs ReWOO thus splits on dynamic vs static control flow. ReAct is a turing-complete loop; ReWOO is a DAG. Need to chain three APIs with error handling? ReAct writes the try/catch in natural language; ReWOO needs you to code it.

Cost model

ReAct pays for the full conversation history on every step. A 10-step task with 500-token observations costs roughly 10× the input of the first step. ReWOO pays once for the plan, once for execution (often no model), and once for synthesis. If you route through a gateway like n4n.ai, per-token metering makes the ReAct multiplier visible as a line item, and automatic fallback hides provider rate limits without changing the loop.

ReWOO’s cost is dominated by the planner call. For cheap tools and expensive context, ReWOO wins. For sparse steps with large outputs, ReAct’s repeated context may still be acceptable because you only pay for what you resend. For a task with S steps, average observation size O tokens, and prompt prefix P, ReAct input tokens ≈ S*(P + S*O/2). ReWOO input ≈ P + plan_size + final_context. The quadratic term is what kills ReAct at scale.

Latency and throughput

ReAct is serial: step time = model latency + tool latency, repeated. ReWOO’s planner call can be done ahead of execution, and independent plan nodes could be parallelized (though most reference impls run serial). ReWOO reduces model round-trips from N to 1–2, cutting tail latency significantly when the model is the bottleneck. Under load, ReAct’s many calls amplify queue wait; ReWOO batches the thinking. ReAct can stream thoughts to the user; ReWOO appears frozen during planning.

Ergonomics

ReAct is easy to debug: you read the thought trace. ReWOO hides the middle; you must log executor substitutions separately. Authoring ReWOO prompts requires teaching the model a strict placeholder syntax. ReAct works with any chat model and a simple parser. ReWOO needs a validator that checks plan IDs resolve and types match. In our codebase, ReWOO planning prompts are twice as long as ReAct’s because of the grammar examples.

Ecosystem

ReAct is the default in LangChain, AutoGPT, and most agent tutorials. ReWOO is less common but appears in research code and some production planners. Both are model-agnostic; neither needs fine-tuning. You can swap a ReAct agent from GPT-4o to a local Llama by changing one line; same for ReWOO.

Limits

ReAct blows up context windows on long tasks. ReWOO cannot recover from a bad plan without a full replan. ReWOO also struggles when a later step’s arguments cannot be expressed without seeing earlier output (e.g., “use the first link from the search results” requires the planner to know search returns a list—possible with schema, but brittle). ReAct’s limit is cost; ReWOO’s limit is rigidity.

Comparison table

Which to choose

Use ReAct when your task has conditional branches, you need the model to react to unexpected tool output, or you are prototyping and want the fastest path to a working agent. Examples: customer support triage, exploratory data analysis, anything where the next action depends on a human-readable intermediate. If you expect to iterate on prompts weekly, ReAct’s transparency saves engineering hours.

Use ReWOO when the tool chain is deterministic, latency or token cost dominates, and you can express dependencies as variable substitution. Examples: ETL-style enrichment (lookup → format → store), batch report generation, or high-volume inference where you pre-plan 10k jobs and execute with a cheap worker. In a recent pipeline we cut token spend 4× by moving from ReAct to ReWOO for a fixed 5-step enrich.

Hybrid: Plan with ReWOO, execute with a ReAct supervisor that only engages if a node fails. This captures most of the cost save without losing recovery. Implement the supervisor as a fallback: if executor raises, hand the plan and error to a ReAct loop for one recovery step.

If you are serving both patterns behind one endpoint, keep the loop logic in your app and let the gateway handle provider routing. That way ReAct vs ReWOO becomes a config flag, not a rewrite.