Pattern Matrix/White Paper/C3

Problem

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 receives structurally independent scrutiny. In financial credit, medical assistance, legal assessment, and regulatory workflows, the required form of independence comes from the applicable policy and the reviewing organization; using several prompts or vendors does not by itself prove compliance. Compared with single-agent Generator-Critic, this pattern also needs model routing, separated context and evidence, independent traces, and an explicit adjudication contract.

Classification: Collaboration × Loop

• Vertical axis · Collaboration: This is two or more independently configured agents in opposition, one proposing a solution and another dedicated to testing it. Independence may come from model family, context, evidence source, runtime, prompt incentive, or organizational ownership. A vendor difference is one possible signal, not a sufficient condition.
• 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.

Solution and mechanics

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).

Each role writes a separate trace into the audit log. Review rounds need a hard ceiling based on risk and budget. The critic must be capable of testing the generator's subtle errors, and the judge needs the evidence contract required to settle disputes. Cross-family routing can reduce some shared blind spots. Independence also depends on context, data sources, runtime separation, and human accountability.

Applicability

• 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: Use it when expected loss, regulatory responsibility, or safety risk justifies independent review overhead.
• 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.
• Model-combination trade-offs: A mid-tier generator plus an independent critic may outperform a single expensive call on some tasks, but that comparison must be run on the target evaluation set.

Known failure modes

• 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: Context grows when every round carries the full debate history. Give the critic the task, current draft, and required evidence; give the judge a structured debate log at final adjudication.
• Sycophancy collapse: A critic may default to agreement, leaving opposition in name only. Monitor issues_per_turn together with false-positive findings and expert review. A critic that never finds substantive issues and one that always invents them are both miscalibrated.
• 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: Low-risk writing polish and tasks with deterministic verification usually do not justify multi-agent adversarial review. Tests, schemas, or a single calibrated critic are more direct.

Verification and metrics

• Independence evidence: Record differences in models, prompts, evidence sources, runtime, and organizational roles. Vendor diversity is only one piece of evidence.
• Critic discovery rate (issues_per_turn): Analyze it together with phantom issues and expert sampling. Persistently empty or persistently fabricated findings both signal poor calibration.
• Debate rounds: Observe the convergence distribution and cap exhaustion. Repeated non-convergence calls for a better judge, evidence contract, or exit from the pattern.
• Cost per decision: Measure the real token, latency, and review cost of the chosen configuration and compare it with the risk budget.

Reference implementation

AdversarialReview.review(task):
                check independence_policy             # model, context, evidence, runtime, or role
                proposition = proponent(task)
                for round in 1..MAX_ROUNDS:            # configured risk and cost ceiling
                    verdict = critic(task, current)
                    if requires_second_review(verdict): continue
                    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  # valid only when supported by the review trace
            

Production implementation should record model versions, prompts, evidence sources, and runtime identity; define when an empty critic verdict requires a second review; configure MAX_ROUNDS from task risk and cost; and retain compliance attestations according to the applicable policy.

Illustrative scenario

Consider a bank's loan-decision assistance system. A first version asks one model to play credit analyst, risk reviewer, and compliance reviewer. Different role prompts do not establish structural independence. A later design separates the generator, critic, and judge by model or evidence source, retains each trace, and writes the final ruling and human approval into the audit record. Whether this satisfies an audit depends on the bank's policy and the auditor's accepted evidence; it cannot be inferred from the number of models alone.

Related 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.

Design conclusion

Adversarial review organizes disagreement through independent roles, evidence, and an explicit ruling rule. Independence is a structural claim that the system must demonstrate, not a label earned by adding another prompt.