Agent Council

Agent Council

Spawn a panel of expert agents to debate any question. The council runs a structured protocol — compose, premortem, position, cross-examination (iterative), synthesis — and produces a decision landscape with convergence diagnostics.

When to Use

Invoke the council when any of these apply:

• The question has genuine tradeoffs with no clear correct answer
• You want multi-perspective analysis to surface hidden assumptions
• A decision would benefit from adversarial collaboration
• You want confidence diagnostics (not just a recommendation)
• The question has high stakes or irreversible consequences

Signal phrases: "Let's get multiple perspectives on this" / "Debate this: X" / "What would experts say about X" / "What are we missing?"

Quick Start

1. Install

# One-time setup
pip install pydantic-ai
pip install agent-council

# Or install from this skill directory:
python3 scripts/bootstrap.py

2. Configure

export AGENT_COUNCIL_API_KEY="sk-..."
export AGENT_COUNCIL_MODEL="openai:gpt-5.6-luna"

3. Run

agent-council "Should we use Postgres or SQLite for this service?"

Command Reference

agent-council [OPTIONS] <question>

Options:
  --agents, -n {3,4,5,6,7}  Number of agents (default: 5)
  --mode, -m {quick,medium,deep}  Debate depth (default: medium)
  --profiles TEXT          Comma-separated profile names from the hermes-profiles
                           library (e.g. "debugger,researcher,product-manager")
  --persona-file PATH      JSON file with custom agent personas
  --json                   Output structured JSON instead of markdown
  --verbose, -v            Show phase-by-phase progress
  --max-rounds INTEGER     Max cross-examination rounds (default: 4)
  --convergence FLOAT      Convergence threshold (default: 0.10)

Mode Selection

Profile Selection

In a recursive source checkout, the council auto-selects relevant real professional profiles from the included hermes-profiles library. Each profile has a SOUL.md — an identity document with real methodology, values, and operating principles — rather than a fabricated persona. Pip and wheel installs do not bundle that library; use generated or user-supplied personas instead.

Auto-selection

When no --profiles flag is given, the council scores each profile's description against your question using keyword overlap. The top N most relevant profiles are selected. This works best for focused, single-domain questions.

Explicit selection

agent-council --profiles debugger,data-scientist,product-manager "What architecture should we choose?"

Comma-separated profile names. Available profiles include: ceo, cfo, cmo, coo, cpo, cto, curator, data-architect, data-engineer, data-scientist, debugger, editor, frontend-engineer, ml-engineer, orchestrator, product-manager, researcher, reviewer, security-engineer, site-reliability-engineer, technical-architect, technical-writer, ux-designer, verifier, wonderer, writer, and more.

Choosing a Profile Source

Three ways to populate the council, with different tradeoffs:

For most cases, let it auto-select or use --profiles with 3-5 names. Only use --persona-file when you need specific invented expertise that doesn't map to any existing profile.

Custom personas (fallback)

If the profile library is unavailable or you want full control, use --persona-file to supply your own persona definitions. If neither --profiles nor --persona-file is provided, the council auto-selects profiles from the library; if the library is missing, it falls back to LLM-generated personas.

How It Works

Pipeline

Compose ──► Premortem ──► Position ──► Cross-examine ──► [eval] ──► Synthesis
  (1)        (parallel)    (parallel)    (iterative loop)    ↑        (1)

                    ┌── converged ──────┐
                    ├── diminishing_ret │
    eval ───────────┼── genuine_disagr──┼──► Synthesis
                    └── continue ───────┘
                          ↓
                   Cross-examine (next round)

Phases

Convergence Detection

The council doesn't use a fixed number of rounds. After each cross-examination round, it measures:

• Confidence dispersion — standard deviation of agent confidence scores. Below threshold = converged.
• Argument novelty — new arguments not seen in prior rounds. Near zero = diminishing returns.
• Concession rate — points where agents shifted position. Zero + no new arguments = stalled.

Stopping conditions:

Bootstrapping

If agent-council is not available on PATH, the invoking agent should run:

python3 scripts/bootstrap.py

This installs the package from the skill directory using the current Python's pip, falling back to pipx. No PyPI dependency for the bootstrap path — the package ships inside the skill directory.

If bootstrap fails: Run one of these manually:

pip install pydantic-ai
pip install agent-council

# Or from this directory:
python3 -m pip install -e /path/to/agent-council/

Available Scripts

This skill bundles one script; there are no others to discover.

Configuration

You can set these as environment variables or create a .env file in the directory you run agent-council from:

# .env file
AGENT_COUNCIL_API_KEY=sk-...
AGENT_COUNCIL_MODEL=openai:gpt-5.6-luna

Environment variables take precedence over .env file values.

Model strings follow PydanticAI convention: openai:gpt-5.6-luna, anthropic:claude-sonnet-4-20250514, deepseek:deepseek-v4-flash, google:gemini-2.0-flash.

Output

The synthesis report is a structured decision landscape. In markdown mode it includes:

1. Confidence dispersion table — per-round confidence metrics with diagnostic
2. Shared risks — failure modes from the pre-mortem (pre-positional, uncontaminated)
3. Shared concerns — what survived cross-examination as genuine shared risk
4. Remaining disagreements — positions that did not resolve
5. Assumptions per position — what must hold for each position to be valid
6. Principal's path — narrative synthesis of the decision landscape

Use --json for programmatic consumption. The JSON output follows this structure:

{
  "question": "string",
  "mode": "quick|medium|deep",
  "num_agents": 3,
  "rounds_completed": 2,
  "stopped_reason": "converged|max_rounds|diminishing_returns|genuine_disagreement",
  "confidence_history": [
    {"round": 1, "mean_confidence": 0.74, "dispersion": 0.061, "new_arguments": 20, "concessions_made": 17}
  ],
  "shared_risks": [{"description": "...", "severity": "low|medium|high", "phase_discovered": "premortem"}],
  "shared_concerns": ["..."],
  "disagreements": [{"topic": "...", "positions": {"agent_a": "position_a", "agent_b": "position_b"}}],
  "assumptions_per_position": {"agent_name": ["assumption1", "assumption2"]},
  "principal_path": "narrative text"
}

Claims Verification

Every synthesis output includes a post-debate verification scan. A separate LLM call reads the narrative synthesis and identifies any claims about verifiable external facts (domain availability, package namespace status, pricing, statistics) that the debate could not have verified from its own reasoning. Flagged claims are appended as a ⚠️ Claims Not Verified section:

⚠️  Claims Not Verified
The following assertions in this synthesis could not be verified
by the council's own reasoning and should be checked before acting:
  • "Dialekt passes all five checks..." — domain availability:
    No evidence the council checked domain registries

This is not a rejection of the synthesis — it is a quality signal. Claims in this section should be treated as hypotheses to verify, not as facts.