
I’ve been making architectural decisions with a single AI agent. Claude Code is smart, thorough, and fast. But lately I’ve noticed a pattern: my best decisions come when I’m uncertain, when I push back, when I ask “what am I missing?”
Single agents don’t argue with themselves. They’re confident. Sometimes too confident.
Here’s where a council comes in.
The Problem With Monolithic Thinking
Every AI model has training data biases, reasoning patterns it favors, and blind spots it doesn’t know it has. When you ask Claude to design a system, it designs a system—often a good one—but it’s one perspective.
This isn’t unique to AI. Humans do this too. We call it groupthink when teams do it, and we’ve invented entire disciplines (red teaming, devil’s advocacy, design reviews) to counteract it.
The question is: can we do the same with AI agents?
Agent Council: The Architecture
Agent Council is a multi-agent deliberation system. Not single API to different models—that lacks depth. Instead, it brings together genuinely different coding agents.
Each agent has its own tool ecosystem, web search, file exploration. They’re complete systems, not just models with different prompts. For example, I have:
- Claude Code (Claude)
- Gemini CLI (Gemini)
- Codex (OpenAI)
- OpenCode
You could use any combination or number.
The Hats They Wear
Each council member adopts a distinct perspective (configurable per session):
| Agent | Perspective |
|---|---|
| Claude | Systems Thinker and Inventor—long-term architecture, sustainability |
| Gemini | Pragmatic Architect—scalability, production stability, operational constraints |
| Codex | Devil’s Advocate—challenges assumptions, questions everything |
| OpenCode | Maintainability Zealot—developer experience, testability, friction reduction |
The value isn’t in the labels. It’s in the combination of different models wearing different hats. Real diversity, not simulated.
My Workflow: Three Steps
Here’s how I actually use this:
Step 1: Primary Research
Before calling a council, I work with Claude Code to deeply understand the problem. Research the domain. Explore the codebase. Draft an initial proposal.
This matters because councils aren’t for simple problems. They’re for architectural decisions with genuine ambiguity—multiple valid approaches, unclear tradeoffs, suspected blind spots.
The proposal becomes the foundation. But I know it’s incomplete.
Step 2: The Council Deliberates
The council works through four rounds of asynchronous deliberation:
Round 1 (Initial): Each agent independently analyzes the problem and proposes a solution. No peeking at others’ work. This captures genuine first impressions, not anchoring effects.
Round 2 (Critique): Agents read each other’s Round 1 proposals and identify weaknesses. What did they miss? What assumptions are unexamined? What breaks at scale?
Round 3 (Defense): Agents read critiques of their own work and respond. Either they defend with additional reasoning, or they acknowledge the critique and revise. Positions evolve.
Round 4 (Synthesis): The chairman (typically Claude) reads ALL the evidence—every proposal, every critique, every defense—and consolidates into a final recommendation.
Step 3: The Synthesis
The synthesis isn’t a vote. It’s not averaging. It’s genuine integration:
- Areas of agreement - what converged across perspectives
- Areas of disagreement - where agents differ and why
- Recommended path forward - the consolidated recommendation
- Minority opinions worth noting - dissenting views that merit consideration
This becomes my implementation plan.
Why Each Step Matters
Asynchronous deliberation beats real-time discussion. When agents work asynchronously (like thoughtful email exchanges), there’s no “first speaker dominance.” Each position gets articulated fully before anyone responds.
Independent proposals prevent anchoring. If agents saw each other’s Round 1 work before writing, they’d anchor to the first proposal. Independence captures genuine diversity.
Forced articulation creates clarity. When you must write down “here’s why I think X,” you discover gaps in your reasoning. This applies to AI agents too.
Critique without consequences enables honesty. There’s no ego, no politics. If Claude’s proposal has a weakness, Codex will say so.
The chairman role prevents dissolution. Without synthesis, you’d have four opinions. The chairman must integrate, finding what’s common, what’s contested, and what’s the path forward.
Real Results: A Case Study
I ran a council to design a task management workflow for research projects. Here’s what happened:
My Round 1 Proposal (Claude alone):
- Three research files (
notes.md,findings.md,candidates.md) - Direct adoption of a task management tool called Beads
- Implicit dependency handling
What The Council Changed:
| What | Before | After | Who Caught It |
|---|---|---|---|
| File structure | 3 files | Single RESEARCH.md |
Gemini: “excessive ceremony” |
| Task lifecycle | Not addressed | Explicit obsolete status |
Codex: “no dedupe model” |
| Dependencies | All equal | Hard vs. soft distinction | Codex: operational wisdom |
| Tool adoption | “Adopt Beads now” | “Validate workflow first, then decide” | OpenCode + Codex |
| Staleness | Vague “periodic review” | Explicit weekly 5-minute ritual | Codex: concrete over vague |
| ID scheme | Assumed hash IDs | ULIDs (sortable + collision-free) | Gemini: explicit rationale |
The final synthesis was materially better than my initial proposal. Not because any single agent had the answer, but because the deliberation process forced genuine consideration of alternatives.
What I Would Have Shipped Without The Council:
- Three research files (too heavy for a solo developer)
- No obsolescence handling (zombie task accumulation)
- All dependencies blocking equally (over-coupling)
- Dogmatic tool adoption without validation
- No concrete maintenance ritual
When To Use (And When Not To)
Use councils when:
- Architectural decisions have multiple valid approaches
- Trade-offs are unclear
- You suspect blind spots in your thinking
- Stakes justify the deliberation time
Skip councils when:
- Problem has obvious solution
- Speed matters more than thoroughness
- You have high confidence
A council takes maybe 20-30 minutes of active time (mostly waiting for agents to finish rounds). For a decision you’ll live with for months, that’s nothing. For a quick bug fix, it’s overkill.
The Implementation
Agent Council is a single Python script. No dependencies, no server, no infrastructure.
python3 agent_council.py new my-council
Creates a session folder with:
COUNCIL.md- rules and member perspectivesPROBLEM.md- where you define the challengeworkspace/- shared context (code, research notes)rounds/- where agents write their reportsprompts/- ready-to-use prompts for each round
Coordination happens through files. Every agent can read and write markdown. State is visible (ls, cat show exactly what’s happening). Sessions survive crashes. The entire deliberation is git-versioned.
The Deeper Insight
The council works because distinct perspectives were real. Gemini’s stability focus caught issues Claude’s systems thinking missed. Codex’s operational pragmatism questioned assumptions everyone else accepted. OpenCode’s friction obsession simplified what others overcomplicated.
If all agents had the same perspective, the council would have been echo-chamber theater. The value came from genuine disagreement and forced reconciliation.
This is what good human design reviews do. Multiple experts with different backgrounds, questioning each other, integrating insights. We’ve been doing this with humans for eons.
Now we can do it with AI agents.
Agent Council is open source. The full project is at github.com/quasilabs/agent-council.