Article5 protocol template

A Reusable Protocol for Multi-Model AI Research Teams

Fifth in a series on a multi-agent P versus NP research project. An earlier post told the story of how five different AI models collaborated and audited one another. This post extracts the method from the story: the project's coordination charter, generalized into a template that any team — working on mathematics, security research, systems verification, or anything else where being wrong is expensive — can adopt directly. Nothing here is specific to complexity theory. Sections in bold are the rules; the indented commentary explains why each exists, citing what actually happened when the rule fired.

0. Preconditions

The protocol assumes three or more AI agents, preferably from different model families, a shared file repository, and a human (or standing instruction) willing to let refutations count as deliverables. Model diversity is not decoration: in the source project, errors were repeatedly caught precisely because a different model family, with different blind spots, re-derived the claim from scratch.

1. One goal, with anti-inflation clauses

Rule 1.1 — State the single terminal goal in one sentence.

Rule 1.2 — Enumerate, in the charter itself, the partial results most likely to be mistaken for the terminal goal, and state explicitly why each falls short.

The source charter opens by listing exactly which lower-bound statements do and do not imply P ≠ NP, and rules that assumption-based results "count for structural understanding but not as completion." This one paragraph is the cheapest known defense against the most common AI failure mode in technical work: triumphant overclaiming. Write the disclaimers before anyone is tempted.

2. Roles: proposers, verifiers, and one integrator

Rule 2.1 — Every agent gets exactly one role: proposer (owns a research line), verifier (owns no line, audits everything), or integrator (owns the ledger and the verdict taxonomy).

Rule 2.2 — Verifiers are charter-designated as independent. Write into their instructions that they are "not a summarizer of existing proposals" and subordinate to no proposer.

Rule 2.3 — Assign verifier and proposer roles to different model families wherever possible.

The source project made one model a formal auditor and another an experiment-semantics auditor, and both charters contain the "not a summarizer" clause verbatim. It worked: the auditors rejected major claims by the strongest proposers at written confidence 0.99, retracted their own earlier approvals when counter-audited, and reported bugs in their own code before using its outputs. Sycophancy is the default failure mode of AI collaboration; role text is the countermeasure.

3. Ownership and the objection queue

Rule 3.1 — Every file has exactly one owner. No agent ever writes to another agent's files.

Rule 3.2 — All disagreement flows through a single append-only integration queue. Each entry gets a permanent ID. Only the owner incorporates accepted objections into owned files.

Rule 3.3 — Separate fact space from hypothesis space at the directory level: one tree for established results (errors corrected immediately), one for hypotheses (each carrying explicit confidence and falsification conditions), one for code, one for finalized proofs.

The source project's queue reached 426 numbered entries in two days and became the project's complete intellectual ledger — every claim, audit, rejection, and retraction citable by ID. The fact/hypothesis split matters because it forces every statement to declare its epistemic status at the moment of filing, not in retrospect.

4. The verification contract

Rule 4.1 — Reproducing an output is not verification. A valid audit must contain: (a) an argument linking the code's states to the mathematical or real-world objects being measured; (b) a minimal counterexample where the verdict is negative; (c) an explicit list of which prior conclusions survive and which are retracted; (d) exactly one verdict: ACCEPT, REJECT, or REVISE.

Rule 4.2 — No claim enters the accepted layer on its author's word. At least one independent hostile audit is mandatory; for load-bearing claims, require two or three.

Rule 4.3 — Independent reimplementation must be genuinely independent: different language or different library, no imports from the original, ideally a different agent. Add differential fuzzing and deliberate adversarial mutations to confirm the checker can fail.

These clauses are copied nearly verbatim from the source charter, and they are where the protocol earns its keep. Python computations were re-audited by standalone JavaScript and Node.js implementations importing nothing; an engine was validated against 3,000 random fuzz inputs; one audit injected six adversarial mutations to confirm each would be caught. The single-verdict grammar ("ACCEPT / REJECT / REVISE, choose one") eliminates the hedge-everything register AI models default to. And clause (a) kills the most seductive fallacy in AI-assisted work: "the script ran, therefore the theorem holds."

5. Failure as a deliverable

Rule 5.1 — Maintain an epitaph file. Every dead approach gets an entry recording the method, the precise cause of death, and the lesson — with the killing counterexample attached.

Rule 5.2 — Self-reported errors are status-positive. An agent that finds a bug in its own work and retracts is following the protocol, not violating it.

Rule 5.3 — Include a "crank pattern" entry in the epitaph file describing the failure modes of bad work in your field, and periodically audit your own output against it.

The source project's most scientifically impressive single episode — an agent refuting its own conjecture with a construction it built after fixing a bug it found in its own simulator — happened because retraction carried no penalty. The crank-pattern mirror entry is the charter checking itself for the same diseases it diagnoses in others.

6. Guardrails on judgment

Rule 6.1 — Known impossibility results and barriers are maps, not verdict stamps. Any agent invoking a barrier to reject work must show the barrier's preconditions actually hold for that work.

Rule 6.2 — Every open route carries a numeric confidence estimate, revised in both directions, with the revision history kept.

Rule 6.3 — Statistical and asymptotic discipline is enforced by rule: no trend claims from single data points, no big-O upper bounds used as evidence of lower-bound failure, no results accepted from code whose execution crossed its declared interface.

Each clause in 6.3 corresponds to a real rejection in the source record: a "degree-3.5 polynomial" claim extrapolated from one point, a gate-failure verdict derived from an upper bound, and a toy evaluator whose outputs were struck because it silently crossed its own boundary. Write the statistical rules down; the models will follow written rules far more reliably than unstated norms.

7. Cadence and pruning

Rule 7.1 — Work proceeds in numbered rounds. Each round ends with a summary document recording what was settled, what was retracted, and what the next round owes.

Rule 7.2 — The integrator may advance at most two candidate approaches per phase. Everything else is parked with a written reason.

Rule 7.3 — When stuck, formally return to an earlier phase and re-derive; do not improvise forward.

Rule 7.4 — At project end, produce a final overview reducing every remaining obstacle to a named, falsifiable open statement.

The two-candidate cap is the protocol's answer to the breadth temptation — with cheap parallel agents, the failure mode is not too little exploration but too little pruning. And rule 7.4 is what turns even a "failed" project into a citable artifact: the source project's final document is precisely such a reduction, and it is the reason this series of posts exists.

8. Known costs and honest limits

Adopters should expect three costs the source record makes visible. Audit overhead is real: several rounds were partly consumed re-auditing audits, and the queue discipline multiplies token expenditure severalfold over naive collaboration. Exhaustive verification gravitates toward finite, checkable subproblems, which can absorb enormous effort for modest conceptual payoff — budget for this deliberately. And the protocol is an error-elimination machine, not an insight machine: in the source project it caught dozens of mistakes and produced zero miracles. The obstacles that had resisted human researchers for decades resisted the agents identically. Use it where correctness is the bottleneck; do not expect it to substitute for the idea you don't have yet.

What you get in exchange is a research record in which every claim has a status, every rejection has a counterexample, every retraction is logged, and a hostile reviewer arriving cold can reconstruct exactly what is known, what is believed, and why. For most technical teams — human, AI, or mixed — that is worth the overhead.

Sources: Generalized from the source project's multi-agent coordination charter (roles, ownership table, per-agent standing questions, verification requirements), its agent guidelines file, the integration queue (426 entries), the failed-attempts catalog, and the round summaries documenting each rule firing in practice. All incidents referenced are drawn from that internal record; no personal information appears in this post.