agent-debate ยท diff
git:20260831.ca20117 to git:20261016.a802ce4
37 added, 61 removed. Audit A to A.
---
name: agent-debate
- description: Use when a consequential decision has genuinely competing positions that need bounded adversarial review before a human decision.
+ description: Use when a consequential decision has two plausible, materially different options and you are about to pick one. Runs two opposed reviewers on the same evidence with a stated round cap, then hands the human a synthesis that names the deciding evidence.
---
# agent-debate
- Run a bounded adversarial review of a consequential trade-off. Debate improves
- the evidence visible to a decision maker; it does not establish truth by vote
- and does not authorize implementation.
-
- ## Preconditions
-
- Use debate only when:
-
- - the positions are both plausible and materially different;
- - the decision is consequential enough to justify independent review;
- - the question can be falsified or informed by identifiable evidence; and
- - the current policy allows the required work.
-
- Do not debate a factual question that can be settled by direct verification, a
- minor naming preference, or a decision already made by an authorized human.
-
- ## Roles
-
- - Independent `reviewer` task packets argue named positions.
- - A `synthesizer` compares their evidence without external tool access unless
- the plan explicitly grants it.
- - The `primary-agent` records the recommendation and presents it to the human.
- - The human approves, declines, or requests revision.
+ A bounded adversarial review of one consequential trade-off. Debate makes the
+ evidence visible to the decision maker; it does not settle truth by vote and
+ does not authorize implementation.
- Provider and model names belong to host-adapter metadata, not the public debate
- contract.
+ ## Use only when
- ## Workflow
+ - both options are plausible and materially different;
+ - the decision is consequential enough to justify two independent reviewers;
+ - identifiable evidence could inform or falsify each side.
- 1. Define the decision, alternatives, known facts, disputed assumptions,
- evidence standard, and human decision owner.
- 2. Evaluate policy before every reviewer spawn. Persist a required checkpoint
- before continuing.
- 3. Give each reviewer the same evidence packet plus one position to steel-man.
- Reviewers are argument-only and must not modify source files.
- 4. After each plan-act-reflect cycle, update the `TaskCheckpoint` and evaluate
- policy. Stop immediately when policy says `stop`.
- 5. Filter missing or failed reviewer outputs, but record their status. Never
- invent the absent side.
- 6. Have the synthesizer separate agreed facts, contested claims, evidence
- quality, uncertainties, and falsifiable conditions that would change the
- recommendation.
- 7. Present the synthesis to the human decision owner. No implementation or
- canonical-memory update occurs without an explicit recorded decision.
+ Do not debate a factual question that a direct check can settle, a naming
+ preference, or a decision an authorized human already made.
- All cycle, context, concurrency, and transcript limits come from the canonical
- machine-readable policy. Do not hardcode them in task packets or prose.
+ ## Setup
- ## Output
+ 1. Write one evidence packet: the decision and who owns it, the two
+ positions as testable statements, shared evidence paths, and the criteria
+ for judging. Template: [references/debate_protocol.md](references/debate_protocol.md).
+ 2. Launch two `reviewer` lanes in parallel, one position each, both on a
+ strong model tier, both read-only, both with the same packet. Each argues
+ the strongest form of its side and cites evidence.
+ 3. State the round cap before launch and stop there. A rebuttal round, if
+ the cap allows one, answers the other side's strongest point. In harness
+ mode the policy's `max_cycles` limit sets the cap; evaluate the policy
+ before each reviewer spawn.
+ 4. A reviewer that changes its conclusion says so plainly; do not simulate
+ disagreement.
- Produce a scratch debate record containing:
+ ## Synthesis
- - decision and alternatives;
- - policy and checkpoint references;
- - each position's claims and evidence references;
- - missing or failed reviewer records;
- - agreed facts and contested points;
- - synthesizer recommendation, uncertainty, and what would change it;
- - pending human decision.
+ The primary-agent, or a separate `synthesizer` with no search tools, writes:
- If the outcome may be useful later, emit a memory proposal. The proposal may
- become canonical only after an explicit human decision; resolution appends a
- new event and never rewrites an earlier memory record.
+ - agreed facts, with evidence;
+ - contested claims, with the evidence on each side;
+ - missing or failed reviewer outputs (recorded, never invented);
+ - a recommendation, how uncertain it is, and what finding would change it;
+ - the pending human decision: approve, decline, or revise.
- See `references/debate_protocol.md` for task framing.
+ Nothing is implemented and no canonical memory changes until the human
+ decides. If the outcome is worth keeping, write a memory proposal as described
+ in `agent-context-budget`.
## Prohibitions
- - No majority vote as an evidence or acceptance mechanism.
- - No silent retry, model switch, context discard, or missing-result coercion.
- - No implementation, source mutation, commit, merge, or push during debate.
- - No direct write, overwrite, archive, or deletion of canonical memory.
+ - No majority vote as evidence or acceptance.
+ - No silent retry, model switch, context discard, or invented missing side.
+ - No source edits, commits, merges, or pushes during the debate.
+ - No direct write to canonical memory.