How Do You Design Mutual Review Between Two AIs?: Three Levels of Review Mechanism

What this article covers

Asking a second AI to catch your mistakes comes in three depths: review the final output only, run both sides once and merge, or run a full dual-track mutual review. Most people only know the first, and the first is exactly the one that cannot catch the most expensive kind of error: taking the wrong route from the very start.

What follows is a way to choose, plus prompts you can copy directly. How each of the three levels runs, when to pick which, how much the cost differs, when to stop, what to do when the other model is unreachable, and what is left when you only have one vendor.

1. The reason, in one line

A chef who loves chilli needs a taster who does not eat chilli. He is not trying to deceive anyone. He simply likes it hot.

So having the same model self-review three or five times does not do much, and it costs more. Switching to another vendor often catches the problem straight away. That is the premise. What follows is the question of how deep the switch should go.

2. The three levels

Level one: review the final output only

Your main model works all the way to the end, and the other vendor only looks at the finished product. This was my earliest approach, and it is enough for most day-to-day work.

What it catches: things written wrong, things left out, parts that contradict each other. What it cannot catch: the main model choosing the wrong direction at the very beginning. It only sees the destination, never the route.

Level two: both sides run once, then merge the good parts back

Two vendors each work through the same material independently, and then you let the main model look at the other track and merge in whatever is worth keeping.

The advantage here is that the cost stays below the full treatment, but you already have information about what the other route looks like. Good for things of middling importance when time is short.

Level three: full dual-track mutual review

A finishes and reviews B, B finishes and reviews A, and then the two review each other once more. Only major decisions get this.

3. How to choose: three criteria

You do not need the full treatment on everything. My order of questions is these three:

My own working ratio is roughly this: most work stops at level one, important things get level three, and level two goes to the "I would like to see whether there is another route, but not today" cases.

4. Cost: what this takes

Fixed cost: one monthly subscription with each of two vendors. The desktop tools can call each other, so there is no need to wire up an API separately. This is how I use it, and it is the threshold I think a document worker can afford.

Variable cost: for the same job, level one is roughly twice the work of a single pass, and level three goes up noticeably more, because both sides have to read the whole thing from the start and then review once each. That is my rough sense of the relative scale, not a measurement.

Honestly, I have never measured the actual usage of each option precisely. I can only give you the relative relationship. The practical judgement is: level one for daily work, level three only for important decisions. That is more useful than exact numbers.

Would three vendors be safer? I did the arithmetic and decided against it:

If every vendor has to review every other vendor, the workload multiplies several times over, and the time is not there either. In my experience two vendors already handle the large majority, and the marginal gain from a third is usually not worth it. That is a judgement from experience, not a statistic.

5. How many rounds before you stop

Easier to miss than "should I run a mutual review" is this: how many revisions before you stop. Without an upper limit, it will keep revising until it thinks the result is good, and what you get is either a bill that keeps climbing or a result that drifts further off.

First, a definition of one round:

• Round one: A reviews B, and B reviews A
• Round two: A revises once following B's suggestions, B revises once following A's, and then they review each other again

When two or three rounds have not solved it, the issue is usually not that you need more rounds. Something is missing from the rule itself. That is the moment to stop and look at the rule, not to keep running.

Two numbers need to be kept apart, or they will look like they contradict each other: "two to three rounds" is how many times the whole mutual-review process runs; "at most two revisions" is how many times it redoes the same single problem. The first is the rhythm you manage. The second is the ceiling you write into the rule for it.

How to tell the rule is missing something

I used tidying a desk to explain this in class. You give it a reference photo of a tidy desk plus four indicators. It tidies once, compares against the standard, and tidies again if it does not match. But if there is suddenly a ball on the desk, and the reference photo has no ball and says nothing about where a ball goes, it can run a hundred more times and still never fully match.

The right move at that point is to stop and report: everything else is in place, this ball has no rule, please add one. So the stop condition needs two layers:

6. What to do when the other model is unreachable

This is something you will hit once you have run it for a while. I have one desktop machine and two laptops, the accounts log each other out, and the mutual review drops out often.

My rule used to say "a mutual review is mandatory", and the result was that one disconnection froze the whole flow. What I came back to was a half-finished thing, which is worth nothing.

The rule now says: if the other side does not respond, the main track finishes first, then tells me the other vendor did not review it, and produces a handoff instruction I can copy in one click. That handoff has to be clear about four things:

Point four is the important one. The status has to be honest, or next time you look at it you will assume this has already been reviewed.

7. When you only have one vendor

Plenty of environments have this constraint: the company only bought one, security policy only allows a specific service, or the budget only covers one subscription.

Cross-vendor review is out of reach here, but there is still a substitute:

• Open two clean new conversations, one running with a "producer" role setup, one with a "only find faults, do not rewrite" role setup
• Neither side sees the other's process. They only exchange finished output
• Open a third conversation that does nothing but compare, and list where the two disagree

8. Turning the three levels into four shared phrases

The last step is making this something you can say out loud in daily work. I boiled it down to four phrases:

The phrase is what triggers it. The full rule lives in your folder. This is also why the rule should be written somewhere the AI can read, rather than explained again every time.

How you can start

Three related articles

• Why Does the AI Keep Forgetting What I Told It?: From "I'll Remember That" to Letting It Run Itself: the step before mutual review, and how to confirm a rule really was remembered and really gets triggered.
• The AI Revised It Ten Times and It Is Still Wrong. Now What?: Cleaning the Data Is Only the First Layer: with long documents you have to handle material and slicing first, or the mutual review is meaningless.
• Can I Get the Computer at Home Started While I Am Out?: One QR Code Scan and the Desktop Begins: what these rules look like inside a loop that actually runs.