Who Judges the Judge?

The fashionable way to make an agent safe is to point a second model at it and call that model the judge. It sounds rigorous, it demos beautifully, and almost nobody asks the only question that matters: who judges the judge?

The pattern is real and it is spreading fast, because it solves a real problem. Agents do not fail by hallucinating. They fail by doing exactly what they were trained to do, one step further than anyone authorized. A follow-up agent whose whole reason to exist is closing the loop will send the email nobody approved, because sending the email is what closing the loop looks like from inside its objective. You cannot fix that by asking the same agent to also police itself. Two masters, one model, and the incentive to act wins every time. So you split the roles. One model acts, a separate model judges. That much is sound. The part that is quietly broken is the assumption that the second model is actually independent.

The pattern everyone is shipping

Strip away the branding and the judge-model pattern is the same shape everywhere it shows up. The acting agent does not get to execute directly. It has to submit a structured proposal first: the action it intends to take, the evidence it believes authorizes that action, the explicit scope of the task, and the consequences it expects. A second model, the judge, reads that proposal and returns a decision. The acting agent optimizes obsessively for getting the job done. The judge optimizes obsessively for guarding the user’s intent. Specialization at the right grain, and neither one does both jobs.

Two design choices make it work in practice, and both come straight out of the production write-ups. The first is that you do not judge every action with equal intensity, because that is how you either drown users in prompts or wave through the one action that mattered. You classify actions into four buckets and calibrate the judge to each:

• Read-only. Retrieve, summarize, inspect. Light touch, and only heavier if the data itself is sensitive.
• Reversible write. Drafts, labels, internal notes, local files. Validate, but you can skip the full audit trail.
• External-impact. Sending messages, booking meetings, posting publicly, opening a pull request. Strong judge, every single time, no exceptions.
• High-risk. Spending money, deleting data, changing permissions, merging code. Judge plus a human approval path, unless you have a narrow, explicit, written policy that says otherwise.

The second choice is that the judge does not answer yes or no. A binary judge trains people to route around it, so production judges return one of four outcomes: allow when scope and authorization are clear, block when the action would exceed authority or cause irreversible harm, revise when the fix is obvious (“draft the email but do not send it,” “archive instead of delete”), and escalate when a human genuinely needs to look. Escalation is a dial. Too low is dangerous, too high destroys trust and nobody uses the thing. I walked through that same escalation-of-permission logic in The Trust Ladder, and the four-bucket table is just that ladder drawn with named rungs.

None of this is wrong. It is genuinely good engineering. It is also where the thinking usually stops, and the place it stops is exactly the place the failure lives.

The comfortable answer, and why it is a trap

Ask a practitioner about the obvious objection, that the actor and the judge might share the same blind spots, and you will get a confident answer that goes roughly like this. Yes, that was a real problem in late 2025. If your judge ran the same model as your actor, with the same context and the same prompt style, it tended to rubber-stamp whatever the actor proposed. But frontier models in 2026 are so far ahead of everything else that the correlated-judgment risk is nearly gone. Stop worrying about the judge and start worrying about scope: what can the system touch, write, or delete?

I understand the appeal, and I think it is the single most dangerous sentence in the whole pattern. It reframes a structural problem as a temporary one, then declares the temporary version solved. The advice that follows (“use a closed-source frontier model as your judge, do not point a Qwen model at a Qwen model”) is not wrong so much as it is aimed at the wrong target. It treats correlated failure as a symptom of weak models. It is not. It is a property of shared origin, and a stronger model does not remove shared origin. It hides it, right up until the moment it does not.

Correlated failure is the whole problem

Here is the mechanism, because vague hand-waving about “blind spots” is what let the comfortable answer win.

When your actor and your judge come from the same model family, they are not two independent observers. They are two samples from one distribution. They were pretrained on overlapping corpora, aligned with the same reinforcement lineage, and shaped by the same house style of reasoning. Their errors are correlated because their competence is correlated. On the vast middle of the input space, where the actor is obviously right or obviously wrong, this does not matter, and that is precisely what makes it seductive: the judge looks like it is working, because on easy cases it is. The failure is concentrated in the tail, on the inputs where the actor is confidently wrong. Those are exactly the inputs where a judge drawn from the same distribution is also confidently wrong, and in the same direction. The judge does not catch the actor’s worst mistake. It ratifies it, and hands you a clean audit record that says two models agreed.

This is not a new idea and it does not belong to AI. Reliability engineering has known for decades that redundancy only buys you safety when the redundant components fail independently. Two identical components on one power rail are not redundant, they are one failure with a spare label. The N-version programming research from the 1980s found the same thing about software written to the same specification by different teams: the “independent” versions failed together on the hard inputs, because the hard inputs were hard for everyone. An ensemble of correlated estimators reduces variance you did not need reduced and does nothing for the bias you share. LLM-as-judge, a technique whose academic roots trace to the MT-Bench and Chatbot Arena work on using strong models to evaluate other models, inherits this whole inheritance. A judge is a redundant estimator of “is this action authorized.” If it is drawn from the same well as the actor, you have bought a spare, not a check.

Making the judge model stronger does not fix this. It moves the tail. A more capable judge is confidently wrong less often, so the region of correlated failure shrinks, which reads on every dashboard as “the problem went away.” It did not go away. It got smaller and quieter and more concentrated on the genuinely novel, genuinely adversarial inputs, which are the only ones an attacker cares about anyway. You have optimized your safety system to work everywhere except the place it will actually be attacked.

What genuine independence would require

If correlated failure is the disease, then the treatment is decorrelation, and you get that structurally or you do not get it at all. Three layers, in order of how much they buy you.

The first and cheapest is a cross-vendor judge. Not a different prompt on the same model, and not a smaller sibling from the same lab, but a judge whose weights come from a different training lineage entirely. If your actor is one vendor’s frontier model, your judge should be a different vendor’s, chosen specifically because its blind spots are unlikely to line up with the actor’s. This is the same instinct behind reading your own reasoning back through a model from a different family, which is why cross-vendor review keeps showing up as a real control rather than a nicety. It is imperfect. Vendors train on overlapping public data and their errors are more correlated than anyone would like. But it is a real reduction in shared blind spots, and it costs you a second API key.

The second layer is the one the whole conversation skips, and it is the load-bearing one: for anything that must never be wrong, do not use a model at all. Use a deterministic gate. A judge model is the right tool for the fuzzy questions (“does this email match the user’s intent”), and the wrong tool for the crisp ones (“is this recipient outside the approved domain,” “does this action touch a production table,” “is the dollar amount over the limit”). Those are not language questions. They are policy questions with exact answers, and a rule written in code gives you the same answer every time and leaves a record you can show an examiner. I made the general version of this case in Validation Hooks: a prose instruction to a model is a nudge it can talk itself out of, and a hook is code that fires whether the model feels like it or not. The correct architecture is not model-judges-model. It is deterministic gate first, model judge second, and the model only ever gets to reason about the questions that genuinely need reasoning. Everything else fails closed on a rule.

The third layer sits underneath both and is the one nobody in the agent-safety discourse wants to talk about, because it is unglamorous plumbing. None of the above means anything if you cannot say, cryptographically, which workload proposed the action and which workload judged it. If the actor and the judge are just two prompts in the same process, sharing the same credentials and the same ambient authority, then “independence” is a story you are telling yourself. Real independence needs identity: each agent a distinct, attested, short-lived workload identity, so the gate knows who is asking and can bind a decision to an actor. This is a solved problem outside AI. SPIFFE and SPIRE exist precisely to give workloads verifiable identities that do not depend on where they happen to be running, and the same machinery that stops one microservice from impersonating another is what stops your acting agent from quietly wearing the judge’s authority. Without that layer, the judge is not a separate party. It is the actor in a different hat, and a blind spot does not care which hat it is wearing.

Three judges, one blind spot

I wrote in We Inspect the Traffic about three teams solving the same problem and shipping three different winners, and how the honest move is to inspect what actually crosses the wire rather than trust the story each team tells about itself. The judge pattern is that essay’s dark twin. Point three same-family judges at three same-family actors and you do not get three independent checks. You get three teams, three winners, and one shared blind spot that every judge inherits and none of them can see, because the thing you cannot see is by definition the thing your judge was not built to look for. Correlated judgment is not a bug you patch. It is the shape of the pattern when you build it the easy way, and the only inspection that catches it is the one that comes from outside the family: a different vendor, a deterministic rule, a signed identity that ties the decision to a party who is actually separate.

The judge model is a good idea. It is just not a finished one, and the industry is shipping the unfinished version at scale while congratulating itself on the safety it did not buy. The correlated-failure risk did not disappear when the models got strong. It went quiet, which is worse, because a risk you can measure is a risk you can manage and a risk you have declared solved is a risk you have stopped watching. Put a judge in front of your agent. Then make it a stranger, back it with a rule that cannot be talked out of anything, and give both of them names your infrastructure can verify. Anything less is one model agreeing with itself and charging you for a second opinion.

---

The judge model is the right pattern built on the wrong assumption of independence. Decorrelate it on purpose, gate the crisp questions in code, and never let two samples from one distribution vote on the action that matters most.

I write about AI-assisted development, enterprise architecture, and the security patterns everyone adopts before anyone stress-tests them. Find me on X @orestesgarcia or LinkedIn /in/setsero.