The Round Table: Multi-Agent Discussion Stages

Part of the AI Software House series.

In short: One agent tends to settle on the first reasonable answer. I added discussion stages so several agents can challenge that answer before anybody acts on it. A moderator keeps the useful parts, and the rest of the pipeline receives the result.

The problem with single-perspective agents

The normal pipeline works well when the requirement is clear: PM writes the PRD, Architect designs the system, and Engineers build it. The weakness is that each agent sees the problem through one role at a time.

Some tasks do not have one obvious answer. "Add webhook support" sounds small until I ask: one subscriber or many? retry or fire-and-forget? what happens if a subscriber is down for a week? Left alone, an engineer agent usually chooses a plausible answer and carries on.

That can produce perfectly tidy code for the wrong system.

The discussion stage

A discussion stage lets me pause the relay and put several viewpoints in the same room:

Homework (optional) — each participant independently researches the topic and writes an initial analysis
Rounds — participants debate in up to N rounds, @mentioning each other to respond directly
Early exit — if the moderator signals CONSENSUS_REACHED, the discussion stops before hitting the round limit
Synthesis — the moderator writes a summary of key conclusions and tradeoffs

Both the transcript and the moderator's synthesis go into PipelineResult. Later agents can see not only the decision, but also the tradeoffs behind it.

How to add a discussion to any pipeline

Drop a discussion stage into any pipeline.yaml:

stages:
  - pm
  - architect
  - discuss_brainstorm   # ← debate here
  - reviewer
  - junior_engineer
  - senior_engineer
  - qa_planner
  - qa_engineer

The discuss_brainstorm stage runs three personas — Analyst, Sceptic, Optimist — against the current PRD and design. Their synthesis flows into every stage that follows.

How participants are configured

Discussion presets live in discussions/*.yaml. Each is auto-discovered and registered as a pipeline stage named discuss_<stem>. The GUI config builder shows them in the stage palette automatically.

A minimal preset:

# discussions/brainstorm.yaml
participants:
  - role: analyst
    persona_file: roles/analyst.md
    llm: "opencode-go/qwen3.6-plus"

  - role: skeptic
    persona_file: roles/skeptic.md
    llm: "opencode-go/qwen3.6-plus"

  - role: optimist
    persona_file: roles/optimist.md
    llm: "opencode-go/qwen3.6-plus"

homework_round: true
max_rounds: 2
early_exit: CONSENSUS_REACHED

moderator:
  persona_file: roles/moderator.md

output_mode: both

context_fields:
  - prd
  - design

Any roles/*.md file can be a participant — including existing agent roles like architect.md or code_reviewer.md. Or you can write inline personas:

participants:
  - role: security-expert
    persona: "You are a security expert. Challenge every design for vulnerabilities."
    llm: "opencode-go/qwen3.6-plus"

Or let the LLM pick the most relevant participants from a pool:

auto_participants:
  pool: [analyst, skeptic, optimist, architect, security-expert]
  count: 3

What the transcript looks like

Each participant writes independently during homework, then the open rounds begin:

ANALYST: The webhook design looks sound for low-volume use cases. My concern is
the retry queue — if the subscriber is down for 72 hours, we could accumulate
tens of thousands of pending events with no back-pressure mechanism.

SKEPTIC: @analyst is right about the queue depth. I'd go further: the current
design has no dead-letter handling at all. Events that permanently fail just
disappear. Is that acceptable for a billing notification system?

OPTIMIST: Both valid points, but the common case is subscribers that are briefly
down for a few minutes. The retry backoff covers that. Let's not over-engineer
for a billing system that hasn't shipped yet.

MODERATOR: CONSENSUS_REACHED. Key conclusions: (1) implement a dead-letter queue
for events that exhaust retries, (2) add a configurable queue depth limit with
back-pressure, (3) document that at-most-once delivery is acceptable for the MVP.

The engineer then receives a concrete decision about the dead-letter queue, along with the reason it was chosen. There is less room to guess.

Where to place a discussion

The stage can go anywhere in a pipeline:

Position	Use case
Before engineers	Debate design before anyone writes code
Before PM	Align on requirements before writing the spec
After code review	Reviewer and engineer debate the findings
Between any two stages	Inject structured reasoning at a decision point

The Two-Model Split: Fast Debate, Slow Research covers a specific pattern: homework_llm, a way to give each participant a different model for the research phase vs the debate phase.

What this changes

I don't use discussion stages everywhere. A single agent is faster and is usually enough for a straightforward task. The extra calls are useful when disagreement is cheaper before implementation than after it.

For an ambiguous or expensive decision, a five-minute AI argument is often a good trade for one less round of human review on a PR that went in the wrong direction.