Agent Pattern

Plan & Execute

LLM creates a full plan upfront, then executes each step sequentially.

Intermediate Evolves from: Orchestrator-Worker

Plan & Execute — Overview

Plan & Execute separates work into two distinct phases: first, the LLM generates an explicit plan (a sequence of steps); then, it executes each step using tools, with the option to replan if a step fails or new information changes the strategy.

Evolves from: Orchestrator-Worker — adds LLM-generated plans, step tracking, and replanning on failure.

Architecture

graph TD Input([User Task]) -->|"complex goal"| Planner[Planner LLM:<br/>Generate step plan] Planner -->|"plan: steps[]"| Tracker[Step Tracker] Tracker -->|"next step"| Executor[Executor LLM:<br/>Execute with tools] Executor -->|"step result"| Check{Step succeeded?} Check -->|"Yes"| Tracker Check -->|"No"| Replan{Replan?} Replan -->|"Yes"| Planner Replan -->|"No — give up"| Fail([Failure]) Tracker -->|"all steps done"| Synth[Synthesizer:<br/>Merge results] Synth -->|"final output"| Output([Output]) style Input fill:#e3f2fd style Planner fill:#fff8e1 style Tracker fill:#f3e5f5 style Executor fill:#fff3e0 style Check fill:#fce4ec style Replan fill:#fce4ec style Synth fill:#e8f5e9 style Output fill:#e3f2fd style Fail fill:#ffcdd2

Figure: The planner generates a step sequence, the executor processes each step with tools, and a tracker monitors progress. Failed steps trigger replanning.

How It Works

  1. Plan — The planner LLM receives the task and generates a structured plan: an ordered list of steps, each with a description and expected outcome.
  2. Track — A step tracker maintains plan state: which steps are pending, in-progress, completed, or failed.
  3. Execute — For each step, the executor LLM runs a bounded ReAct-style loop with tools. Each step has its own iteration budget.
  4. Evaluate — After each step, check whether it succeeded. If not, decide whether to retry, skip, or replan.
  5. Replan — If a step fails or reveals that the plan is wrong, return to the planner with updated context. The planner generates a revised plan.
  6. Synthesize — Once all steps are complete, merge the results into a final output.

Minimal Example

Scaffold a new Python project — the plan is fixed upfront, then each step executes in order.

from patterns.plan_and_execute.code.python.plan_and_execute import PlanAndExecute

agent = PlanAndExecute(
    planner=your_llm,
    executor=your_llm,
    tools={"run_command": lambda cmd: subprocess.check_output(cmd, shell=True, text=True)},
    replan_on_failure=True,    # revise remaining steps if one fails
)

result = agent.run(
    "Set up a Python REST API project: "
    "create directory structure, install dependencies, write a Dockerfile, and generate a README"
)
# result.plan           → the full ordered plan created before any execution started
# result.plan[i].status → "done" | "failed" for each step
# result.replanned      → True if a failure triggered replanning of remaining steps
# result.final_output   → output of the last completed step

The plan created upfront might look like:

Step 1: Create project directory structure (tool: run_command)
Step 2: Initialize a virtual environment and install FastAPI, uvicorn (tool: run_command)
Step 3: Write a minimal main.py with a health-check endpoint
Step 4: Write a Dockerfile for the project
Step 5: Generate a README.md documenting setup and usage

Full implementation: [`code/python/plan_and_execute.py`](code/python/plan_and_execute.py)

Input / Output

  • Input: A complex task that benefits from upfront strategic planning
  • Output: A synthesized result after executing all plan steps
  • Plan: Structured list of steps with descriptions and expected outputs
  • Step result: Individual output from each executed step

Key Tradeoffs

Strength Limitation
Strategic — plans before acting Planning overhead for simple tasks
Tracks progress explicitly Plan quality determines execution quality
Can recover from failures via replanning Replanning is expensive (resets context)
Bounded execution per step Rigid step boundaries may not suit fluid tasks
Clear audit trail of plan + execution Two-phase latency (plan + execute)

When to Use

  • Complex, multi-step tasks where order matters
  • Tasks where you want an explicit, inspectable strategy before execution
  • When failure recovery and replanning are important
  • Long-running tasks that benefit from progress tracking
  • Tasks where the user wants to review or approve the plan before execution

When NOT to Use

  • Simple tasks with fewer than 3 steps — use ReAct
  • When steps are known at design time — use Orchestrator-Worker
  • When the task is exploratory with no clear end goal — use ReAct
  • When each step needs deep specialization — use Multi-Agent

Deeper Dive

  • Design — Plan schema, step tracking, replanning strategies, executor design
  • Implementation — Pseudocode, planner prompts, state management, testing
  • Evolution — How Plan & Execute evolves from orchestrator-worker