The third reviewer has to be blind

Every agent pipeline I run ends with a reviewer that knows less than I do, on purpose.

It gets the artifact. It gets one question. It does not get the QA report, the revision history, how many rounds it took, or what I think the answer is. That last exclusion is the entire point, and it took me a while to accept it, because withholding context from a model feels like sabotage.

It isn't. Context is exactly what corrupts the second opinion.

What happens when you brief the reviewer

The natural thing to write is a prompt like:

The QA engine passed this design but I'm not sure about the hinge clearance. Take a look and tell me if it's a problem.

You will get an answer about the hinge clearance. You will usually get agreement. What you will not get is the thing you actually needed, which is the observation you did not know to ask for — the one about the bracket on the other side of the part that holds nothing.

Hand an agent a hypothesis and it works on your hypothesis. Tell it a gate already passed and you have told it the expected answer. The review comes back in the same confident register either way, which is what makes it dangerous: a rubber stamp and a genuine all-clear are textually identical.

I am not describing a model defect. Ask a person to check your work and mention you are fairly sure it's fine, and you will get the same outcome. The difference is that you can run the agent version a hundred times a week, so the failure compounds quietly.

The rule

After the deterministic gate passes, dispatch a reviewer that has seen none of it.

Concretely, in my pipelines:

• The mechanical reviewer gets the renders and the printed-part list and one question: would this work mechanically? It does not know the QA engine exists.
• The electrical reviewer gets the schematic, the BOM and the board contract, and answers would this circuit work? — reasoning from first principles about whether every rail has a source and every current path is sized for its load.
• The buyer reviewer on the product-research pipeline gets the product, the price, the images and the competitor table. Not the analysis. Not the scores. Just: would you buy this over page one?

Each one runs after the gate passes, never instead of it. That ordering is not a detail.

Why not instead of

The deterministic gate and the blind reviewer catch different species of defect, and neither one degrades gracefully into the other.

The gate is a script. It checks the things I knew to check, it returns the same verdict every time, and it keeps running after I am gone. It is also, by construction, incapable of noticing anything I did not anticipate. It catches the wall thickness, the clearance, the missing decoupling cap.

The reviewer catches the category error. The assembly that is geometrically valid and impossible to put together. The bracket that holds nothing. The product whose economics close and that nobody wants. Those never appear as a failing row, because no row was ever written for them.

Run only the gate and you ship confident nonsense. Run only the reviewer and you have swapped a reproducible standard for an opinion that changes between runs — which is not a gate at all, and cannot be handed to a client as the thing that proves the work.

It costs something real

Blind review is more expensive than the alternative, in two ways worth stating plainly.

It burns tokens on context the reviewer must rebuild from the artifact — that is the price of the independence. And it produces false positives: a reviewer that does not know a constraint was deliberate will flag it. I get told about decisions that were already considered and settled.

I take that trade every time. A reviewer that never objects has told me nothing, and I cannot distinguish it from one that has nothing to object to. Noise I can triage. Silence I cannot interpret.

The tell that you have got it wrong is a reviewer that agrees with you constantly. That is not a high-quality pipeline. That is an expensive echo, and it will agree with you right up until a customer doesn't.

If you build one thing from this

Take whatever review step you already have and delete the context from its prompt. Not the artifact — the framing. No "we think," no "QA already passed," no "just check X."

Give it the thing and the question. Then see whether it still agrees with you.

---

This is the pattern we build into client work: three passes, and the third one has no idea what the first two decided. How that works.