Planner, Executor, Judge: Verification in Agentic LLM Flows

By Lazar Milicevic, Senior Technical Engineer and founder of BizFlowAI. Last updated: 2026-10-23.

An agentic flow is a system where an LLM does not just answer once, but plans steps, calls tools, observes results and decides what to do next, usually across several model calls. The part most teams skip is verification: who checks that a step actually did what it claimed? I have shipped unattended agent pipelines for long enough to say that the planner and the executor are rarely where things break. The missing judge is.

The three roles, and why separating them matters

A planner decomposes the task into steps. An executor carries out one step with tools. A judge checks the executor's output against criteria the planner wrote down before execution started. That last clause is the whole trick.

If the same context that produced an answer also evaluates it, the evaluation inherits every mistaken assumption. Splitting the roles gives you an independent read. This is not a new idea. Anthropic's "Building effective AI agents" describes the evaluator-optimizer workflow, where one LLM call generates a response while another provides evaluation and feedback in a loop. It also describes orchestrator-workers, where a central LLM dynamically breaks a task down, delegates to worker LLMs and synthesizes their results. Planner/executor/judge is those two patterns composed. Reflexion (Shinn et al.) formalizes a similar split into an Actor, an Evaluator and a Self-Reflection module, feeding verbal feedback into the next attempt's context instead of updating weights.

Here is the shape I use:

            ┌────────────┐
 task ────► │  PLANNER   │──► steps + acceptance criteria
            └─────┬──────┘
                  │ for each step
                  ▼
            ┌────────────┐   output + evidence
            │  EXECUTOR  │──────────────────────┐
            │ (tools)    │                      ▼
            └─────▲──────┘               ┌────────────┐
                  │   critique           │   JUDGE    │
                  └──────────────────────│ pass / fail│
                     (max N retries)     └─────┬──────┘
                                               │ pass
                                               ▼
                                         next step / done

Two design rules that took me a few failures to internalize:

1. Acceptance criteria are written by the planner, before execution. The judge scores against them, not against its own impression of the output.
2. The judge sees evidence, not just prose. Tool results, diffs, query output, HTTP status. A judge that only reads the executor's summary is grading the executor's confidence.

A small reproducible example

Here is a minimal version in Python. It is deliberately provider-agnostic: llm(system, user) is whatever client you use (Claude API, OpenAI, a local Ollama model). Swap in your own.

import json

def llm(system: str, user: str) -> str:
    raise NotImplementedError  # your client here

def plan(task: str) -> list[dict]:
    out = llm(
        "Break the task into at most 5 steps. Return JSON: "
        '[{"step": str, "accept": [str, ...]}]. '
        "Each 'accept' item must be checkable from tool output.",
        task,
    )
    return json.loads(out)

def execute(step: dict, critique: str | None) -> dict:
    prompt = step["step"] + (f"\nPrevious attempt rejected: {critique}" if critique else "")
    # run tools here; return the answer AND the raw evidence
    return {"answer": llm("Do the step using tools.", prompt), "evidence": "<tool logs>"}

def judge(step: dict, result: dict) -> dict:
    out = llm(
        "You are a strict verifier. Check each acceptance item against EVIDENCE only. "
        'Return JSON: {"pass": bool, "failed": [str], "critique": str}.',
        json.dumps({"accept": step["accept"], "evidence": result["evidence"],
                    "answer": result["answer"]}),
    )
    return json.loads(out)

def run(task: str, max_retries: int = 2):
    results = []
    for step in plan(task):
        critique = None
        for attempt in range(max_retries + 1):
            res = execute(step, critique)
            verdict = judge(step, res)
            if verdict["pass"]:
                results.append(res)
                break
            critique = verdict["critique"]
        else:
            raise RuntimeError(f"Step failed after retries: {step['step']}")
    return results

The details that matter in production: the retry cap (without it you get loops that burn tokens), the hard failure when retries run out (do not silently continue with a bad step), and logging every verdict so you can later measure how often the judge actually fires.

What the judge gets wrong

LLM judges are useful, and the evidence says so. Zheng et al. (2023) found strong judges like GPT-4 reach over 80% agreement with human preferences, the same level as agreement between humans. On MT-bench with ties excluded, GPT-4 agreed with human experts 85% of the time versus 81% human-to-human. That is why I trust a judge at all.

The same paper documents the failure modes I see in my own pipelines: position bias, verbosity bias, self-enhancement bias, and limited reasoning ability. Translated into agent terms:

My rule: deterministic verification first, LLM judge for what cannot be checked deterministically. If a step produces JSON, validate the schema in code. If it writes code, run the tests. If it publishes a page, fetch the URL and check the status. The LLM judge is for the fuzzy remainder: "does this summary contradict the source?"

This lines up with a conclusion in the MAST paper (Cemri et al., "Why Do Multi-Agent LLM Systems Fail?"): final-stage, low-level verification alone is inadequate, and multi-level verification using external knowledge and testing throughout generation works better. That matches what I see. A single judge at the end of a long chain catches symptoms. Per-step verification catches causes.

Single agent vs planner-judge vs multi-agent

I will be upfront about what I can and cannot give you here. I do not have a clean published benchmark of latency across these patterns, and I am not going to invent one. The cost data point I can cite is from Anthropic's multi-agent research system write-up (quoted by Simon Willison): agents typically use about 4x more tokens than chat, and multi-agent systems about 15x more. Anthropic also says multi-agent systems only make economic sense when the task is valuable enough to pay for that extra cost. The rest of the table is qualitative, from what I have run.

One more data point worth taking seriously: the MAST project page notes that multi-agent systems often gain little over single-agent setups or simple baselines such as best-of-N sampling. That matches my instinct. Before adding agents, try a single agent with a good judge. It is the cheaper experiment and it usually tells you whether you need more.

Failure modes from my own systems

I run unattended, scheduled pipelines, including the autonomous content and SEO machine behind BizFlowAI ContentStudio (research, write, optimize, publish across several sites, with a measure-learn-target-generate-publish loop). I have not instrumented these into a publishable accuracy benchmark, so I will not give you a percentage. What I can give you is the categories of failure, ranked by how often they cost me time:

1. Judge approves what the executor claimed, not what it did. Early on, the judge read the executor's summary. The summary said "published." Nothing was published. Fix: the judge receives the raw tool response and must cite it.
2. Criteria drift. If acceptance criteria are written after the output exists, they quietly bend to fit it. Fix: criteria are produced by the planner and frozen before execution.
3. Retry loops with no new information. The executor gets "failed, try again" and repeats the same mistake. Fix: the critique must name the failed criterion and the evidence line that violated it.
4. Same-model blind spots. A judge from the same model family waved through the same subtle factual slip the executor made. Fix: different model or at least different context and instructions for the judge.
5. Cascading bad plans. A flawed plan is faithfully executed and faithfully approved, because every step meets its own criteria. This is the one a per-step judge cannot catch. Fix: a cheap plan-review pass before execution. There is published work on externalizing the critique into an independent Judge-Planner pair for exactly this reason (plan verification for embodied task agents, arXiv 2509.02761).

Number 5 is the most underrated. Verifying steps against a bad plan gives you high-confidence wrong answers.

How to verify that your judge is worth its cost

Do not assume the judge helps. Measure it:

1. Log every verdict with step ID, criteria, evidence and pass/fail.
2. Sample and hand-label a few dozen verdicts, split between passes and fails.
3. Compute two numbers: how often the judge fails a step a human would pass (wasted retries) and how often it passes a step a human would fail (escaped errors). The second is the one that hurts.
4. Compare against no judge on the same tasks. If the judge's catch rate does not pay for its tokens and latency, remove it or replace it with deterministic checks.

For deeper reading on building reliable judges, the survey "A Survey on LLM-as-a-Judge" (Gu et al., arXiv 2411.15594), last revised in October 2025, is a good map of the space.

What I'd do

• Start with one agent and a deterministic verifier. Schema checks, tests, status codes. Add an LLM judge only for what code cannot check.
• Add the planner-judge split before you add more agents. It is the cheapest reliability upgrade I know of, and the MAST finding that multi-agent often barely beats simple baselines is a good reason to be skeptical of the more expensive route.
• Freeze acceptance criteria before execution and give the judge evidence, not summaries.
• Cap retries and fail loudly. A stuck pipeline that pages you beats one that quietly ships garbage.
• Reserve true multi-agent designs for high-value, parallelizable work, where the extra token cost is justified by the task's value, which is Anthropic's own framing.
• Measure the judge. Escaped errors are the metric that matters.

If you are weighing how to put verification into an agent system you plan to run unattended, I am happy to compare notes at lazar-milicevic.com/#contact, or you can read more field notes on the blog.

Sources

• Anthropic, "Building effective AI agents": https://www.anthropic.com/engineering/building-effective-agents
• Anthropic, "How we built our multi-agent research system" (quoted via Simon Willison): https://simonwillison.net/2025/Jun/14/multi-agent-research-system/
• Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena": https://arxiv.org/abs/2306.05685
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models": https://arxiv.org/abs/2210.03629
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning": https://arxiv.org/pdf/2303.11366
• Cemri et al., "Why Do Multi-Agent LLM Systems Fail?": https://arxiv.org/pdf/2503.13657
• Gu et al., "A Survey on LLM-as-a-Judge": https://arxiv.org/abs/2411.15594
• "Plan Verification for LLM-Based Embodied Task Completion Agents": https://arxiv.org/pdf/2509.02761

---

About the author: Lazar Milicevic is a Senior Technical Engineer with 10+ years building AI automation, cloud architecture and B2B SaaS systems, and the founder of BizFlowAI. He designs autonomous systems that run unattended, from multi-agent content and SEO machines to serverless AWS integrations and local-LLM RAG pipelines.