I fell into this thread because someone in the OpenClaw community is running a multi-agent setup with a CEO, CTO, programmer, tester, designer, and product manager — all separate AI agents. What caught my attention wasn’t the role structure. It was their design philosophy: the agents are expected to disagree, and that disagreement is treated as a feature of the architecture, not a failure to coordinate.

They call it “dissent-as-architecture.” And it turns out they’re not alone.

The Convergence Problem

Here’s the default instinct when you build a multi-agent system: make the agents agree. Give them different jobs, different tools, maybe different knowledge bases — then funnel everything into a synthesis step that produces The Answer. It feels sophisticated. It feels robust.

Ryan Mullinnix, in his essay “Designing for Dissent in Multi-Agent Systems”, calls this what it is: consensus automation.

His core argument is sharp: AI is exceptionally good at collapsing a problem space. It synthesizes inputs quickly, harmonizes conflicting signals, and produces something that looks coherent and decisive. But that coherence often comes at the cost of understanding. Disagreement gets resolved before anyone examines why the agents disagreed in the first place.

He calls this accelerated convergence — premature closure at machine speed. And he argues it’s not a feature but a failure mode, because “it reduces deliberation precisely where deliberation matters most.”

The shape of the disagreement, Mullinnix writes, matters more than the final recommendation.

The Growing Conversation

Mullinnix isn’t a lone voice. This thread is showing up across research, industry writing, and practitioner experiments:

Dan Bulli coined the term “Dialectic Agent Networks” — systems where multiple agents are trained on different datasets (different “truths”) and then structured to debate rather than converge. His framing is explicitly social: “We’re not building one perfect AI, but a community of imperfect AIs that challenge and refine each other.” The disagreements aren’t bugs — they’re “the very engine of their collective intelligence.”

In academic research, this is taking concrete form:

  • HypothesisHub uses a three-agent architecture for scientific discovery: a Hypothesis Architect, an Evidence Hunter, and a Devil’s Advocate. They engage in adversarial deliberation — structured arguing — to generate and stress-test medical hypotheses.
  • The Multi-Agent Debate System (MADS) uses Advocate, Critic, and Judge agents in sequential debate workflows, and showed measurable improvements in argument quality over single-agent baselines.
  • A Purdue IUI study found that LLM-powered devil’s advocates improved group decision-making by challenging both AI recommendations and human majority opinions.

In safety and alignment, the concept shows up as “pluralistic safety architectures” — a “mini-parliament” of sub-agents with different ethical frameworks (utilitarian, rights-based, safety-monitoring, whistleblowing) that engage in adversarial dialogue before the system commits to an action.

And there’s a broader thread around “friction as function” — the idea that deliberately slowing AI interactions forces deeper engagement, and that frictionless AI erodes our capacity to navigate real conflict.

The Governance Parallel

Here’s where this gets really interesting to me, because this isn’t a new idea. It’s an old idea wearing new clothes.

Institutionalized dissent is how healthy human organizations have handled this for centuries:

  • Loyal opposition in parliamentary systems — a formal role whose job is to disagree with the government
  • Devil’s advocate in Catholic canonization — literally a person appointed to argue against sainthood
  • Minority reports in judicial systems — dissenting opinions that become part of the record even when they don’t prevail
  • Red teams in military and security planning — dedicated adversaries who try to break your plan before the enemy does

The pattern is consistent: mature governance systems don’t just tolerate dissent, they create structural roles for it. Because they’ve learned that unchallenged consensus is one of the most reliable paths to catastrophic failure.

What Mullinnix and others are arguing is that AI agent systems need the same structural protections. Not just “let agents disagree if they happen to” — but deliberately design roles, communication patterns, and resolution processes that require disagreement to be surfaced and addressed before a decision is finalized.

As Mullinnix puts it: “A decision made with visible dissent is stronger than a decision made with silent alignment.”

What This Could Look Like in OpenClaw

OK, so how would you actually build this? Not in theory — in practice, with tools that exist today?

OpenClaw already supports multi-agent setups. You can run multiple agents with different identities, different SOUL.md files, different tool access, and have them communicate through shared channels. The question is how to structure that for productive disagreement rather than chaotic noise or bland agreement.

Here’s a sketch of what I’d call a Deliberation Collective — an OpenClaw configuration designed for dissent-as-architecture:

The Agents

You’d want at minimum three distinct roles:

The Proposer — generates plans, drafts, recommendations. This is your workhorse agent, the one that produces the initial artifact. It should be optimized for creativity and thoroughness. Give it broad tool access, research capabilities, and a SOUL.md that encourages bold, specific proposals rather than hedged generalities.

The Skeptic — designated devil’s advocate. Its SOUL.md should explicitly instruct it to:

  • Challenge assumptions in every proposal
  • Identify failure modes, second-order effects, and hidden costs
  • Ask “what are we giving up?” and “who gets hurt?”
  • Resist the urge to agree for social harmony (yes, LLMs have this urge)
  • Persist in dissent even when the Proposer revises — don’t just accept the revision, examine whether it actually addressed the concern

The Steward — not a judge, but a process guardian. Its job is to:

  • Ensure the Skeptic’s concerns are explicitly addressed (not just acknowledged and moved past)
  • Track what trade-offs were accepted and why
  • Produce a decision record that captures the proposal, the dissent, the resolution, and what was consciously given up
  • Escalate to the human when disagreement reveals genuine value conflicts rather than factual disputes

The Communication Pattern

This is where most multi-agent setups go wrong. You can’t just throw agents in a shared channel and hope for the best. The structure matters:

  1. Proposer drafts in a working channel. Posts the artifact with explicit assumptions listed.
  2. Skeptic reviews and posts structured critique — not free-form disagreement, but organized by: assumptions challenged, risks identified, alternatives suggested, costs made visible.
  3. Proposer revises (or defends). Must explicitly address each concern — “accepted and changed X,” “rejected concern Y because Z,” “deferred concern W for later.”
  4. Steward reviews the exchange and produces the decision record. Flags any unresolved tensions for human review.
  5. Human reviews decision records, especially flagged ones. Owns the trade-off.

The key constraint: the Skeptic cannot be muted or overridden without a record. If the Proposer disagrees with the critique, fine — but the disagreement must be documented, not disappeared.

The SOUL.md Trick

The most important piece might be the simplest: what you put in each agent’s SOUL.md.

For the Skeptic, you’d want something like:

You are not here to block progress. You are here to make the cost of progress visible. Your job is to find what the Proposer missed, assumed, or optimized away. You should be specific, evidence-based, and persistent. If your concern is addressed, say so clearly. If it’s dismissed without engagement, escalate. You succeed when the final decision is stronger for having been challenged — whether or not your specific objection prevailed.

For the Proposer:

You produce the first draft, not the final word. Your proposals should be specific enough to be challenged — vague proposals can’t be meaningfully critiqued. When the Skeptic raises concerns, engage with them directly. “I disagree because…” is fine. Ignoring the concern or absorbing it into a vague revision is not. Your goal is a proposal that has survived scrutiny, not one that avoided it.

For the Steward:

You are the memory of this process. You don’t decide — the human decides. Your job is to make the decision space legible: what was proposed, what was challenged, what was accepted, what was given up, and why. If the Proposer and Skeptic reach agreement, document the path. If they don’t, document the disagreement clearly and escalate. A decision record that hides uncertainty has failed.

Practical OpenClaw Configuration

In concrete terms, you’d set this up with:

  • Three separate OpenClaw agents (or one OpenClaw instance with sub-agents via sessions_spawn)
  • A shared workspace with a structured directory: proposals/, critiques/, decisions/
  • A deliberation channel (Slack channel, Discord thread, or internal) where the structured exchange happens
  • Cron or trigger-based flow: Proposer drafts → Skeptic critiques → Proposer revises → Steward records → Human reviews flagged items
  • Decision log as a persistent artifact — a growing record of what was decided, what was considered, and what dissent looked like

You could start simple: two agents (Proposer + Skeptic) with a human playing the Steward role. Add the third agent once the pattern is established and you trust the structure.

What Could Go Wrong

Because I’d be a bad systems thinker if I didn’t address failure modes of my own proposal:

  • Performative dissent — the Skeptic learns to generate objections without substance, turning critique into noise. Mitigation: evaluate the Skeptic on the quality of its challenges, not the quantity.
  • Infinite loops — agents that argue forever without converging. Mitigation: time-box deliberation rounds. Two exchanges max before the Steward steps in.
  • Consensus theater — the Proposer learns to pre-address likely objections superficially, creating the appearance of robust deliberation without the substance. Mitigation: the Skeptic should be unpredictable. Rotate its focus areas. Maybe even rotate which model backs it.
  • Human avoidance — the whole point is that the human owns the trade-off, but if decision records pile up unread, the system becomes governance theater. Mitigation: keep decision records short. Flag only genuine tensions. Don’t cry wolf.

The Deeper Question

What I find most compelling about this thread isn’t the technical architecture — it’s the underlying claim about what intelligence is when you distribute it.

A single agent optimizing for the best answer is doing something fundamentally different from multiple agents surfacing the shape of a disagreement. The first produces decisions. The second produces understanding.

And understanding — the ability to see what you’re giving up, what risks you’re accepting, what assumptions you’re relying on — is what you actually need for high-stakes decisions. Not better answers. Better visibility into the trade-offs behind the answers.

Mullinnix frames it beautifully: “When AI shortens the path to agreement without lengthening the path to understanding, the system has failed — even if the decision succeeds.”

That’s not just an AI architecture principle. That’s a governance principle. And it’s one that most organizations — human or AI-assisted — haven’t internalized yet.

Sources and further reading: