II · Planning & Control FlowEmerging★

Planner-Executor-Observer

also known as Three-Role Loop, POE

Add an explicit Observer role between Planner and Executor so progress is checked against the plan instead of trusted blindly.

This pattern helps complete certain larger patterns —

  • specialisesPlan-and-Execute★★— Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.
  • used-byReplan on Failure★★— Trigger a fresh planning step when execution evidence contradicts the current plan.

Context

A team runs a Plan-and-Execute agent: a planner emits an ordered plan once and an executor walks the steps. The executor's work needs to be checked against the original intent — does the cumulative output still match what the planner asked for, or has the executor wandered onto an adjacent topic? The team is willing to spend a small amount of supervision overhead to catch drift early instead of paying for an entire bad run.

Problem

Two existing shapes both fail this requirement. Letting the executor run blind means the planner only finds out at the end whether the run was on-track, at which point fixing it requires starting over. Reporting back to the planner after every step rebuilds the ReAct loop and reintroduces the per-step planner cost the team adopted Plan-and-Execute to avoid. There is no clean place for a cheap, focused check that reads the executor's cumulative output against the plan and decides whether to keep going, stop, or replan.

Forces

  • Observation must be cheap or it negates the plan-execute speedup.
  • Triggering replans too eagerly thrashes; too lazily wastes effort.
  • The Observer needs visibility into plan and tool results both.

Example

A research agent that uses a Planner and Executor loop produces fluent reports that quietly drift from the plan: the executor swaps in adjacent topics and the planner never notices because no one is checking. The team adds an Observer role: after each executor step the observer reads the cumulative output against the plan and emits loop, respond, or replan. When the executor wanders into 'related-but-off-plan' territory the observer triggers a replan instead of letting the drift compound.

Diagram

Solution

Therefore:

Three roles: Planner produces a plan; Executor runs steps; Observer reads the cumulative result and decides loop / respond / replan. Each role has its own prompt and (optionally) its own model.

What this pattern forbids. The Executor cannot decide to stop or replan; only the Observer can.

The smaller patterns that complete this one —

  • generalisesOuter-Inner Agent Loop·— Run two nested loops: an outer planner agent decomposes the goal into subtasks; an inner executor runs a ReAct loop on each, and the outer can replan based on the inner's progress.

And the patterns that stand alongside it, or against it —

  • composes-withEvaluator-Optimizer★★— One LLM generates; another evaluates and feeds back; loop until criteria are met.
  • alternative-toReAct★★— Interleave a single thought, a single tool call, and a single observation per step so the agent reasons over fresh evidence.
  • alternative-toPlanner-Generator-Evaluator Harness·— Decompose a long-running job into three role-isolated agents — a Planner emitting a feature list, a Generator working one chunk per fresh context, and an Evaluator grading against a rubric without seeing the Generator's trace.
  • alternative-toPlanner-Executor-Verifier (PEV)★— Triadic specialization where a planner produces the plan, an executor runs it, and a separate verifier checks each step's effects against the original goal.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance