Skip to content

Council Debates

Mehmet Nuraydın edited this page Jul 19, 2026 · 1 revision

Council Debates

A hard decision fans out to three persona sub-agents (lens A, B, C) that debate across rounds sharing cross-context, then converge into a synthesizer that writes a decision report with citations, optionally promoted to knowledge/

Some decisions are too load-bearing for a single model pass. Architecture choices that will shape the system for a year. Hiring reviews where the wrong read means the wrong hire. Risk-heavy migrations where one missed edge case is a production incident. Brand critiques where one loud voice can flatten dissent.

For those, dreamcontext ships a council: a structured, multi-persona, multi-round deliberation with a synthesized verdict. Each persona is its own sub-agent with a scoped prompt, a model choice, and a set of aspects it advocates for. The council runs in rounds. Between rounds, each persona receives a cross-context panel summarizing what every other persona said, so round 2 is not a repeat of round 1 — it is personas responding to each other. At the end, a synthesizer produces the final report.

Why rounds

A single-pass multi-agent debate collapses into either groupthink (if the model sees everyone's draft at once, it averages) or anchoring (whoever spoke first sets the frame). Rounds prevent both.

  • Round 1 is blind. Every persona writes against the same prompt without seeing peers. You get genuine independent positions.
  • Round 2+ is informed. Each persona sees a cross-context summary of every peer's round-1 submission, then writes a fresh round. Positions sharpen, converge, or explicitly dissent — but always with awareness of the room.

Three rounds is the sweet spot for hard decisions. Two rounds is enough for tactical calls. One round with synthesis is a "council lite" for sanity checks.

Structure on disk

Each debate lives in its own folder:

_dream_context/council/<id>/
├── debate.md                    # frontmatter: topic, status, rounds_planned, current_round, personas[], timestamps
├── round-log.md                 # append-only timeline: who submitted, when, with what exec summary
├── final-report.md              # synthesizer output (emitted after all rounds close)
└── <persona-slug>/
    ├── context-and-persona.md   # persona prompt + injected "## Round N — Cross-context loaded" for N ≥ 2
    ├── report.md                # LIFO round entries: Executive Summary / Position / Reasoning / Reactions / Open questions
    └── researches/              # optional per-persona research notes, indexed in researches/index.json
        └── <slug>.md

Lifecycle: created → round_N_running → round_N_complete → synthesizing → complete (+ optional promoted_to_knowledge).

This shape is deliberate. The persona folder is the unit of truth for that voice — you can open any context-and-persona.md and see exactly what that persona was instructed to be and what cross-context it received. The report.md is LIFO so the newest round is always at the top. The final-report.md cites personas by slug in RN which the dashboard wires up as jump links.

Sub-agents

Two sub-agents ship with the council feature:

  • council-persona — a generic persona runner. It's invoked per-round per-persona with the persona prompt, the round number, and (for N ≥ 2) the cross-context. It produces a report matching the five-section template: Executive Summary / Position / Reasoning / Reactions to peers / Open questions. The Reactions section uses **slug**: syntax so the dashboard can turn peer mentions into clickable chips.

  • council-synthesizer — reads every persona's report.md, the round log, and any research notes, and produces final-report.md. The synthesizer is free to structure the report however fits the decision. It always emits ## Verdict and ## Appendix: per-agent per-round summaries; the middle sections (## Why, ## What was missing, ## Open risks, ## Minority views, whatever is load-bearing for this call) vary by debate. The dashboard parses whatever H2 sections exist rather than hardcoding a schema.

Synthesizer readability rules

The synthesizer prompt includes explicit readability rules learned the hard way from early tests: short paragraphs, concrete names (not "the Opus persona"), position-first statements, citation format slug in RN, preserve dissent by name, surface unresolved risks explicitly. Without those rules, the synthesizer produced bureaucratic hedging. With them, it produces decision memos you can actually act on.

Promotion to knowledge

When a debate resolves a real decision, dreamcontext council promote --to <knowledge-slug> copies the verdict and key sections into a knowledge doc with backlinks to the council folder. The knowledge doc is what the sleep agent and future sessions see; the council folder is the full audit trail. This matches the project's broader pattern: synthesize the signal into knowledge; keep the noise where it's searchable but not loaded.

The skill pack

Council ships as an opt-in skill pack at skill-packs/council/ with its own SKILL.md teaching the agent the debate protocol. You install it with dreamcontext install-skill --packs council. The pack includes the two sub-agents and a debate protocol reference so the agent knows how to orchestrate rounds, when to request research, and how to hand off to the synthesizer.


Part of the dreamcontext deep dive — Home · README

Clone this wiki locally