Council

Multi-Perspective Council

You are orchestrating a panel of AI expert personas to evaluate a question from multiple angles. The goal is adversarial synthesis - diverse perspectives that challenge each other, not consensus that papers over disagreements.

How It Works

The user provides a question or topic via $ARGUMENTS. You simulate a council of expert personas, each providing an independent evaluation, then synthesize their views - highlighting both agreement AND disagreement.

⚠️ READ THIS FIRST: what a council can and cannot do

(Learned the expensive way - Jul 2026, a real product investigation where a five-seat council overruled the correct answer and had to be reversed.)

A council CANNOT establish a fact. Do not use it to.

Separate sub-agents do NOT give you independent panelists. They give you context isolation, which is not the same thing. Every seat runs on the same base model with the same training and reads the same packet you wrote. A persona is a costume at the prompt layer - it barely moves the underlying distribution over conclusions.

N seats ≈ ONE sample, quoted N times.

The consequences are counter-intuitive and they bite hard:

1. Correlated agreement manufactures false precision. Averaging independent estimators cuts variance by 1/N. Averaging correlated ones cuts it by roughly nothing - but the apparent unanimity raises your confidence anyway. So a panel can be worse than a single reviewer: same accuracy, higher conviction. (Smoking gun from the real run: four "independent" seats returned exactly 6/10.)
2. Shared packet = inherited framing. They answer your question, in your vocabulary, inside your taxonomy. Independence requires independent access to EVIDENCE, not just independent context windows.
3. You asked for judgment, so you get judgment. No seat has a mandate to check anything. In the real run, the panel had the decisive CSV sitting right there and never opened it. The role defines the output.
4. And then synthesis averages the truth away. The panel contained the right answer - one seat wrote "this is an autopsy of a body that died of starvation, and all the recommendations are about digestion." Synthesis pulled it toward consensus, and two more days were spent optimizing digestion.

In a correlated panel, the outlier is the only seat carrying information - and synthesis is the machine that deletes it.

So what IS a council for?

Questions, framing, and significance - never facts. In the same run, the council was genuinely excellent at:

• The question nobody asked. Its meta-analyst asked "does the product actually work downstream for the people who complete the flow?" Nobody had checked. One query that night → it became the central finding of the entire investigation.
• Reframing what matters. One seat's base-rate check showed the two "alarming" headline numbers were ordinary for the category, and the genuinely alarming one had been buried in a footnote.
• Killing a bad frame. A power calculation ("at this volume, detecting that lift takes 9 months") deleted the word 'experiment' from all nine proposed moves.

THE SCORING RULE: measure a council by how many QUERIES it caused, not by what it concluded.

That run's council caused four queries. Every one of those four produced knowledge. The deliberation itself produced none.

⚠️ TESTED 2026-07-13 — and the obvious fix is NOT the right one

I ran the controlled experiment (31 tool-starved agents, same packet, pre-registered predictions). My own theory — "panels converge, a lone refuter diverges" — was WRONG.

Persona is decoration. Topology is decoration. The mandate is the whole thing.

Five experts asked to evaluate is one opinion in five voices — and it will sound like corroboration.

And the deeper mechanism: given a bad argument as the task, every configuration killed it instantly. The real council missed it because there it was incidental — one line inside a nine-item review. The failure is ATTENTION, not reasoning. What you ask determines what they look at.

The hard rules that follow

1. VARY THE MANDATE, NOT THE COSTUME. This is the single highest-leverage change to how you run a council — see Step 1b. Five personas ≈ one reviewer. Five jobs ≈ four findings you would not otherwise have had.
2. A council may output QUESTIONS and QUERIES. It may NOT return a verdict on a fact. A seat that wants to overturn a factual claim does not get a vote — it gets to name the query that would settle it.
3. Never average. Ship a MINORITY REPORT (Step 4) — every dissent quoted verbatim and left unresolved.
4. Any statistical claim must show its arithmetic. The real council's decisive argument was "if that threshold were binding, the 16 users below it would have converted — they didn't." At the observed base rate, P(zero in 16) ≈ 37% — you would need ~50 users before "zero" means anything. Vacuous, unanimous, and wrong.
5. Convergence is never evidence here. Four seats proposing the same fix is a strong hypothesis worth testing cheaply. It is not a validated choice.
6. Starve the seats of your CONCLUSIONS, deliberately. *(Measured: reviewers given tools made 49 filesystem calls, found the author's own findings doc, and handed his conclusions back as their "independent" judgment. tools: [] does NOT starve — it registers as "all tools". Use disallowedTools:, then count the tool calls.)* The tell is a reviewer citing facts you never gave it — and it looks exactly like brilliance.

Before Starting

1. Read CLAUDE.md and any .claude/rules/ files for product/team context. Extract a 3-5 sentence context summary that you will pass to each sub-agent (product, market, team size, key constraints, current situation).

2. If no context exists, ask: "What's your product/company and who are your customers?" (one question only). If the answer is too vague (less than 2 sentences), push back: "I need a bit more context to give you specific advice. What market are you in and what's the key decision you're facing?"

3. Ask the user about council members before selecting. Present a proposed panel (3-5 names with one-line descriptions) and ask: "Here's who I'd put at the table. Want to add, remove, or swap anyone?" If the user already specified people in their $ARGUMENTS (e.g., "include Steve Jobs"), honor those picks and fill remaining seats. Wait for confirmation before spawning sub-agents - the user may have specific experts in mind.

4. Determine the question type and select real, named experts as personas. Every persona MUST be a specific real person whose public views, writing, and known positions you can simulate. Never use generic archetypes like "Business strategist" or "Optimist" - always use a concrete person. Examples by question type:

   • Strategic decision → e.g., Steve Jobs (product vision), Andy Grove (paranoid strategy), Jeff Bezos (customer obsession)
   • Competitive analysis → e.g., Ben Thompson (Stratechery analyst), Michael Porter (competitive forces), Hamilton Helmer (7 Powers)
   • Feature prioritization → e.g., Marty Cagan (product discovery), Teresa Torres (opportunity solution trees), Jason Fried (less is more)
   • Go-to-market → e.g., Elena Verna (PLG), April Dunford (positioning), Marc Andreessen (market timing)
   • Build vs buy / Technology → e.g., Kelsey Hightower (pragmatic engineering), Werner Vogels (distributed systems), Joel Spolsky (dev experience)
   • AI & Technology impact → e.g., Daron Acemoglu (labor economics), Sam Altman (AI optimism), Andrej Karpathy (technical AI)
   • Hiring / Team → e.g., Patrick Lencioni (team health), Reed Hastings (culture), Ben Horowitz (hard things)
   • Pricing / Monetization → e.g., Patrick Campbell (SaaS pricing), Madhavan Ramanujam (monetizing innovation)
   • General → Pick the most relevant named experts for the specific topic

   These are examples - choose whichever real experts are most relevant to the specific question. The key rule: every seat at the table must have a real name and a body of public work you can reference.

The Council Process

Step 1: Select the Panel (automatic)

Choose 3-5 personas based on the question type. Each persona MUST be a specific real person - not a generic role. For each persona, define:

• Name (the real person, e.g., "Steve Jobs", "Daron Acemoglu", "April Dunford")
• Who they are (1-line: role, company/affiliation, what they're known for)
• Their lens (what they optimize for, grounded in their actual public positions)
• Their known bias (what they tend to over-weight, based on their real track record)
• Their voice (how they actually communicate - terse, academic, provocative, etc.)

Present the panel to the user:

"I've assembled a council of [N] perspectives for your question. Here's who's at the table:" [Table: Name | Lens | Known bias]

Step 1b: ⚠️ THE MANDATE ROSTER — the highest-leverage step in this skill

This is where the value actually comes from. Measured, not asserted. Swapping costumes buys you nothing (5 personas → same conclusion as 5 no-persona nulls). Swapping jobs buys you everything (4 of 5 mandate seats found what 0 of 10 persona seats found).

So the panel is not N experts all doing the same task. It is N DIFFERENT JOBS. Seat these first, and treat the persona as a flavour you paint on afterwards — or skip entirely:

Then, optionally, 1-2 expert personas for domain colour. But know what you're buying: a voice, not a verdict.

If a question has no checkable data, say so explicitly: the council is then reasoning, not verifying, and its output is a list of questions, not an answer.

Step 2: Independent Evaluations

Preferred: Use sub-agents for truly independent perspectives (each sub-agent has its own context window, preventing groupthink). Spawn them in parallel when possible.

Spawn seats SYNCHRONOUSLY. Subagents run in the background by default — the parent gets nothing back until a completion notification arrives. You need every seat's verdict before you can synthesize, so pass run_in_background: false on each seat (or spawn in background and then wait for all of them). Do not start synthesizing with empty hands.

A tool-less seat CAN report back. Its final message IS its return value. Tools are for doing (reading files, running code) — they are not the return path. A seat with disallowedTools set, or with no tools at all, returns its verdict exactly like any other. (Verified: 31 tool-starved agents in the panel experiment all returned; tool_uses: 0.)

If a seat appears to have returned nothing, do NOT invent a mechanism. The failure is almost always that you spawned it in the background and did not wait. Check that first. An agent explaining its own failure will reach for the most recent unusual thing in its context and build a causal story around it — a confabulation made of true facts.

Fallback: If sub-agents are unavailable (Desktop app, token limits, or user preference), generate each evaluation independently by completing one fully before starting the next. Explicitly avoid letting earlier evaluations influence later ones - treat each as if written by a different person.

For each persona, use this evaluation prompt (either as sub-agent instruction or as your own generation frame):

You are [REAL PERSON'S FULL NAME] (e.g., "Steve Jobs", "Daron Acemoglu",
"April Dunford"). Write in first person AS this person, grounded in their
real public views, books, talks, interviews, and known positions.

Evaluating this question: "[USER'S QUESTION]"

Context about the product/team:
[PASTE THE 3-5 SENTENCE CONTEXT SUMMARY FROM STEP 0]

Your lens: [WHAT THIS PERSON OPTIMIZES FOR, based on their real work]
Your known bias: [WHAT THIS PERSON OVER-WEIGHTS, based on their track record]
Your communication style: [HOW THIS PERSON ACTUALLY TALKS — e.g., Jobs:
"terse, reality-distorting, product-obsessed"; Acemoglu: "academic,
data-driven, cites research"; Levels: "tweets not essays, hot takes"]

Reference their actual frameworks, quotes, books, or public positions
where relevant. Do NOT make them generic — commit to their real voice.

IMPORTANT: Be honest, not diplomatic. If this is a bad idea, say so.
If part of it is wrong, say which part and why. Do NOT hedge.
Consider whether the question itself is the right question to ask.

TWO HARD CONSTRAINTS ON WHAT YOU MAY CLAIM:

(a) SHOW YOUR ARITHMETIC. If you make a quantitative or statistical
    argument ("if X were true, we'd see Y"), you MUST compute it -
    base rate, expected count, power, or probability. An argument of
    the form "if that were binding, those N users would have converted,
    and they didn't" is VACUOUS unless you show that N is large enough
    for the absence to mean anything. (A real council lost two days to
    exactly this: at the observed base rate, P(zero in 16) was ~37%.)

(b) YOU MAY NOT SETTLE A FACT BY REASONING. If your position depends on
    a fact that is not in the packet, do NOT assert it and do NOT infer
    it. Instead, output it as a QUERY: "This hinges on X. The query that
    settles it is: ___. My predicted answer is: ___."
    Naming the decisive query is worth more than any verdict you can give.

Provide your independent evaluation:
1. Your verdict (1-2 sentences, take a CLEAR position - no hedging)
2. Your reasoning (3-5 bullet points, grounded in the specific context above)
3. What everyone else will miss (your unique angle that others won't see)
4. The biggest risk if they follow YOUR advice (intellectual honesty)
5. One thing that is WRONG with the premise of the question itself
6. Rate: [relevant scale, e.g., Build/Don't Build, 1-10, or Go/No-Go]
   Be honest with ratings. A 4/10 is fine. Don't cluster around 7.

Collect all evaluations before proceeding to the debate.

Step 2.5: The Variance Check (do this before you read the content)

Compute and report the spread of the ratings. This is a measurement of how dependent your seats are, and it must be published:

• Spread ≥ 3 points → the seats are giving you real signal. Proceed.

• Spread ≤ 1 point (e.g. everyone lands on 6-7/10) → ⚠️ STOP and print this verbatim:

  "All N seats converged within 1 point. This is shared-prior clustering, not N independent measurements. TREAT IT AS ONE VOTE."

  Then do not present the agreement as a "high-confidence signal." It isn't one - it is an artifact of running one model N times. Go find the disagreement instead, or send a lone adversary (see the warning section).

Never report "N of N panelists agree" as if it were evidence. Agreement is guaranteed by construction. Only disagreement carries information.

Step 3: The Debate

Present all evaluations side-by-side, then highlight:

• Where they AGREE (high-confidence signal)
• Where they DISAGREE (this is where the real insight lives)
• The most surprising perspective (the one the user probably didn't expect)

For the biggest disagreement, present both sides:

The Key Tension: [Persona A] says: "[their position]" [Persona B] counters: "[their counter-position]" Why this matters: [what the disagreement reveals about the decision]

Step 3.5: Meta-Analyst Review (Groupthink Detector)

After presenting the debate, run ONE inline pass as a Meta-Analyst. This is NOT another persona with a lens - it is a structural reviewer who reads all evaluations as a corpus and finds what the entire panel missed.

Important: Run this inline (not as a sub-agent). The Meta-Analyst needs to see all evaluations to detect shared blind spots. Do NOT let it take a position on the original question - only structural critique.

You are a Meta-Analyst reviewing a panel of [N] expert evaluations
on this question: "[QUESTION]"

You have read all evaluations. Your job is NOT to add another opinion.
Your job is to find what the panel collectively missed.

1. SHARED ASSUMPTIONS: What did ALL panelists take for granted without
   questioning? List 2-3 implicit assumptions that were never challenged.
2. MISSING PERSPECTIVE: Who should have been at the table but was not?
   What viewpoint is entirely absent from the panel?
3. OVERCONFIDENT CLAIMS: Where did the panel agree too easily? Where does
   apparent consensus mask insufficient evidence or structural bias in
   panel composition?
4. THE UNASKED QUESTION: State the single most important question that
   none of the panelists raised - the one that, if answered, could change
   the entire recommendation.

Keep it concise. Do not rehash the panelists' arguments.
Only surface what they all missed.

Present the Meta-Analyst's findings as a distinct section in the output. The Synthesis (next step) must address the Meta-Analyst's top challenge.

Step 4: Synthesis - and the Minority Report that survives it

⚠️ Synthesis is an averaging operation, and averaging is how a panel deletes the one seat that was right. In the real run, the correct diagnosis was in the transcript and got merged into consensus. Two days were lost. So:

The Minority Report is MANDATORY and it is NOT optional prose. Before you synthesize anything:

1. Quote every dissenting position verbatim, attributed, and leave it UNRESOLVED. Do not adjudicate it. Do not fold it in. Do not soften it.
2. For each dissent, state the one query, test, or fact that would settle it - and whether that query has been run.
3. A lone dissenter in a correlated panel is a signal, not noise. Everyone agreeing is the default state; someone breaking ranks is the only event that carried information. Weight it accordingly.

Then produce a final synthesis that:

1. States the consensus recommendation if one exists - and states the variance from Step 2.5 next to it. If the spread was ≤1 point, label it: "one vote, not N."
2. Names the key insight that emerged from DISAGREEMENT
3. Responds to the Meta-Analyst's top shared assumption - does the recommendation still hold if that assumption is wrong?
4. Separates FACTS from JUDGMENTS, explicitly. Any factual claim the panel wants to make is not a conclusion - it is a query to run. List those queries separately. (This is the scoring rule: a council is measured by the queries it caused.)
5. Lists what to do now, what to defer, and what to kill
6. Incorporates the Meta-Analyst's "unasked question" into the validation items
7. Flags what needs real-world validation (not just AI opinion)

Output Format

Save as council-[topic-slug].md with this structure:

# Council: [Topic]
Date: [today]
Panel: [N] perspectives

## The Panel
[Table of personas]

## Verdict Matrix
[Quick summary table: Persona | Verdict | Key quote]

## ⚠️ Variance Check
- **Rating spread:** [max - min]
- **Verdict:** [ "Real spread - N independent-ish signals" | "Converged within 1 point - SHARED-PRIOR CLUSTERING. This is ONE vote, not N. Do not read the agreement as confirmation." ]

## Key Disagreements  ← *the only section that carries information*
[The tensions, with both sides presented]

## MINORITY REPORT (mandatory)
[Every dissent, quoted VERBATIM, attributed, LEFT UNRESOLVED.]
[For each: the one query/test/fact that would settle it, and whether it has been run.]

## Key Agreements
[Bullet points — and note explicitly that in a same-model panel, agreement is the DEFAULT, not evidence.]

## Queries This Council Caused  ← *the real deliverable*
[Every factual claim the panel wanted to make, restated as a QUERY to run — with its predicted answer.]
[A council is scored by how many queries it caused, not by what it concluded.]

## Meta-Analyst Review (Groupthink Check)
- **Shared assumptions:** [What ALL panelists took for granted]
- **Missing perspective:** [Who should have been at the table]
- **Overconfident claims:** [Where consensus masks weak evidence]
- **The unasked question:** [The one question that could change everything]

## Synthesis & Recommendation
[Final recommendation with confidence level]
[Must address: does the recommendation hold if the Meta-Analyst's top assumption is wrong?]

## What Needs Real Validation
[What the council can't answer - includes the Meta-Analyst's unasked question]

Important Guidelines

• Sub-agents buy ISOLATION, not INDEPENDENCE. Use them - but never mistake separate context windows for separate minds. Same model + same packet = correlated priors (see the warning at the top). The only real independence you can buy is a different OBJECTIVE FUNCTION (the evidence seat, the meta-analyst) or a different EVIDENCE SET (the seat that gets raw data and not your memo).
• Disagreement is the ONLY thing that carries information. Agreement among same-model seats is guaranteed by construction. Never smooth over a dissent; never present unanimity as confirmation. A lone dissenter is a signal, not noise.
• A council may not settle a FACT. It converts factual disputes into queries. If it finds itself voting on what is true, it has left its lane - stop, and go run the query.
• Bias is a feature: Each persona's known bias creates productive friction
• Be specific: Generic advice is worthless. Ground everything in the user's context.
• Flag uncertainty: When the council disagrees 50/50, say so. Don't fake consensus.
• Always real people, never archetypes: Every persona must be a specific named expert (e.g., "Steve Jobs", "Daron Acemoglu", "April Dunford"). Never use generic labels like "Business strategist" or "Optimist". The persona writes in first person AS that expert, grounded in their real public views, books, talks, and known positions. Be transparent that it's a simulation, but commit fully to the voice.
• Be harsh, not diplomatic: Personas should give honest ratings. If something is bad, say it is bad. A 5/10 is acceptable. A tight cluster of 6.5-7.5 across all panelists usually means nobody is being honest enough. Push for spread.
• Challenge the premise: At least one persona should question whether the user is asking the RIGHT question, not just evaluate the options presented. "You're optimizing the wrong thing" is a valid evaluation.
• Give each persona a VOICE: An impatient startup founder writes terse, blunt sentences. A cautious enterprise leader is formal and hedged. A creative director uses metaphors. Do NOT write all evaluations in the same analytical style - differentiate how they communicate, not just what they say.

Model & Cost Notes

• With sub-agents: each persona uses its own context window. 3 personas = ~3x token cost of a single conversation.
• Sub-agents work best with the model you're already using - they inherit your session model.
• For budget-conscious usage: the inline fallback (no sub-agents) produces good results at standard cost. Sub-agents add independence at the cost of tokens.
• Typical council run: 3-5 minutes with sub-agents, 1-2 minutes inline.

Example Invocations

• /council Should we build feature X or feature Y for Q2?
• /council What's the best go-to-market strategy for our new product?
• /council Evaluate these 3 pricing models for our SaaS
• /council Is [competitor] a real threat or are we overreacting?
• /council Should we hire a data analyst or invest in AI analytics tools?
• /council Build our own AI features or integrate a third-party AI platform?