ReWOO and Plan-and-Execute

In plain words

Before a placement drive, you can either check one company, think, check the next, think again, carrying all old notes each time. Or you can write the full checklist first and then just collect the facts. ReWOO is the second way for agents: one planner call writes the whole plan, cheap workers fetch evidence, and one solver call writes the answer.

How it flows

A tiny example

steps = plan(question)          # one model call, no tool outputs seen
evidence = {}
for label, tool, arg in steps:
    arg = fill_refs(arg, evidence)  # #E1 becomes an earlier result
    evidence[label] = run_tool(tool, arg)
answer = solve(question, steps, evidence)   # one more model call

Notice the model is used only twice, at plan time and at solve time, however many tools run in between.

What you will learn

• Why an agent that thinks after every tool call becomes slow and costly.
• How ReWOO splits the work into Planner, Workers and Solver.
• How to write a plan as a small dependency graph and run it in order.
• When to plan first, and when to stay reactive.

The problem, simply

Think about a placement drive at your college. Suppose Priya has to prepare a company shortlist. She could do it two ways.

Way one: she opens one company page, thinks "hmm, what next", opens the next, thinks again, and re-reads all her old notes every single time. By the tenth company she is carrying ten pages in her head just to take one small decision.

Way two: she writes the full checklist first. CGPA cutoff, role, package, location. Then she just collects those four facts and decides once at the end.

An agent has the same choice. In the ReAct style (think, act, observe, repeat), every step carries all the earlier thoughts and observations in the prompt. Total tokens grow roughly with the square of the number of steps. Ten steps costs far more than ten times one step.

And if a tool fails halfway, the agent must reason its way out of the error mid-stream, with the original goal buried under old text.

The idea

Reasoning without observations

ReWOO means "reasoning without observations". Plain meaning: the part that plans never sees tool outputs at all. It only sees your question.

That one restriction is the whole trick. If the planner does not need observations, it can write the entire plan in one shot, before any tool runs.

The three roles

There are exactly three parts.

Planner. Takes your question, returns a small list of steps. Each step names a tool and its argument.

Workers. Boring executors. Each runs one tool call and returns a string. No thinking, so independent workers can run at the same time.

Solver. Sees the question, the plan and all the evidence. Writes the final answer once.

The #E1 trick

A plan is not always a straight line. Step 2 may need the result of step 1.

So the planner writes placeholders. Step 1 stores its result as #E1. Step 2 can then say "find the population of #E1", and the executor swaps in whatever step 1 actually returned.

Because steps declare their dependencies, the plan is a small graph with no cycles. The executor runs it in dependency order, and steps that depend on nothing can run in parallel.

A worked example

Suppose Rahul asks the agent: "What is the population of the capital of France, in millions?"

The planner writes, in one call:

• Step 1: lookup("capital of France"), stored as #E1.
• Step 2: population(#E1), stored as #E2.
• Step 3: round_to_millions(#E2), stored as #E3.

Step 1 gives "Paris", so step 2 actually calls population("Paris"). The solver reads the evidence and says "about 2 million".

Two model calls total, no matter how many tools ran in between. On HotpotQA (a test set where you must combine two facts to answer one question), the original work reported about five times fewer tokens than ReAct, and four points better accuracy.

IMP

Note: Fewer model calls also means fewer chances for the model to drift off the goal. Cost is only half the benefit.

Failures stay in one place

Say the population tool times out. In ReAct that error lands in the middle of the thinking stream and the model must recover live.

In ReWOO, that worker just returns an error string. The solver sees the full plan plus "step 2 failed", so it can answer partially or say clearly what is missing. Damage stays inside one node.

IMPRemember: ReWOO trades flexibility for cost and clarity. The plan is fixed before anything runs, so if reality surprises you mid-way, plain ReWOO cannot change its mind.

Small planner, big solver

Since the planner never sees observations, its job is narrow and repeatable. So you can take plans written by a very large model and fine-tune a small one (around 7 billion parameters) to write the same kind of plans. The small model then handles planning, and the big model is not needed for that part.

The cousins: Plan-and-Execute and Plan-and-Act

Plan-and-Execute is ReWOO plus a replanner. Run some steps, look at the results, and if things went sideways, rewrite the rest of the plan. You give back a little token saving for flexibility.

Plan-and-Act pushes the same idea to long jobs: web and mobile agents running past thirty or fifty steps, like filling forms across many pages. Its contribution is training data where the plan is written out explicitly, so the planner stays coherent over a long run.

Which one to pick

• Short task, unknown environment, surprises expected: ReAct.
• Known tools, structured task, cost matters: ReWOO.
• Same as ReWOO but surprises expected: Plan-and-Execute.
• Thirty-plus steps of browser or app navigation: Plan-and-Act.

Tip

Tip: Start with the simplest thing that works. If the job is one tool call and a summary, do not build a planner for it.

Build it

"""Toy ReWOO: Planner -> Workers -> Solver. Standard library only."""
import re

# ---- Fake tools. In real life these hit APIs or a database. ----
FACTS = {"capital of France": "Paris", "Paris": "2140000"}

def lookup(arg):        return FACTS.get(arg, "not found")
def population(arg):    return FACTS.get(arg, "not found")
def to_millions(arg):
    return "about %.1f million" % (int(arg) / 1_000_000) if arg.isdigit() else "unknown"

TOOLS = {"lookup": lookup, "population": population, "to_millions": to_millions}

# ---- Planner: one call, no observations. Here it is scripted. ----
def plan(question):
    """Returns a list of (label, tool, argument). #E1 style refs allowed."""
    if "population" in question and "capital" in question:
        return [("#E1", "lookup",     "capital of France"),
                ("#E2", "population", "#E1"),
                ("#E3", "to_millions", "#E2")]
    return [("#E1", "lookup", question)]

# ---- Workers: run each node, substituting earlier results. ----
def run_workers(steps):
    evidence = {}
    for label, tool, arg in steps:
        # replace every #En placeholder with what that worker returned
        real_arg = re.sub(r"#E\d+", lambda m: evidence.get(m.group(0), ""), arg)
        try:
            fn = TOOLS[tool]
            evidence[label] = fn(real_arg)
        except Exception as err:                 # failure stays inside one node
            evidence[label] = "ERROR: %s" % err
        print("  %s = %s(%r) -> %s" % (label, tool, real_arg, evidence[label]))
    return evidence

# ---- Solver: sees question + plan + evidence, answers once. ----
def solve(question, steps, evidence):
    last = steps[-1][0]
    if str(evidence.get(last, "")).startswith("ERROR"):
        return "Could not finish. Failed at %s." % last
    return "Q: %s\nA: %s" % (question, evidence[last])

if __name__ == "__main__":
    q = "What is the population of the capital of France, in millions?"
    steps = plan(q)                      # 1 planner call
    print("PLAN:")
    for s in steps:
        print("  %s: %s(%r)" % s)
    print("WORKERS:")
    ev = run_workers(steps)              # N cheap tool calls, no model
    print("SOLVER:")
    print(solve(q, steps, ev))           # 1 solver call

Look at the output in three blocks. The whole plan prints before any tool runs, which is the ReWOO promise. Then watch #E1 turn into Paris in the second worker line. Only the solver stitches things together, so a real model would have been called just twice.

Where you will see this

• Coding agents like Claude Code and Cursor, laying out an edit plan for several files before touching any of them.
• Deep-research modes in ChatGPT-style products, which pick sources up front and then write one report.
• Support bots that fetch order status, refund policy and payment status in parallel, then compose one reply.
• A Swiggy or Zomato style assistant checking restaurant, offers and delivery time together.
• Cost-sensitive internal tools, where every extra model call is real money at scale.

Common mistakes

• Using ReWOO for a one-step job. Two model calls to do what one could. Extra machinery, worse latency, no benefit.
• Letting the planner peek at tool outputs. Once observations enter the planning prompt you are back to ReAct costs, and the small-planner benefit is gone.
• Not validating the plan. Check that every tool exists, every #E points to an earlier step, and there is no cycle. A bad plan silently produces garbage evidence.
• Crashing the run on one tool error. Catch it inside the worker and pass the error string forward. The solver can often still answer.
• Assuming plans are straight lines. Ignore dependencies and a step may run with a placeholder that is still empty.

If they ask in an interview

Q: What is the difference between ReAct and ReWOO?

A: ReAct interleaves thinking and acting, so every step re-reads all earlier thoughts and observations and the prompt grows quadratically. ReWOO plans up front with a planner that never sees observations, runs cheap workers, then solves in one more call. You trade mid-run flexibility for far fewer tokens and cleaner failures.

Q: Why can a small model be used as the ReWOO planner?

A: Its input is only the question and the tool list, never the messy outputs. That makes the task narrow and consistent, so plans from a large model can fine-tune a small one that keeps up. The heavy model is then needed only for reasoning over evidence.

Q: When would you not use ReWOO?

A: When the environment is unpredictable and you must react to what you find, like debugging an unfamiliar system. A fixed plan cannot adapt there, so I would use ReAct, or Plan-and-Execute, which replans after partial execution.

Try these

1. Add a fourth tool and two steps that do not depend on each other. Print which steps could have run in parallel.
2. Make one tool raise an exception. Confirm the solver still gives a sensible partial answer instead of blowing up.
3. Write a validate(steps) function that rejects an unknown tool, a forward reference, or a duplicate label.
4. Add a tiny replanner: if any evidence starts with ERROR, rebuild the remaining steps once and re-run. That one change turns ReWOO into Plan-and-Execute.

Words, simply

Quick recap

• ReAct re-reads its own history at every step, so cost grows fast and errors land mid-thought.
• ReWOO splits the job into Planner, Workers and Solver: roughly five times fewer tokens, and failures stay in one node.
• A fixed plan cannot adapt, so add a replanner when the world can surprise you.