Pattern Matrix/White Paper/C3

C3 · Adversarial Review

What problem it solves

The same LLM running three different prompts and pretending to be an "independent reviewer" does not count as independent in the eyes of a regulatory auditor. These three prompts share the same underlying model's training data, the same alignment biases, and the same prior about "what it thinks is right and what is wrong." It is like a judge serving as prosecution, defense, and arbiter at once: formally there is review, but structurally there is none.

Adversarial review addresses how a high-stakes decision passes audit-grade independent review. It is not as simple as "add a critic to make the agent more accurate." In settings such as financial credit approval, medical diagnosis, legal assessment, and regulatory compliance, independent review is a structural requirement rather than a quality optimization. Frameworks such as SOC 2, HIPAA, FDA, and the EU AI Act explicitly require "different people, different models, different incentives" to do the reviewing; this is the entry ticket to going live, not a bonus. It shares a common origin with single-agent self-examination (Generator-Critic) but operates at a different scale: the former is one LLM process plus two prompts, while the latter requires model routing, independent traces, and cross-vendor billing, an entirely separate set of engineering infrastructure.

Why the coordinate is "Collaboration × Loop"

• Vertical axis · Collaboration: This is two or more independent agents genuinely in opposition, one proposing a solution and another dedicated to finding flaws. It is multi-agent, but with the distinctive structure of an adversarial incentive, not merely a division of labor. The critic must use a different model, a different vendor, and a different prompt incentive; otherwise it degenerates into single-agent self-review.
• Horizontal axis · Loop: The proponent and the critic argue back and forth, propose, object, revise, object again, until the judge converges or the budget runs out. This is the only structural loop within the collaboration group, distinct from the splitting of Hierarchy, the scattering of Parallel, and the passing of Chain.

Core mechanism

A single adversarial review consists of three roles and one loop:

1. Proponent proposes: the generator agent produces the initial solution.
2. Critic objects: an independent critic agent is dedicated to finding problems, with a prompt that makes explicit that "finding problems is not confirmation; finding no issue means you should review again." A critic that finds no problems is a suspicious signal in a high-stakes setting, not a pass signal.
3. Proponent revises: the solution is revised based on the issues the critic raised, and the next round begins.
4. Judge rules: the judge agent synthesizes both sides' arguments and issues the final ruling (approve / conditional / reject).

The three roles use models from different vendors, and each writes its independent trace into the audit log. The number of rounds has a ceiling: 3 agents × 2 rounds is the standard configuration validated in academic experiments, where 2 rounds already converge most improvements; beyond 3 rounds the marginal returns diminish and oscillation is introduced. The capability of the critic and the generator must not differ too much, or the critic will fail to detect the generator's subtle errors. Crossing families matters more than crossing sizes: models from the same vendor have correlated bias distributions and shared blind spots, and only crossing families introduces the perspective of an independent training history.

Suitable production scenarios

• Compliance scenarios with audit-grade independence requirements: financial credit approval, medical diagnosis assistance, legal assessment, regulatory compliance. In these scenarios independent review is the entry ticket to going live.
• Critical decisions where errors are costly: decisions where the cost of error exceeds ten thousand dollars, where trading 9× the cost for an accuracy improvement gives a positive ROI.
• Scenarios where the generator output and the critic share biased training data: single-model self-review is almost ineffective in these scenarios, and an independent cross-family perspective must be introduced.
• The engineering trade-off of saving money for quality: pairing a mid-tier model with a cross-family critic can close a considerable portion of the performance gap against running a top-tier model alone, while the total cost is in fact lower.

Where it tends to go wrong

• Model collusion: nominally cross-vendor, but the critic and the generator share the same batch of web training corpus underneath. "Independent training" is independent on the surface, not in substance, and the two have shared blind spots on certain corner cases. Vendor independence does not equal training-data independence. Critical scenarios should choose models pretrained on different regions and different language corpora, or add a third critic, or attach a compliance human reviewer as the final line of defense.
• Cost cascade explosion: the context accumulates and grows longer each round, and the nominal 9× cost may actually rise to over 30×. Each round's critic context should be truncated to "the task plus the current draft" without history, and the judge runs only once at the end with the full history.
• Sycophancy collapse: the critic's RLHF training makes it default toward being helpful rather than critical, and after running for a while it says "looks good" to seventy percent of generator outputs, so there is opposition in name but no disagreement in fact. The critic prompt must explicitly state "finding no problems is a red flag," monitor the critic's issues_per_turn distribution, and rewrite prompts that stay low for the long term.
• Insufficient diversity in role prompts: when all agents use the same role prompt, multi-agent is actually worse than single-agent. The engineering focus is not piling up the number of agents but designing role diversity.
• Misuse on simple tasks: tasks where the cost of error is below one hundred dollars, such as writing polish, and tasks where deterministic verification is available (tests as a critic are far cheaper than an LLM as a critic), are fine with single-agent self-review and should not invoke adversarial review.

Key metrics

• Vendor independence (healthy zone ≥ 2 different vendors): how many different vendors the participating models come from. Fewer than 2 fails to meet compliance-grade independence, and auditors will cross-check against vendor billing records.
• Critic discovery rate issues_per_turn (healthy zone not persistently zero): the distribution of the number of issues the critic raises per round. Staying near zero for the long term is a signal of sycophancy collapse.
• Number of debate rounds (healthy zone 2-3 rounds): the back-and-forth rounds needed to converge. More than 3 rounds suggests the task may not suit this pattern, or the judge's convergence logic has a problem.
• Cost per decision (accounted by business): the real token cost of three cross-family agents. Monitor the spend per round, and downgrade to single-critic mode when it exceeds the threshold.

Minimal implementation skeleton

AdversarialReview.review(task):
                check vendor independence (≥2 different vendors)   # refuse to run if not met
                proposition = proponent(task)
                for round in 1..MAX_ROUNDS:            # ceiling 3
                    verdict = critic(task, current)    # use a model from a different vendor
                    if verdict.no_issues_found and round==1: continue  # found no problems = red flag
                    if not verdict.issues: break
                    current = proponent(task, current, verdict.issues) # revise
                return judge(task, debate_log)         # synthesize both sides, write audit log

            CritiqueVerdict:
                issues: list           # explicit beats implicit
                severity: minor/major/critical
                no_issues_found: bool  # note: this is a RED FLAG, not a PASS
            

Four engineering points: agent_vendors must genuinely cross vendors (auditors verify against billing); the critic's "treat finding no problems as a red flag" is the core of anti-sycophancy; set MAX_ROUNDS to 3; write the compliance attestation field into the audit log and retain it for 7 years.

Enterprise adoption example

A regional bank's AI decision-assistance system for corporate lending has the agent read a borrower's 43 documents and then recommend approve / reject / approve with added credit support. The first version used a single model plus three role prompts (credit analysis, risk assessment, compliance review), and after half a year the accuracy looked acceptable. But once the SOC 2 audit arrived, the auditor asked three questions: Has this "approve" recommendation gone through independent review? If the same LLM with different prompts was used, how does that count as independent? If regulators impose penalties later, can you produce an audit trail proving that every decision went through independent adversarial review? The engineering team could not answer. This was not a technical problem but a structural one. In the seventh month they completely rebuilt it into adversarial review: the generator used Claude Sonnet to produce the loan recommendation, the critic used GPT-5.4 as the red-team reviewer (with a prompt stating "finding problems is not confirmation; treat finding no issue as a red flag and keep reviewing"), and the judge used Claude Opus to arbitrate. The three agents used models from three different vendors, and each wrote its independent trace into the audit log. In the eighth month they passed the SOC 2 re-review. The cost was that the token cost per decision rose from about $0.30 to about $2.10, a 7× cost for compliant go-live, and in a financial setting that arithmetic is worth it.

Relationship to other patterns

• Generator-Critic (Reflection group): a common origin at a different scale. The former is single-agent self-examination (the same model with different prompts), while the latter is multi-agent independent review (independent agents plus an adversarial incentive plus structural independence). The cost of error, regulatory requirements, and cost budget are the three decision points for upgrading from the former to the latter.
• Fan-out Aggregate (C2): a sibling pattern. Both have multiple agents working in parallel, but the fan-out workers are in a collaborative, complementary relationship, while the adversarial review critic is in an adversarial relationship.
• Parallel Exploration (Reasoning group R3): a cousin pattern, multi-agent in parallel but without the structure of an adversarial incentive.
• N-version programming (classic engineering lineage): adversarial review is its reskinned counterpart in the LLM era. Independent implementations each running on their own plus a judge synthesizing them is equivalent to N-version plus voting.

What the pattern teaches

The essence of adversarial review is not adding a critic to make the agent more accurate, but encoding the procedural justice of humanity's thousands of years of rule-of-law tradition into the agent system. Truth does not emerge from consensus; it emerges from structured disagreement, and independence is a structural requirement, not a quality optimization.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.