> ## Documentation Index > Fetch the complete documentation index at: https://lizamas.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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 > [card] 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. > [card] 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. > [card] 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. > [!TIP] > > 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 > [tab] Doer terminal > > ```bash theme={null} > # 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. > [tab] Reviewer terminal > > ```bash theme={null} > # 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. > [!NOTE] > > 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** ```bash theme={null} 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. > [!WARNING] > > 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 | > [!NOTE] > > 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.