Planner-Executor

Phase 10 · Document 03 · Agents and Tools Prev: 02 — JSON Schema and Structured Output · Up: Phase 10 Index

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

The bare agent loop (01) handles one step at a time, but real tasks ("research three competitors and write a comparison") need decomposition, sequencing, and recovery. Agent architectures — ReAct, plan-and-execute, reflection, and multi-agent — are the patterns for how the model organizes multi-step work. Choosing the right one (and not over-engineering) is what separates an agent that reliably completes complex tasks from one that wanders, loops, or stalls. Since per-step reliability compounds (Phase 5.06, 00), the architecture's job is to keep the agent on track and recoverable across many steps — and the senior lesson echoes 00: use the simplest architecture that works.

2. Core Concept

Plain-English primer: how the model organizes multi-step work

The question this doc answers: given tools and a loop, how does the agent decide the sequence of actions? Four patterns, simplest → most complex:

1. ReAct (Reason + Act) — the default loop. The model interleaves reasoning and action: think ("I need the population, I'll search") → act (tool_use) → observe (tool_result) → think → act … until done. This is the standard agent loop (01); the "plan" is implicit and dynamic, re-decided each step from the latest observation. Flexible and robust to surprises; can wander on long tasks without guardrails.

ReAct:  thought → action → observation → thought → action → … → answer   (re-plan every step)

2. Plan-and-Execute — plan first, then do. The model writes an explicit plan (a list of sub-tasks) up front, then an executor carries out each step (often with its own small ReAct loop), optionally re-planning if reality diverges. Benefits: the plan is visible/auditable, steps can be parallelized, and the agent stays oriented on long tasks. Cost: a rigid plan can be wrong if early steps surprise it — so good versions re-plan when needed.

Plan-and-Execute:  PLAN [s1,s2,s3] → execute s1 → execute s2 (→ re-plan?) → … → synthesize

3. Reflection / self-critique. After acting (or producing a draft), the model critiques its own output ("does this answer the question? any errors?") and revises — a generate→critique→revise loop. Improves quality on tasks with checkable criteria (code that must pass tests, answers that must be grounded), at extra cost/latency. Strongest when paired with a real signal (test results, eval) rather than pure self-judgment.

4. Multi-agent — specialized agents collaborating. Split work across agents with roles (e.g., a planner/orchestrator delegating to worker/specialist agents), each in its own context (04, what-happens §10 subagents). Benefits: context isolation (each agent's context stays focused), parallelism, specialization. Costs: orchestration complexity, more tokens, and coordination failure modes. Use sparingly — many "multi-agent" problems are better as one agent with good tools, or a fixed workflow.

Orchestrator–worker (the most useful multi-agent shape)

The pattern that earns its complexity: an orchestrator decomposes the task and dispatches sub-tasks to worker subagents, each running in a fresh, isolated context window and returning only a summary. This is exactly the subagent / context-isolation technique from what-happens §3.6/§10: keep the bulky exploration out of the main context. Great for parallelizable research (07) and large-codebase audits.

Choosing the architecture (least-agentic that works)

fixed known steps              → WORKFLOW (not an agent at all) [00]
dynamic, one capable agent     → ReAct (the default)
long task, want a visible plan → Plan-and-Execute (+ re-plan)
checkable quality criteria     → add Reflection (with a real signal)
parallel/isolated sub-tasks    → Orchestrator–worker (multi-agent) — only if it earns its cost

The progression mirrors 00: don't reach for plan-and-execute or multi-agent until a plain ReAct loop demonstrably falls short. Complexity adds tokens, latency, and new failure modes (coordination, stale plans).

Why architecture is mostly about staying on track

Because errors compound (00), the architecture's real value is orientation and recovery: an explicit plan keeps a long task coherent; reflection catches mistakes before they propagate; re-planning recovers when reality diverges; orchestration isolates context so it doesn't rot. All of it is in service of higher task success rate — which you measure (09), not assume.

3. Mental Model

   how does the agent organize multi-step work?  (simplest → most complex)
   ReAct: think→act→observe→… (re-plan every step) ← the DEFAULT loop [01]
   Plan-and-Execute: write PLAN → execute steps → RE-PLAN if reality diverges (visible, parallelizable)
   Reflection: generate → CRITIQUE → revise (best with a REAL signal: tests/eval, not just self-judgment)
   Multi-agent: ORCHESTRATOR → worker subagents in ISOLATED contexts → summaries [04, what-happens §3.6/§10]

   CHOOSE least-agentic that works: workflow [00] < ReAct < plan-execute < reflection < multi-agent
   architecture's job = ORIENTATION + RECOVERY across steps (errors compound [5.06]) → higher task success [09]

Mnemonic: ReAct (re-plan each step) is the default; add an explicit plan for long tasks, reflection for checkable quality, multi-agent (orchestrator–worker) only for parallel/isolated work. Each adds cost + failure modes — use the simplest that works.

4. Hitchhiker's Guide

What to look for first: can a plain ReAct loop (with stops) do the task? Most can. Only add planning/reflection/multi-agent where ReAct demonstrably wanders or stalls.

What to ignore at first: elaborate multi-agent frameworks and "agent swarm" hype. They add tokens, latency, and coordination bugs; prove you need them.

What misleads beginners:

• Over-architecting. Reaching for multi-agent/plan-and-execute when ReAct (or a workflow, 00) is simpler and more reliable.
• Rigid plans. A plan made before acting can be wrong — without re-planning, the agent executes a stale plan into failure.
• Self-reflection without a signal. Pure self-critique has limited value; pair reflection with real feedback (test results, eval, tool errors).
• Multi-agent as default. Coordination overhead and token blow-up often make it worse than one good agent (Anthropic's own multi-agent writeup notes the cost).
• Ignoring compounding. No architecture saves a low per-step reliability — fix tools/schemas first (01/09).

How experts reason: they start with ReAct + stops, add an explicit plan when tasks are long/parallelizable (with re-planning), add reflection tied to a real signal when quality is checkable, and reach for orchestrator–worker multi-agent only when context isolation/parallelism clearly pays for its complexity. They measure task success rate per architecture rather than assuming the fancier one wins (09).

What matters in production: task success rate, steps/tokens/latency per task (architecture inflates these), recovery behavior (re-plan/reflect), and context hygiene (isolation via subagents, 04).

How to debug/verify: read the trajectory (08) — is the agent wandering (needs a plan), repeating mistakes (needs reflection/error-feedback, 01), or polluting context (needs subagents)? A/B architectures on a task set (09).

Questions to ask: does ReAct already work? does the task need a visible/parallel plan? is there a real signal to reflect against? does multi-agent's isolation/parallelism justify its cost?

What silently gets expensive/unreliable: over-engineered multi-agent (tokens/latency/coordination bugs), stale rigid plans, ungrounded self-reflection (false confidence), and architecture choices made without measuring task success.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• Four patterns, simplest→complex: ReAct (default) < plan-and-execute < reflection < multi-agent — each adds cost and failure modes.
• ReAct re-plans every step (implicit dynamic plan); plan-and-execute makes the plan explicit (and should re-plan on divergence).
• Reflection works best with a real signal (tests/eval/tool errors), not pure self-judgment.
• Orchestrator–worker is the most useful multi-agent shape: isolated-context subagents returning summaries (what-happens §3.6/§10).
• Use the least-agentic architecture that works — multi-agent's coordination overhead/token cost often makes it worse than one good agent.
• Architecture's job is orientation + recovery across steps because errors compound (Phase 5.06).
• No architecture fixes low per-step reliability — fix tools/schemas first (01).
• Measure task success per architecture — don't assume the fancier one wins (09).

9. Observations from Real Systems

• Most production agents are ReAct loops with good tools and stops — Claude Code, Cursor agent (06, Phase 11).
• Deep-research products use orchestrator–worker: a lead agent spawns parallel research subagents with isolated contexts (07, Anthropic multi-agent).
• Reflection shines with executable signals — coding agents that run tests and revise outperform single-shot (06).
• LangGraph and similar provide explicit graph/state orchestration when control flow gets complex.
• The common over-engineering trap: multi-agent setups that cost 3–5× the tokens of a single agent for no reliability gain — measured, not assumed (09).

10. Common Misconceptions

11. Engineering Decision Framework

CHOOSE AN AGENT ARCHITECTURE (escalate only when the simpler one falls short):
 0. Fixed known steps? → WORKFLOW (not an agent). [00]
 1. DEFAULT: ReAct loop (think→act→observe) + stop conditions. [01]
 2. Long / multi-part / parallelizable task and ReAct wanders? → PLAN-AND-EXECUTE (with RE-PLANNING).
 3. Checkable quality (tests/eval/grounding)? → add REFLECTION tied to that REAL signal.
 4. Need context isolation / parallel sub-tasks? → ORCHESTRATOR–WORKER multi-agent — only if it earns its cost.
 5. MEASURE task success + steps/tokens/latency per architecture; keep the simplest that hits the bar. [09]
 6. If per-step reliability is low, fix TOOLS/SCHEMAS first — no architecture saves it. [01]

12. Hands-On Lab

Goal

Compare agent architectures on the same task and show that complexity must earn its cost — measuring task success vs steps/tokens.

Prerequisites

• The bounded ReAct agent from 00/01; a multi-step task with a checkable outcome (e.g., "find 3 facts and produce a structured comparison").

Steps

1. ReAct baseline: run the task as a plain ReAct loop; record task success (n runs), steps, tokens, latency.
2. Plan-and-execute: have the model emit an explicit plan (a structured list, 02), then execute each step; add re-planning if a step fails. Compare success/steps/tokens to ReAct.
3. Reflection: add a generate→critique→revise pass with a real signal (e.g., "does the output contain all 3 required facts?"); measure quality uplift vs added cost.
4. Orchestrator–worker: split into a planner that dispatches 3 parallel worker subagents (each isolated context, 04) that each fetch one fact and return a summary; the orchestrator synthesizes. Compare latency (parallelism) and tokens (overhead) to ReAct.
5. Decide: tabulate task success vs cost/latency across architectures; pick the least-agentic one that hits the bar and justify with data.

Expected output

A comparison table — architecture → task success, steps, tokens, latency — demonstrating where added complexity helps (and where it just costs more), with a justified choice.

Debugging tips

• Plan-and-execute fails on surprises → no re-planning; add it.
• Multi-agent costs more for no gain → the task didn't need isolation/parallelism; revert to ReAct.

Extension task

Add reflection without a real signal (pure self-critique) and show it helps less than reflection with a test/eval signal.

Production extension

Implement the chosen architecture with full tracing (08) and a task-success eval gate (09); isolate bulky sub-tasks via subagents (04).

What to measure

Task success rate, steps, tokens, latency per architecture; reflection uplift (with vs without a real signal); multi-agent parallelism gain vs token overhead.

Deliverables

• An architecture comparison (success vs steps/tokens/latency) on one task.
• A plan-and-execute (+re-plan) and a reflection (with signal) variant.
• A justified architecture choice (least-agentic that hits the bar).

13. Verification Questions

Basic

1. What is ReAct, and why is it the default?
2. How does plan-and-execute differ from ReAct, and why must it re-plan?
3. When does reflection actually help?

Applied 4. Give a task that justifies orchestrator–worker multi-agent, and one that doesn't. 5. Why does "use the least-agentic architecture that works" apply here too?

Debugging 6. A plan-and-execute agent fails when an early step surprises it. Fix? 7. A multi-agent setup costs 4× the tokens for no quality gain. What do you conclude?

System design 8. Design an architecture-selection process (with measurement) for a complex multi-step task.

Startup / product 9. Why is over-engineering agent architecture both a reliability and a cost risk for a product?

14. Takeaways

1. Four patterns, simplest→complex: ReAct (default) < plan-and-execute < reflection < multi-agent.
2. ReAct re-plans each step; plan-and-execute makes the plan explicit (and re-plans on divergence).
3. Reflection needs a real signal; orchestrator–worker earns its cost only via isolation/parallelism.
4. Architecture's job is orientation + recovery across steps because errors compound — it can't fix low per-step reliability (01).
5. Use the least-agentic architecture that works, and measure task success vs cost to choose (09).

15. Artifact Checklist

• An architecture comparison (ReAct vs plan-execute vs reflection vs multi-agent) on one task.
• A plan-and-execute with re-planning implementation.
• A reflection variant tied to a real signal (and a no-signal contrast).
• An orchestrator–worker (isolated subagents) variant with cost/latency numbers.
• A justified, measured architecture choice.

Up: Phase 10 Index · Next: 04 — Agent Memory