Liza's Three Operating Modes: Pairing to Multi-Agent

Choose between Pairing, Adversarial Pairing, and Multi-Agent modes depending on how much autonomy and human oversight you want during a coding session.

Liza gives you three operating modes. Each one places the same behavioral contract on every agent — the difference is how much autonomy you delegate, how many agents are running, and where the approval authority sits. You pick the mode that matches the risk profile and pace of your current work, and you can switch between them as that profile changes across different tasks or sprints.

​

Overview

Pairing

One agent, one human. You approve every significant action before it happens. Best for exploratory work, unfamiliar codebases, and decisions with high product density.

Adversarial Pairing

A doer agent and one or more reviewer agents coordinate through a shared Markdown blackboard. Best for high-stakes changes where you want adversarial review without running the full pipeline.

Multi-Agent

A fully autonomous pipeline from goal to merged code. Thirteen specialized roles across four phases. You review artifacts at sprint checkpoints; agents handle everything between them.

​

Pairing Mode

Pairing is where Liza started. You work directly with a single agent under the behavioral contract — the agent brings senior-level judgment, you bring product intent. Every state-changing action goes through an Approval Request before execution: the agent writes down its intent, its validation plan, and any assumptions, then waits for your explicit approval before touching any files.

This is not just a safety gate — it is also a quality gate. Externalizing the reasoning before acting surfaces problems that would otherwise only appear after a diff has grown. Agents that must write “I will try random things until something sticks” in a structured plan rarely proceed with that plan.

Use Pairing when:

• You are making product decisions and want the agent as a Socratic Coach or Challenger
• You are in an unfamiliar codebase and want to stay in the loop on every change
• You are doing exploratory, spike, or research work where requirements are still forming
• You want the lowest-overhead entry point to Liza’s contract system

1. Start a session

   Open your coding agent (Claude Code, Codex CLI, or another supported provider) in your project directory. The agent reads CORE.md and PAIRING_MODE.md at session start before responding to anything.

2. Set the collaboration mode

   Choose a posture for the session: User Duck (agent helps you think out loud), Socratic Coach (agent asks clarifying questions), Challenger (agent stress-tests your plan), or Autonomous (agent executes with minimal ceremony on low-risk tasks).

3. Approve actions at the gate

   Before any state-changing action, the agent produces an Approval Request: intent, validation plan, assumptions, doc and test impact. You approve, redirect, or descope. After approval, the agent executes.

4. Review the DoD

   When the agent reports done, it presents the full Definition of Done checklist — code, tests, docs, pre-commit, and validation output. You confirm or request changes.

Pairing mode supports Magic Phrases — shorthand commands that trigger specific contract behaviors without lengthy explanation. For example, a phrase can trigger the debugging protocol, request a retrospective, or switch collaboration mode mid-session.

​

Adversarial Pairing Mode

Adversarial Pairing runs a doer agent and one or more reviewer agents in separate terminals, coordinated through a shared Markdown blackboard. It gives you the adversarial review dynamic of Multi-Agent mode without the full pipeline infrastructure — useful when you have a specific high-stakes change and want a second opinion that is structurally independent of the author.

The doer implements and submits. The reviewer examines the diff, issues a verdict, and provides structured comments (file, line, defect, fix). The doer addresses feedback and resubmits. You remain the approval authority for phase transitions unless you invoke with the yolo flag, which waives doer-side human approval prompts while leaving reviewer verdicts, validation, and stop conditions intact.

Use Adversarial Pairing when:

• You have a specific change (a PR, a refactor, a security-sensitive area) that warrants independent review
• You want Multi-Agent-style adversarial dynamics without setting up a full autonomous pipeline
• You want to coordinate two agents using different providers to get cross-model reviewer diversity

Doer terminal

# Start the doer agent in your project directory
# Pass the shared blackboard path as argument
/adversarial-pairing doer ./adversarial-blackboard.md

The doer reads the blackboard, runs analysis, produces a plan for your review, then implements and submits once the plan is approved.

Reviewer terminal

# Start a reviewer in a separate terminal
# Use a stable ID when running multiple reviewers
/adversarial-pairing reviewer-codex ./adversarial-blackboard.md

The reviewer polls the blackboard every 60 seconds. When the doer submits, the reviewer examines the diff and returns a verdict with structured comments.

The blackboard file is shared coordination state and should not be committed to git unless you explicitly want an audit trail of the review session.

​

Multi-Agent Mode

Multi-Agent is Liza’s fully autonomous pipeline. You provide a goal document; Liza decomposes it into epics, user stories, architecture, and implementation plans through adversarial role pairs, then executes coding tasks in parallel git worktrees. You interact at sprint checkpoints between pipeline phases — reviewing the artifacts produced, steering the next sprint, and answering questions the agents have surfaced.

The pipeline runs across four phases. Every phase uses a doer/reviewer pair: nothing progresses without a binding approval from an independent reviewer agent. The orchestrator decomposes work, detects blocked tasks, and triggers escalations. A deterministic Go supervisor enforces state transitions that agents cannot circumvent.

Use Multi-Agent when:

• You have a well-defined goal and want agents to own the full path to merged, tested code
• You are building a feature or system that warrants a spec-first approach with epics and user stories
• You want to run multiple coding tasks in parallel on isolated branches
• You are comfortable reviewing artifact checkpoints rather than individual agent actions

1. Write a goal document

   Describe the problem, the users, the expected behavior, and the scope boundary. Use Pairing mode’s Coach or Challenger postures to stress-test the goal before handing it off. The goal document is where every product decision lives — ambiguities resolved here prevent wrong turns downstream.

2. Initialize and start

   liza init          # initialize the project
   liza start         # start the pipeline from the goal document
   liza tui           # open the terminal UI to observe live state
   
3. Spawn agents per role

   Open terminals for each agent role as the orchestrator creates tasks. The TUI shows which roles need agents, the current state of each task, and the blackboard in real time.

4. Review at checkpoints

   Between pipeline phases, Liza pauses and presents the produced artifacts — epics, user stories, architecture documents, implementation plans. You review, steer, and resume. Agents remain paused until you respond.

5. Inspect merged results

   When all coding tasks merge to the integration branch, the integration analyst runs a cross-task review. You receive a final checkpoint before the sprint closes.

Multi-Agent mode is fully autonomous within a sprint. Agents merge code to the integration branch without asking you first — that authority belongs to the code reviewer role, which is a separate agent from the coder. Review the goal document carefully before starting a sprint.

​

Mode Comparison

	Pairing	Adversarial Pairing	Multi-Agent
Human interaction	Approves every gate	Approves phase transitions	Reviews sprint checkpoints
Agent count	1	2+ (doer + reviewers)	Up to 13 across 4 phases
Review mechanism	Human approval request	Structured peer verdict	Binding peer verdict (Go-enforced)
Approval authority	Human	Human (or yolo for doer)	Reviewer agent + Go supervisor
Parallelism	Sequential	Sequential	Parallel worktrees per task
Infrastructure	None	Shared Markdown file	state.yaml blackboard + worktrees
Best for	Exploratory, high-density decisions	High-stakes specific changes	Spec-driven feature development
Entry barrier	Lowest	Low	Requires goal document + setup

All three modes use the same behavioral contract. Tier 0 invariants — no fabrication, no test corruption, no unvalidated success — apply regardless of the mode you choose.