One model answers. Another reviews. They go back and forth until they agree — or surface exactly where they disagree. Give each agent a domain character and you get cross-perspective reasoning: an architect proposing, a reviewer stress-testing, a security engineer hunting vulnerabilities.
The round-table isn't a debate with a winner. It's a collaborative search for the best answer. Agent A proposes. Agent B finds gaps. Agent A revises. Agent B re-checks. The goal is explicit AGREED — and if it doesn't happen, both positions are shown side-by-side so you can decide.
It's opt-in per turn: toggle the Discuss button next to Send and the next message goes through deliberation. Toggle it off and you're back to single-agent chat. You need two models configured — they can be the same provider and model, or different ones (e.g. a fast reviewer paired with a deep reasoner).
One round = both agents take a turn. The process repeats until they agree or hit the round cap.
Agent A answers first. Agent B reviews that answer and lists specific objections — errors, gaps, unstated assumptions. Agent A revises, addressing each objection (accepting or refuting with reasons). Agent B re-reviews. If all objections are resolved, B says AGREED. If not, the cycle continues until consensus or the round cap (default 3 rounds).
After the deliberation concludes — regardless of outcome — each agent writes a personal manifesto: a short, opinionated final statement of their convictions. Both manifestos are saved as a file you can preview and download.
Set ROUNDTABLE_CHARACTERS to a pair of slugs. The first character layers onto Agent A (the answerer), the second onto Agent B (the reviewer). Each brings a different lens to the question.
| When you want… | Characters | How it plays out |
|---|---|---|
| 🔍 Code review | software-architect, code-reviewer |
Architect proposes design or fix. Reviewer hunts edge cases, over-engineering, missing tests. Converges on a simpler, correct solution. |
| 🛡️ Security audit | software-architect, security-engineer |
Architect designs the system. Security engineer traces untrusted inputs, maps attack surface, demands defense in depth. Catches what code review misses. |
| 💡 Product decision | product-thinker, software-architect |
Product thinker asks "should we build this?" Architect asks "how would we build it?" Scope, trade-offs, and whether the problem is even right. |
| 🤔 Open-ended | socratic-questioner, software-architect |
Socratic questioner surfaces assumptions with no domain knowledge needed. Architect provides substance. Good for any fuzzy question. |
| 🚀 Domain-specific | space-engineer, doctor |
Two domain experts with different frameworks. Space engineer reasons from physics; doctor from clinical evidence. Cross-domain scrutiny. |
Available characters: software-architect, code-reviewer, security-engineer, product-thinker, socratic-questioner, doctor, space-engineer. Add your own by dropping a .md file into id/characters/.
Generic examples that work with any project. Toggle Discuss ON before sending.
What you'll get: Agent A assesses the approach and proposes improvements. Agent B finds specific edge cases and flags over-engineering. If they disagree, A revises.
What you'll get: A proposes an approach with constraints named. B challenges assumptions, asks about failure modes, suggests simpler alternatives.
What you'll get: Architect outlines a design. Security engineer traces every untrusted input path, demands defense in depth, flags concrete vulnerabilities with severity labels.
What you'll get: Cross-perspective analysis. Architect designs. Security engineer attacks the design. The final answer accounts for both.
What you'll get: Product thinker questions scope, users, and priorities. Architect estimates complexity and hidden costs. Together they decide if it's worth it.
What you'll get: Socratic questioner surfaces unstated assumptions. Architect grounds the answer in process and measurement. No domain expertise needed — pure reasoning.
What you'll get: A reads and assesses the ADR. B challenges weak arguments, flags missing trade-offs, demands evidence. Useful before sharing with the team.
What you'll get: Architect identifies likely causes. Reviewer checks for missing indexes, N+1 patterns, and edge cases in the proposed fix.
Consensus reached. A single bubble shows the agreed answer. The full transcript — every turn from every agent — is saved to var/roundtables/. You also get a manifesto file with each agent's final personal statement, served at /roundtables/ for preview and download.
My conviction: webhooks are the right call here. Polling burns resources linearly with scale; webhooks scale with events. The migration cost is real but bounded — one-time engineering, not perpetual ops tax. Start with a dead-letter queue, log every delivery attempt, and never trust a single webhook as your only record of truth. Idempotency keys are non-negotiable. Do this right and you eliminate an entire class of latency and reliability problems in one move.
I stand by one principle: if you can't test it, you don't understand it. Before switching to webhooks, write the integration tests against a real webhook receiver. If that's hard, your design is wrong. The architect's dead-letter queue is essential; without it, you'll drop events silently and never know. Also: what's the retry policy? Exponential backoff with a max? What happens when the third-party is down for 10 minutes? The manifesto says "bounded migration cost" — I want a number, not an adjective. Three days or three weeks? The difference matters.
No consensus. Both final positions are shown side-by-side so you can see exactly where they disagree. You still get the full transcript and manifesto file — even disagreement produces useful artifacts.
.envThe Discuss toggle appears automatically when you configure two agents. Characters are optional but highly recommended — they're what make the deliberation interesting.
The two agents can use the same model, different models, or even different providers. Common pairings: a fast reviewer (phi4-mini, haiku) paired with a deeper reasoner (gemma4, qwen3). Cloud + local works too — e.g. Claude for deep answers, a local llama.cpp model for fast review.
Characters are just .md files in id/characters/. Create your own by following the template in the existing ones. The slug you use in the env var is the filename without .md.