The Mirror Agent Pattern: Building AI That Critiques Its Own Output

One extra LLM call. That's the entire cost of a mirror agent. In return you remove the dumbest 40% of your output errors — the ones that aren't subtle reasoning failures but obvious garbage your producer model would catch if it bothered to re-read its own work. We've measured this across six production agent stacks and the lift is almost embarrassingly cheap. Mirror agents are not a silver bullet, but they sit so far inside the cost-benefit envelope that not running one is usually a mistake.

The pattern is simple: after your producer agent generates output, a second pass critiques that output against a rubric and either approves, rewrites, or rejects it. The mirror sees what the producer just made and asks the question the producer never asks itself in the first pass: is this actually good? This post is the practical guide — what a mirror agent actually is, when it helps, when it makes things worse, and how to implement and evaluate one without burning your latency budget.

What A Mirror Agent Is (And Isn't)

A mirror agent is a second LLM pass — same model or different — whose only job is to evaluate the output of the first pass and produce either a verdict, a revised version, or structured feedback. It is not a verifier (which runs deterministic checks like schema validation or unit tests). It is not a human review queue. It is a critique step that runs inline before the output ever reaches the user.

The cleanest mental model: your producer is a junior engineer pushing code. The mirror is the same junior engineer reading their own diff before the PR goes up. Same brain, different mode. The mirror gets the prompt, the output, and a critique rubric — and is explicitly told to look for problems rather than generate solutions. That mode-shift is where the lift comes from.

What it isn't: a mirror agent is not a smarter model checking a dumber one (that's a judge pattern), not a tool-calling validator (that's a verifier), and not a human-in-the-loop checkpoint. It's pure LLM-on-LLM reflection, with all the implications that carries — including the fact that if your producer is wrong about a fact, your mirror is probably wrong about it too.

Reflection vs Critique vs Verifier Patterns

The agent literature uses these three terms almost interchangeably, and that's a problem because they have different cost profiles and different failure modes. Here's the breakdown we use internally:

Most teams conflate self-reflection with mirror agents. They are not the same. Self-reflection runs in the same context window, which means the producer is anchored on its own output and tends to defend it. A mirror agent runs in a fresh context with only the original task and the candidate output — no chain-of-thought contamination, no commitment bias. In our testing, mirror agents catch roughly 2.3x more errors than same-context self-reflection on the same producer output.

Verifiers should always run first. Never use a mirror to check something a regex could check. Tokens spent on verifiable problems are tokens wasted. The mirror is for the fuzzy stuff — coherence, tone, hallucinated entities, missed instructions, formatting violations that don't have a clean schema.

When Mirror Agents Help vs Make Things Worse

We've watched teams add mirror agents to pipelines and see quality drop. It happens. Here's the honest map of where mirrors actually help and where they introduce more problems than they solve.

Where They Help

• Structured output that frequently breaks rules. Classification, extraction, JSON-mode tasks where the producer hits the right shape 85% of the time and you need that last 10-12%.
• Multi-instruction prompts. When the producer prompt has 6+ requirements, the mirror catches dropped instructions far better than the producer catches them in self-reflection.
• Tone, voice, brand violations. A mirror with a tone rubric catches "this sounds AI-generated" better than any single-pass prompt.
• Hallucination filtering on retrieved content. Pass the retrieved chunks to the mirror with "does the output only use facts from these sources?" — this works disturbingly well.

Where They Hurt

• Creative tasks with no objective rubric. Mirrors regress toward mediocre, safe outputs. Your spicy headline becomes a corporate headline.
• When producer and mirror are the same model with same knowledge. If GPT-5 is wrong about a fact, GPT-5 the mirror is wrong about it too. Mirrors do not fix knowledge gaps.
• Tight latency budgets. Adding 800ms-2s to a real-time pipeline can kill UX faster than the quality lift saves it.
• Output the mirror can't actually evaluate. Asking a text-only mirror to critique generated code without executing it is mostly theater.

The single biggest failure mode we see: teams use the mirror as a revise step instead of a verdict step. Revision lets the mirror rewrite the output, which means it can introduce new errors that the producer never made. Verdict mode — where the mirror only emits APPROVE / REJECT / WHY — keeps the failure surface smaller. Use revise sparingly, verdict by default. For more on this distinction see our guide to agent evaluation testing.

Implementation: Dual-Agent And Self-Reflection Prompts

Here's the structural skeleton we deploy. Two patterns, depending on whether you want a dual-agent setup or a cheaper self-reflection pass.

Pattern A: Dual-Agent (Verdict Mode)

1. Producer receives task prompt and emits candidate output.
2. Mirror receives: (a) the original task, (b) the candidate output, (c) a critique rubric, (d) explicit instruction to output APPROVE or REJECT with reasons. No revision.
3. If APPROVE, ship. If REJECT, loop the producer with the mirror's feedback as context.
4. Cap the loop at 2 iterations. After that, fall through to whatever your fallback is.

The critique rubric is the entire game. Bad rubric, bad mirror. Good rubrics are concrete and binary: "Does the output cite at least one source? Y/N." Bad rubrics are subjective: "Is the output high quality?" Force the mirror into yes/no checks and aggregate them into a verdict.

Pattern B: Self-Reflection (Same-Context)

1. Producer emits candidate output.
2. In the same conversation, append a system turn: "Re-read your output above. Identify any failures against the rubric. Then output a corrected version."
3. The corrected version is your final output.

Pattern B costs ~30% more tokens, no extra round trip, weaker quality lift. It's the right call when latency matters more than the absolute ceiling on quality — chat UX, real-time pipelines, anything under 500ms budget. Pattern A is the right call when quality matters more than latency and you can absorb a second round trip.

The Self-Critique LLM Prompt That Actually Works

After testing dozens of prompt variants, here's the structure that consistently outperforms others on our evaluation harness:

• Role shift: "You are a strict reviewer. Your job is not to generate output. Your job is to find problems in existing output."
• Checklist: Provide 5-12 binary checks. More than 12 and the mirror's attention fragments. Fewer than 5 and you're not really evaluating.
• Anti-charity instruction: "Assume the output is wrong until proven otherwise. Default to REJECT." This single line lifts catch rate by ~15% in our tests.
• Forced structured output: Each check returns Y/N + one-sentence reason. Aggregate at the end. No prose.

Cost / Latency Tradeoffs

The honest numbers, based on production deployments we've measured:

Notice judge-down. Using a smaller model as the mirror — Haiku critiquing Sonnet, or 4o-mini critiquing 4o — is the most cost-efficient setup we've found for high-volume agents. The smaller model is often just as good at applying a rubric as the bigger one, because applying a rubric is easier than producing the original output. You spend 15-25% more tokens to catch 22-32% more errors. That's the sweet spot for production. We dig into the broader cost model in production-ready agents.

The judge-up setup (smaller producer, bigger mirror) is for high-stakes one-shot decisions — legal review, medical triage, payment authorization. Don't use it on high-volume traffic. The 3-8x cost multiplier compounds fast.

Evaluation: Measuring Mirror Lift

Don't deploy a mirror without measuring whether it actually helps. The default assumption "more checks = more quality" is wrong often enough that you need real numbers. Here's the eval setup we run on every mirror we deploy.

The Four Metrics That Matter

1. Catch rate. Of known-bad outputs the producer generates, what % does the mirror reject? Build a fixed eval set of 50-200 known failures. Run them through the mirror. Track the number.
2. False reject rate. Of known-good outputs, what % does the mirror wrongly reject? This is the metric most teams forget. A mirror with 95% catch rate and 30% false reject rate is worse than no mirror.
3. Net quality lift on production traffic. Run A/B: 50% of traffic gets mirror, 50% doesn't. Have humans score the final output. The delta is your real lift — and it's usually smaller than the catch rate suggests.
4. Loop convergence. When the mirror rejects and you loop back to the producer, what % converge to APPROVE within 2 iterations? Below 70% and your rubric is too strict or your producer is mismatched.

The Honest Failure Modes

• Mirror agrees with everything. Catch rate <5% on your known-bad eval set. Usually fixed by stricter rubric or the anti-charity instruction.
• Mirror rejects everything. False reject rate >25%. Usually too many checks or checks too subjective. Cut the rubric in half.
• Infinite loop. Producer and mirror disagree forever. Hard-cap iterations at 2 and emit the best-of-N candidate.
• Mirror catches symptoms, not causes. Loop fixes the surface issue but breaks something else. This is where human-in-loop testing earns its keep — you need a human pass on the long tail.

For the broader question of how you score agent output before any of this is deployed, see our piece on AI output quality metrics. The mirror is only as good as the rubric, and the rubric is only as good as the metrics you can actually measure.

The Pattern, Compressed

A mirror agent is the cheapest quality lever you have between your producer agent and your user. One extra LLM call, ideally on a smaller model with a tight binary rubric, in verdict mode, with a hard 2-iteration cap. Measure catch rate and false reject rate together, not either one in isolation. Run verifiers before you run the mirror. Don't use mirrors on creative tasks with no objective rubric. Don't expect them to fix knowledge gaps — they critique form, not facts.

The mirror agent pattern won't make a bad agent good. It will make a mediocre agent noticeably better, at a cost most teams can absorb without flinching. The teams that ship the highest-quality agents in production aren't running smarter models — they're running ordinary models with a mirror behind them, catching the dumb stuff before it ever hits a customer. That's the whole game. One extra call. Almost ​without cost.