quasiLabs Blog

Stories from the code-mines

Feb 2, 2026 - 6 minute read - AI-Native Development

Building an Agent Council

The Agent Council

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 perspectives
  • PROBLEM.md - where you define the challenge
  • workspace/ - shared context (code, research notes)
  • rounds/ - where agents write their reports
  • prompts/ - 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.