Planner, critic, verifier: orchestration patterns that survive production

Key takeaways

• One agent with ten responsibilities fails mysteriously; five agents with two responsibilities each fail legibly. Role separation is a debugging strategy, not a philosophy.
• The critic and the doer must be different contexts. Models grade their own work generously.
• Verification is a gate, not a vibe: schema checks, citation checks, and acceptance tests that run before output leaves the system.
• Budget everything — steps, tokens, tool calls, wall-clock. Autonomy without budgets is an outage with extra steps.
• Determinism at the orchestration layer, creativity inside the nodes. Never the reverse.

Why multi-agent at all

The honest answer isn't "agents are the future" — it's that single-prompt systems stop being debuggable past a certain task size. When one model call plans the work, does the work, and judges the work, a bad output gives you nothing to inspect. Was the plan wrong? The execution? The self-assessment (always glowing)?

Splitting roles gives every failure an address:

• Planner — decomposes the task into steps with explicit inputs and outputs. Produces a plan as data, not prose.
• Executors — do one step each: research, extraction, drafting, tool calls. Narrow contracts, schema-bound outputs.
• Critic — reads an executor's output against the step's contract and returns structured objections. Crucially: a fresh context that did not produce the work.
• Verifier — the last gate. Mechanical checks (schema, citations resolve, constraints hold) plus targeted spot-checks. Only outputs that pass leave the system.

This is the architecture behind our Agent Orchestration module, and the same shape shows up in the swarm act of the journey on our home page — planner, researcher, critic, verifier, messages in flight.

The patterns that matter

The orchestrator is boring on purpose

The layer that routes messages between agents should be deterministic code — a state machine, not another LLM improvising control flow. Same input, same routing, replayable from logs. When someone asks "why did the system do that," the answer must be a trace, not a shrug.

plan (data) → step 1 → critic → [pass] → step 2 → critic → [pass] → verifier → out
                          ↓ [fail, structured objection]
                     retry with objection attached (max N)

The retry carries the critic's specific objection back into the executor's context — not "try again," but "the summary cites a source that doesn't exist; remove or replace it." Bounded retries with reasons converge; blind retries oscillate.

Critic ≠ doer

The single most reliable finding from running these systems: a model reviewing its own output in the same context finds almost nothing. The same model, fresh context, adversarial instructions, finds real problems. Self-review theater is the most common way "we have verification" turns out to be false.

Verification is mechanical first

Before any model judges quality, machines judge validity:

• Output parses against the step's schema.
• Every citation resolves to a real retrieved chunk (the grounding contract again).
• Hard constraints hold — length, allowed values, no mutations outside the step's scope.

Cheap checks catch a shocking share of failures, and they never get tired or generous.

Budgets, or it isn't production

Every run gets ceilings: maximum steps, maximum tool calls, token spend, wall-clock. Hitting a ceiling isn't failure — it routes to a human with the partial trace attached. The alternative is the agent that spent a weekend re-planning in a loop because nobody told it stopping was allowed.

Failure modes to design against

Failure	Smell	Countermeasure
Ping-pong loops	Two agents "improving" each other forever	Retry ceilings, objection must change between rounds
Consensus theater	Critic approves everything	Fresh context, adversarial brief, sampled human audit
Scope creep	Executor "helpfully" does extra work	Schema-bound outputs, mutations only via the orchestrator
Silent degradation	Quality drifts as inputs shift	Golden-set evals on a schedule, not just on deploys
Runaway spend	One task burns the day's budget	Per-run ceilings, spend visible in traces

Where to start

Not with five agents. The ladder we recommend — and the one we follow in client work — starts with one caged agent inside a deterministic workflow, adds a separate-context critic when wrong outputs start costing real money, and only grows into planner/executor/verifier when tasks genuinely decompose. Each rung has to pay rent in reliability before the next one exists.

FAQ

Doesn't all this checking defeat the point of autonomy? Autonomy isn't the point — outcomes are. The system is autonomous inside its gates; the gates are what make the autonomy deployable in front of paying users.

One big model call with a great prompt — cheaper? Sometimes, for small tasks, yes. The crossover comes when failures need diagnosing. A monolith gives you a bad answer; a pipeline gives you the step that produced it, the objection that caught it, and the trace to fix it.

Is this framework-specific? No. These patterns predate and outlive any given agent framework — they're about where determinism lives. Pick tools that let the orchestration layer stay boring.

---

oblivioX designs orchestration layers where specialised agents plan, execute, and verify in parallel. If your agents are impressive in demos and mysterious in production, the door is open.