Adversarial Pairing: Doer and Reviewer Agent Sessions

Adversarial Pairing runs a doer agent and one or more reviewer agents in separate terminal sessions, coordinating through a shared Markdown blackboard.

Adversarial Pairing sits between solo Pairing mode and the full Multi-Agent System. You run one doer agent and one or more reviewer agents in separate terminals, all coordinating through a shared Markdown blackboard. The doer holds the only coding session; reviewers read the blackboard, inspect submitted artifacts, and issue verdicts — without asking you for each individual review action. The result is peer-agent accountability without the overhead of a full autonomous sprint.

​

When to Use It

High-stakes Pairing changes

Changes that are too risky to rely on a single agent’s judgment — database migrations, auth flows, public API modifications.

Complex debugging

Hard bugs where you want root-cause analysis reviewed by a second agent before the fix is written.

Architectural edits

Structural changes that touch multiple subsystems and benefit from cross-model review before a single line of production code is written.

Full MAS is too heavy

The task is well-scoped and doesn’t need 11+ agents, but a single reviewer is better than none.

​

How It Works

Adversarial Pairing runs multiple standard Pairing sessions against one shared Markdown file — the blackboard. Each session is an ordinary agent terminal:

• One doer session — the only session with permission to write code or make state changes
• One or more reviewer sessions — run autonomously, reading the blackboard and writing verdicts without prompting you for each action

The blackboard tracks the goal, plan, submitted artifacts, review notes, validation output, and final decisions. It’s a coordination surface, not a chat log.

Run reviewers on different model providers whenever possible. When your doer is Claude and your reviewers include Codex (or vice versa), each model’s distinct blind spots become visible. Disagreement between reviewers is useful signal — it surfaces assumptions that a single-provider review would pass silently.

​

Activating Adversarial Pairing

Start the doer session first so it can create and initialize the blackboard. Then open reviewer sessions against the same blackboard path.

Basic setup

Open three terminals in your initialized project directory:

Terminal 1 — Doer:

# In your agent session, run:
/adversarial-pairing doer .liza/adversarial/my-task.md

Terminal 2 — Reviewer (Claude):

/adversarial-pairing reviewer-claude .liza/adversarial/my-task.md

Terminal 3 — Reviewer (Codex):

/adversarial-pairing reviewer-codex .liza/adversarial/my-task.md

The reviewer-<id> form tells each reviewer both its role and the stable ID it registers on the blackboard — useful when running multiple reviewers so their verdicts are clearly attributed.

With yolo flag

If you want the doer to proceed through its own approval gates without pausing for your confirmation each time, add yolo to the doer invocation:

/adversarial-pairing doer .liza/adversarial/my-task.md yolo

yolo skips doer-side human approval gates only. It does not waive reviewer approvals, reviewer stop conditions, validation requirements, or your ability to issue a stop instruction at any time. Reviewer sessions always require agent-to-agent approval before the doer commits.

Setting the goal

If the blackboard file doesn’t exist yet, include a short goal paragraph in your first doer message alongside the activation command:

/adversarial-pairing doer .liza/adversarial/retry-client.md

Goal: Add exponential backoff retry logic to the HTTP client in
src/client.py. Retries should apply to 429, 502, 503, and 504
responses only, with jitter, and be configurable per-caller.

The doer records this goal in the blackboard before planning, so all reviewer sessions start from the same task frame.

​

The Workflow

1. Doer records goal and plan

   The doer reads the task, builds a plan, and writes both the goal and implementation plan to the blackboard. Reviewers can see this immediately.

2. Reviewers challenge the plan

   Reviewer sessions read the blackboard, analyze the plan, and write review notes and verdicts. They challenge assumptions, flag risks, and request changes — they don’t just suggest. A reviewer can block forward progress until its concerns are addressed.

3. Plan approval

   Once reviewers approve the plan (and you approve if not in yolo mode), the doer has permission to write code.

4. Doer implements

   The doer implements the approved plan in its working branch, then submits the candidate diff to the blackboard for code review.

5. Reviewers approve the diff

   Reviewer sessions inspect the submitted diff and either approve or request changes. Follow-up rounds continue until all reviewers approve.

6. Doer commits, rebases, and merges

   After reviewer approval, the doer commits, rebases, and merges into the target branch, then deletes its dedicated worktree and the topic branch. Without yolo, it asks you before each of these git state changes; with yolo, it proceeds unless a stop condition applies.

​

Key Difference from Solo Pairing

In standard Pairing mode, a reviewer’s input is advisory — you make the final call. In Adversarial Pairing, reviewer agents can block progress. A reviewer verdict of “rejected” is not a suggestion; it halts the doer until the concern is resolved. This creates real accountability between agents, not a polite second opinion.

For debugging tasks, you can configure the blackboard to require explicit root-cause analysis and a failing-test gate before implementation begins. That gives you MAS-style diagnostic rigor — diagnosis review and failing-test review — without handing the entire task to the autonomous pipeline.

​

Blackboard Path Notes

The blackboard file path is arbitrary — put it wherever makes sense for your project (.liza/adversarial/ is a reasonable convention). The file is typically untracked and should not be committed unless you explicitly want a record. During coding, the doer normally uses a dedicated git worktree recorded in the blackboard; reviewers inspect the staged or unstaged diff for the current review round.