Why a Text File Is Not a Debate Protocol

There is a moment in multi-agent work where the human becomes the weakest coordination layer.

Not because the human judgment is bad.

Because the human becomes the message bus.

One terminal has the conductor role. Another terminal is executing the fix. A third agent is acting as devil's advocate. One may be Claude Code, one may be Codex, one may be another MCP-capable runtime. The plan is real. The work is ambitious. The code is risky enough to deserve adversarial review.

And then the workflow collapses into copy and paste.

There is a new message.
Read this.
Answer that.
Did you see the objection?

That is not collaboration. That is a human acting as a radio operator in a blackout.

A plain text file can help. It can seed context. It can hold a transcript. It can be copied into three sessions so everyone starts from the same brief.

But a text file is not a debate protocol.

It does not know who is addressed. It does not know what each role has already processed. It does not know which answer closes which question. It does not know whether a decision is standing guidance or a one-shot task. It does not know whether a worker accepted the mission, duplicated another worker, found no issue, or disappeared.

Complex agent work needs more than shared text.

It needs coordination state.

Repo: https://github.com/RMANOV/sqlite-memory-mcp

The real use case

The practical use case is not abstract.

Imagine a heavy release-hardening task.

The CONDUCTOR frames the mission: identify the highest-risk bug path, keep the scope narrow, avoid unrelated refactors, and preserve the reason for the final decision.

The EXECUTOR takes implementation work: inspect the code, patch the minimal surface, run the relevant tests, return evidence.

The ADVOCATE attacks the plan: find false assumptions, missing tests, parser edge cases, lifecycle bugs, misleading public claims, and anything that would embarrass the release after publication.

This division is useful only if the state survives the sessions.

If the advocate catches a lifecycle bug, that objection must not remain trapped in one chat. If the executor fixes it, the answer must be connected to the question. If the conductor resolves the topic, the reason must be stored beside the state transition, not reconstructed later from memory.

That is what the Debate Protocol in sqlite-memory-mcp is built to support.

What the protocol stores

The protocol turns a debate into structured SQLite state.

At its core are durable topics, append-only messages, lifecycle state, role-aware cursors, addressed recipients, signal state, role bindings, worker claims, reclaim logs, and no-action closure.

The useful roles are simple:

• CONDUCTOR: owns the goal, scope, routing, state, and acceptance criteria.
• EXECUTOR: performs bounded work and returns evidence.
• ADVOCATE: searches for failure modes, false claims, missing tests, and public-risk statements.

The point is not to make agents agree.

The point is to make disagreement durable.

A transcript can say:

Someone objected to the release.

A debate protocol can show:

CONDUCTOR opened the topic.
ADVOCATE asked a high-priority question.
EXECUTOR answered with a code change and test evidence.
ADVOCATE found no remaining objection or filed a new challenge.
CONDUCTOR moved the topic to RESOLVED with the reason attached to the STATE row.

That is a different class of artifact.

It is not chat history.

It is a coordination ledger.

Why the release line matters

The current GitHub release line matters because the protocol has moved beyond a simple message log.

The v3.9 series established the core debate shape: durable topics, messages, state transitions, watermarks, Q/A flow, compaction, and validation. It also hardened important edge cases, including strict watermark parsing and transition-reason persistence.

That transition-reason fix is small but important.

If a topic becomes RESOLVED, the reason cannot be a fragile afterthought written in a separate row that may be blocked by the lifecycle gate. The reason has to travel with the state:

RESOLVED [reason: all blocking questions answered]

That makes the decision auditable.

The v3.10 series added the first wake and binding layer: role/session bindings, recipient modes, wake dry-run planning, hook support, and a resident pump fallback. That is where the system starts addressing the manual signaling problem directly.

The v3.11 series added worker-claim discipline: sessions can claim work, one-shot decisions can be protected from duplicate processing, stale claims can be reclaimed safely, and a worker can explicitly close with no substantive action.

That last feature matters more than it sounds.

In real adversarial review, a good devil's advocate often finds no blocker. That is not empty work. It is a useful terminal result. If the system cannot record "I checked this and found no objection," it leaves stale claims and forces the next agent to rediscover the same absence.

No-action closure turns disciplined silence into state.

Note: the GitHub release line reaches v3.11.4. The package metadata in pyproject.toml may lag that release line, so this article describes the repo/release line, not a PyPI package claim.

What this saves

The obvious saving is time.

The human stops manually pasting messages across terminals.

But the deeper saving is correctness.

A structured debate protocol reduces common multi-agent failure modes:

• missed objections;
• duplicate worker effort;
• answers detached from questions;
• stale tasks that look active;
• state transitions with missing reasons;
• future sessions starting from a vague recap;
• public release notes written without the adversarial context that shaped them.

That is why the devil's advocate role is not theater.

A good ADVOCATE is a bug-finding surface. It challenges the parser, the lifecycle, the assumption, the test gap, and the claim that sounds good but is not yet supported by code.

When that challenge is stored as structured state, it becomes reusable engineering evidence.

What this is not

This is not a claim that autonomous multi-agent software teams are solved.

They are not.

This is not a claim that a hook can wake every provider perfectly in every environment.

Adapters remain runtime-specific. Different tools have different lifecycle constraints. Human judgment still owns the final decision.

The useful claim is more grounded:

sqlite-memory-mcp provides the coordination substrate that a serious multi-agent workflow needs before it can be trusted: roles, addressed messages, cursors, claims, state transitions, compaction, no-action closure, and auditability.

That is already enough to change the workflow.

The difference from a text file

A text file is passive.

It waits to be read.

A debate protocol is active state.

It can answer operational questions:

• What is open?
• Who is addressed?
• Which role has processed which message?
• Which task has been claimed?
• Which claim is stale?
• Which answer closes which question?
• Why did this topic become resolved?
• What should the next session read first?

This is the difference between storing words and coordinating work.

For simple tasks, a text file is enough.

For complex engineering work across multiple agents and providers, it is not.

The next useful primitive is not a smarter prompt.

It is a durable room where the plan, the work, the objection, the answer, and the final state can all survive the next session.

That is the Debate Protocol.

Repo: https://github.com/RMANOV/sqlite-memory-mcp