Why This Matters
Most multi-agent setups make things worse. There is exactly one shape that consistently pays for itself: the critic agent. A primary writes; a separate evaluator agent reviews against a fixed checklist; on fail, the primary retries with the critique attached; a hard iteration cap prevents infinite loops. This guide is the wiring diagram for that pattern — two-agent and three-agent variants, the prompt-design rules that separate a real critic from a rubber stamp, the four predictable failure modes (agreeable critic, infinite loop, drift trap, sandpaper effect), and the cost math that tells you when it pays off. By the end you will know how to build a critic loop that catches real bugs before they ship, without falling into the merge-hell traps that doom naive multi-agent.
The Problem
Single-agent output is confident. That is the problem.
A model running a single pass over a task produces something that reads finished. The prose is fluent. The function compiles. The SQL parses. You skim it, it looks fine, you ship it. Two days later a customer hits the case you never thought of, the empty input case, the off-by-one, the second SELECT inside what was supposed to be a single-query function. The output was wrong all along and nothing in the run flagged it.
You can try to fix this from inside the primary. Sharper system prompts. More tests. Explicit checklists in the instructions. It helps. It does not eliminate the failure mode. The model that wrote the code is the same model evaluating the code, in the same conversation, with the same context window biasing it toward "this looks done." That is sycophancy collapse against itself.
Sometimes you need a second pair of eyes. Not a second worker doing the same job in parallel — that route lands you in merge hell, where two agents produce competing artefacts and a third has to reconcile them. What you want is a different role: an evaluator whose only job is to find faults in the primary's output before it ships. The primary writes. The critic flags. The critic never edits.
This guide is the wiring diagram for that pattern. Build it well and one bad output stops costing you a 2am incident. Build it badly and you have rebuilt naive multi-agent with extra steps.
The Core Insight
A critic agent is not a second worker. It is a different role with a different prompt, and ideally a different model or at minimum a different temperature.
The distinction matters because the failure mode of naive multi-agent - two workers producing two outputs you then have to merge - is exactly what we are not doing here. The primary ships. The critic never ships. The critic's job is to find fault. That asymmetry is what makes the pattern work.
Think of it like the difference between two writers collaborating on a draft (merge hell, prose drift, voice collision) and a writer plus an editor (one person owns the words, one person owns the red pen, the handoff is clean).
If you let the critic edit directly, you have rebuilt naive multi-agent and you will get all the same anti-patterns: context explosion, merge hell, infinite loops where the critic rewrites what the primary just rewrote.