An assistant produces a polished design, analysis, draft, or code change. You are not sure whether the result is sound, so you open another assistant and paste both the work and the explanation behind it. The second assistant says the reasoning is coherent and suggests minor refinements.
That may be useful editing. It is weak review. The second model saw the first model’s conclusion before it had a chance to form its own.
Separate the artifact from its defense
The artifact is the thing being reviewed: a patch, document, calculation, plan, or answer. The rationale is the first model’s account of why it is correct. Give the reviewer the artifact first, along with the facts needed to judge it.
Include:
- The intended outcome and named audience.
- Requirements, constraints, and non-goals you confirmed.
- A short text artifact or a stable reference to the exact version.
- Source references, selected test output, or other relevant evidence.
- Known uncertainty, clearly labeled.
- The kind of defects you want found.
Do not remove context that changes correctness. A reviewer needs the requirements and accepted tradeoffs. It does not need the full sequence of arguments that persuaded the first model.
If the artifact is a repository, large document, or protected source set, do not paste it into the package. Give the reviewer separate authorized access and identify the commit, path, version, or source record as text.
Ask a review question that can fail
“Review this” is too broad. Define what a useful failure looks like.
For code, ask about correctness, security, concurrency, compatibility, and whether the tests can pass for the wrong reason. For research, ask which claims exceed their sources and what evidence would disconfirm the conclusion. For writing, ask where the draft misstates the brief, hides uncertainty, or makes an unsupported promise.
Ask the reviewer to return:
- Defects ordered by impact.
- The location and evidence for each defect.
- Uncertainty about each finding.
- Missing tests or checks.
- The smallest way to confirm or disprove the concern.
This makes the output inspectable. Asking for a review rather than a compliment is mostly about giving the reviewer permission to say the work fails.
Use a second pass for rationale
After the first pass, show the original rationale where it matters. The reviewer can then test whether a deliberate choice answers a finding or merely explains how the defect arose.
Keep the order. If the rationale comes first, it anchors the review. If it comes second, it becomes another claim to evaluate. A second model can still share the same assumptions, but you have reduced one obvious source of agreement.
For a debugging-specific version of this workflow, use one AI for debugging and another for review. There, the neutral evidence begins with a reproducible failure and exact code state.
Hand off the review brief to yourself
Draft the review brief to your own email on the RelayLink account both assistants use. Check the artifact reference, requirements, evidence, and defect criteria before you explicitly confirm it. One account is enough: no second account or contact request is involved, and there is no email or magic link. The brief remains unread until any assistant pulls it; the account portal is the fallback.
What RelayLink carries is the structured text you approved, not chat history, hidden reasoning, files, or browser state. A repository path or source reference grants no access. Give the reviewer separate authorized access to the exact code or source version, then check it yourself.
Do not include secrets, customer data, confidential source, or protected documents unless the AI provider and receiving environment are authorized. A human approval to send a RelayLink package does not grant a provider permission to receive restricted material.
Own the verdict
A finding is not true because a second assistant wrote it. Agreement between two assistants is not proof or certification, and disagreement does not tell you which one is right. Models can share training patterns, follow the same flawed requirement, or miss the same edge case.
Run tests, reproduce calculations, check sources, and inspect the artifact. Record which findings you accepted and why. If you reject a plausible finding, preserve the reason and the condition that should reopen it.
If the reviewer cannot inspect the artifact or the relevant evidence cannot be shared safely, treat its response as a limited critique rather than a substantive review. The second assistant supplies another examination; you decide what the evidence supports and what changes.