VII · Verification & ReflectionEmerging★

Planner-Executor-Verifier (PEV)

also known as PEV, Triadic Plan-Verify-Execute

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.

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.

Context

A team uses plan-and-execute for multi-step agents. Verification of step success is either skipped (executor runs blindly) or done by the same model that planned (which carries the same biases). Tool failures get retried but goal drift goes unchecked.

Problem

Plan-and-execute without independent verification cannot detect that 'step succeeded' is not the same as 'plan progressed toward goal'. A tool can return success while the world state diverges from what the plan assumed. By the time the plan completes, drift has accumulated. Distinct from plan-and-execute by mandating the third independent verifier role.

Forces

  • Adding a verifier adds latency and a third model call per step.
  • Verifier must reason about goal-progress, not just step-success.
  • Some tool effects are not observable by a verifier external to the tool.

Example

A coding agent plans 'refactor module X'. Planner produces 12 steps. Executor runs step 4 (rename function). Verifier checks: 'does the refactor still compile? do all callers still resolve?' Verifier flags 3 unresolved callers in step 4's effect. Replan triggered with the call-site list as new constraints. Without PEV, the executor would have proceeded to step 5 with broken intermediate state.

Diagram

Solution

Therefore:

Three components, possibly three model calls per step: Planner (one-shot or incremental), Executor (executes step, gets tool result), Verifier (compares post-step state against goal expectation). On verifier reject, trigger replan with the observed drift as context. Distinct from plan-and-execute (which has no verifier) and from evaluator-optimizer (which is per-output not per-step). Pair with replan-on-failure, mental-model-in-the-loop-simulator, stochastic-deterministic-boundary.

What this pattern forbids. No plan step's effect is accepted without an independent verifier check; same-model self-verify is excluded.

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

  • alternative-toPlanner-Executor-Observer★— Add an explicit Observer role between Planner and Executor so progress is checked against the plan instead of trusted blindly.
  • complementsReplan on Failure★★— Trigger a fresh planning step when execution evidence contradicts the current plan.
  • complementsStochastic-Deterministic Boundary (SDB)★— Formalize the seam between an LLM proposal and a system action as a four-part contract — proposer, verifier, commit step, reject signal — so the contract itself, not the agent's good intent, gates side-effects.
  • alternative-toEvaluator-Optimizer★★— One LLM generates; another evaluates and feeds back; loop until criteria are met.
  • complementsMental-Model-In-The-Loop Simulator·— Run candidate multi-step strategies inside an internal simulator of the environment before committing in the real world — broader than simulate-before-actuate (single action) by simulating multi-step strategies.
  • complementsStrategic Preparation Phase★— Mandate an explicit problem-space representation step before the agent attempts solutions, mirroring how expert humans build a mental model of constraints and dependencies before solving.
  • complementsGenerate-and-Test Strategy★— Generate multiple candidate solutions in parallel, then systematically test each against declared constraints rather than committing to the first plausible one — adapted from Langley & Simon's cognitive-science research on human expert problem-solving.

Neighbourhood

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

References

Provenance