Plan-and-Execute

Agent Architectures covers ReAct — reason, act, observe, one step at a time. Plan-and-execute inverts the order: think through the whole task before acting on any of it, then execute the resulting plan with far less per-step reasoning.

Think of the difference between planning a road trip turn-by-turn as you drive versus mapping the whole route before leaving the driveway. ReAct is the first: figure out the next move, do it, see what happened, figure out the next move again — useful when the road might be closed and you won't know until you get there. Plan-and-execute is the second: work out the whole route up front, then just follow it — much less thinking per mile, as long as the roads are actually open the way you expected. The "replanner" is what happens when you hit a detour anyway: it doesn't throw out the whole trip, it just re-routes from where you actually are.

The Architecture

Three real components, matching how LangChain describes the pattern, which traces back to earlier work like Plan-and-Solve prompting and BabyAGI:

Planner — one LLM call that reasons about the entire task and produces a full multi-step plan upfront, not one step at a time.
Executor — runs each step in the plan. Each step is "the user's query and a step in the plan," invoking whatever tools that step needs — a much smaller prompt than re-reasoning about the whole task, and cheap enough to hand off to a smaller model.
Replanner — after execution, decides whether to finish with a response or generate a follow-up plan, based on what actually happened during execution (not just what was planned).

1 / 6

1.Search Company A pricing page

2.Search Company B pricing page

3.Search Company C pricing page

4.Synthesize into a comparison table

Planner

Planner produces the full multi-step plan upfront -- one LLM call reasons about the whole task, not one call per step.

Step through the trace above: two steps run exactly as planned with zero re-planning, then a third step fails against reality (a dead page), and the replanner does something a fixed plan can't — it revises based on what the failure actually was, rather than blindly retrying the same broken step or giving up.

Run the Control Loop For Real

A real planner/replanner is an LLM call — not something to fake in a browser sandbox. What is real and runnable here is the orchestration loop itself: given any planner's output and any replanner's decision, exactly how does the loop advance, splice in a fix, and keep going? Below, execute_step and replan are deterministic stand-ins (so the whole trace is reproducible) for what would otherwise be tool calls and an LLM call — but run_plan, the actual control flow being demonstrated, is the real thing, unsimplified:

Run it yourself

def execute_step(step):
  # Deterministic mock "tool call" -- step 3 is the dead page from the
  # diagram's trace above.
  if step == "fetch https://old-blog.example/post-42":
      return {"ok": False, "reason": "404 Not Found"}
  return {"ok": True, "result": f"done: {step}"}

def replan(original_plan, failed_index, failure):
  # A fixed lookup standing in for what would be an LLM call in a real
  # system -- deterministic here so the loop's behavior is reproducible.
  if "old-blog.example" in original_plan[failed_index]:
      return ["fetch https://web.archive.org/web/2023/old-blog.example/post-42"]
  return []  # no fix available -> give up on this step

def run_plan(plan, execute_step, replan):
  """The real orchestration loop: execute each step in order; on
  failure, ask the replanner for replacement step(s), splice them in
  right after the failed step, and keep going."""
  steps = list(plan)
  results = []
  i = 0
  while i < len(steps):
      step = steps[i]
      outcome = execute_step(step)
      results.append((step, outcome["ok"]))
      if not outcome["ok"]:
          steps[i + 1:i + 1] = replan(plan, i, outcome)
      i += 1
  return results

plan = ["search source A", "search source B", "fetch https://old-blog.example/post-42"]
results = run_plan(plan, execute_step, replan)

print("Executing plan:")
for step, ok in results:
  print(f"  [{'OK' if ok else 'FAILED'}] {step}")

replan_calls = sum(1 for _, ok in results if not ok)
task_completed = results[-1][1]  # did the LAST attempt at each position succeed
print(f"\nReplanner invoked: {replan_calls} time(s)")
print(f"Every individual attempt succeeded: {all(ok for _, ok in results)}",
    "(False is correct here -- the original dead-page fetch is honestly",
    "recorded as a failure, not silently dropped from the trace)")
print(f"Task ultimately completed (last attempt succeeded): {task_completed}")

# Try changing execute_step so a second step also fails, or make replan()
# return an empty list (give up) instead of a fix -- watch how run_plan's
# behavior changes without changing run_plan itself at all.

Implement the Orchestration Loop Yourself

execute_step and replan are given below, fixed and deterministic, matching the trace above exactly. The tests check the real control-flow behavior: does a failed step get recorded as failed (not silently dropped), does its replacement get spliced in right after it, and does execution continue.

Implement it yourself

assert len(run_plan(plan, execute_step, replan)) == 4
assert run_plan(plan, execute_step, replan)[0] == ("search source A", True)
assert run_plan(plan, execute_step, replan)[2] == ("fetch https://old-blog.example/post-42", False)
assert run_plan(plan, execute_step, replan)[3] == ("fetch https://web.archive.org/web/2023/old-blog.example/post-42", True)

Why It's Often More Efficient Than ReAct

LangChain's own framing of the tradeoff names three real advantages of separating planning from execution:

Speed — no LLM call is needed after every single tool invocation; a step that doesn't need re-reasoning just runs.
Cost — "smaller, domain-specific models" can execute individual steps, reserving the larger (and more expensive) model specifically for the planning call that needs the most reasoning.
Quality — forcing one call to reason through the entire problem space upfront, chain-of-thought style, produces more coherent multi-step plans than reasoning about each step in isolation without seeing the whole shape of the task first.

Where It Loses to ReAct

The tradeoff runs the other way for tasks that genuinely need per-step adaptation: a plan committed to upfront is exactly the wrong structure when each step's result changes what the next step should even be, not just whether it succeeded. ReAct's interleaved reason-act-observe cycle handles that naturally; plan-and-execute has to detour through the replanner every time, which is slower than never having committed to a rigid plan in the first place.

The basic version also has a real, named limitation: it's "still restricted by serial tool calling" and "doesn't support variable assignment" between steps — later frameworks (LLMCompiler and similar DAG-based approaches) address this by letting independent steps run in parallel and by passing structured values between steps instead of only natural-language results, but that's beyond what the basic planner/executor/replanner pattern itself provides.

When to Reach for It

Predictable-structure tasks — the ones where you could sketch the steps yourself before starting — are the actual fit: "search three specific sources and synthesize a comparison" has a shape you already know; "debug this failing test" doesn't, since what to do next depends entirely on what the previous step revealed. The general rule from Agent Architectures still applies: reach for structure once managing a plain loop by hand gets error-prone, not by default.

References

LangChain, "Plan-and-Execute Agents" — the architecture description, efficiency reasoning, and named limitation cited above.
Wang et al., "Plan-and-Solve Prompting" — arXiv:2305.04091, cited prior work on separating planning from execution in a single prompt.
Loops and Graphs — the general loop/graph framing this pattern is one concrete instance of; the replanner here is functionally a gate deciding whether to loop back or finish.

Next: Reflection / Self-Critique — a different axis entirely: not how many steps ahead to plan, but whether the agent checks its own work.