damian@wong:~/
damian@wong:~/projects$ cat decision-council.mdx
AI PROJECT

Decision Council

A multi-agent decision framework that pressure-tests complex choices through independent advisors, peer review, adversarial debate, and consensus synthesis while preserving dissent.

Multi-Agent Systems · Decision Science · JSONL
VIEW ON GITHUB ↗

01 / Overview

Important decisions rarely fail because there was no argument for the option someone chose.

They fail because an assumption went unchallenged, an alternative was never considered, or disagreement disappeared too early.

Claude Council is an experiment in structuring AI reasoning around that problem.

Instead of asking one model:

"What should I do?"

the system creates a small decision process.

Five advisors analyze the same decision independently from different reasoning perspectives. Their responses are anonymized and reviewed by other agents, unusually strong consensus can trigger an adversarial debate, and two separate chairmen examine the majority and minority positions before producing the final recommendation.

The goal is not to make an AI "choose for you."

The goal is to build a process that makes weak assumptions, uncertainty, disagreement, and overlooked alternatives harder to hide.


02 / My Contribution

I designed Claude Council as a structured decision pipeline rather than a collection of personas responding to the same prompt.

What I built

The main problem I was exploring was not how to generate more opinions.

It was how to design interaction between agents so that additional reasoning actually adds useful disagreement instead of repeating the same answer several times.


03 / Architecture

Claude Council runs decisions through a staged deliberation pipeline.

Decision flow

StageResponsibility
TriageDecide whether the question actually deserves a council
HistoryLook for previous related decisions and outcomes
FramingStructure the decision, stakes, options, and context
Bias AuditFlag potential cognitive distortions before deliberation
AdvisorsGenerate independent analyses from different reasoning lenses
Peer ReviewEvaluate advisor arguments without revealing their identities
DebateAttack unusually strong consensus
ChairmenIndependently synthesize majority and minority interpretations
Dissent PassRestore valuable arguments that consensus may have softened
JournalRecord the decision for future calibration

This separation is intentional.

An advisor cannot simply become the final answer.

Its reasoning has to survive review, comparison, disagreement, and synthesis first.


04 / The Council

The five advisors are designed around different failure modes in decision-making, rather than different writing personalities.

AdvisorQuestion it pressures
Red TeamHow could this fail?
First PrinciplesWhich assumptions are we treating as facts?
ExpansionistWhat options are missing entirely?
OutsiderWhat would another discipline notice here?
ExecutorCan this actually be executed with the available resources?

Red Team

Works backwards from failure.

Instead of asking why an option might succeed, it assumes the decision went badly and attempts to identify:


First Principles

Breaks the decision apart and challenges its starting assumptions.

It tries to identify when the council is reasoning inside a frame that may itself be wrong.

CODE
existing assumption
        ↓
break it apart
        ↓
reframe the problem
        ↓
compare new possibilities

Expansionist

Looks beyond the options explicitly provided by the user.

A decision framed as:

A vs B

may actually contain:

A vs B vs C vs hybrid vs delay vs experiment first

The Expansionist exists to prevent the council from optimizing inside an unnecessarily narrow option set.


Outsider

Approaches the problem through methods borrowed from another field.

The objective is to introduce reasoning patterns the other advisors may not naturally reach.


Executor

Pressure-tests feasibility.

It focuses on:

This acts as a counterweight to recommendations that are strategically attractive but operationally unrealistic.


05 / Engineering Decisions

Independence before collaboration

One of the most important architectural decisions was preventing the advisors from seeing each other's reasoning during the first pass.

CODE
                    Decision

      ┌────────┬────────┬────────┬────────┬────────┐
      ↓        ↓        ↓        ↓        ↓
     Red    Principles Expansion Outsider Executor
     Team
      │        │        │        │        │
      └────────┴────────┴────────┴────────┴────────┘
                         ↓
                     Comparison

If agents collaborate too early, they can anchor on whichever argument appears first.

Parallel fan-out gives each reasoning lens an opportunity to form its own conclusion before social influence enters the pipeline.

The council combines the analyses after independence has been established.


Anonymized peer review

Another design decision was separating the argument from the identity of the advisor that produced it.

Before peer review, advisor responses are mapped to anonymous labels:

CODE
Red Team          ─┐
First Principles  ─┤
Expansionist      ─┼──→  A · B · C · D · E
Outsider          ─┤
Executor          ─┘

Persona-specific structural clues are also normalized where possible.

Reviewers therefore evaluate the reasoning itself instead of knowing:

"This is the Red Team argument, so naturally it is pessimistic."

Only after peer review are the original identities restored for final synthesis.


Confidence as structured output

Every advisor is required to expose more than a recommendation.

Each analysis includes:

CODE
CONFIDENCE

confidence:
assumptions:
what would change my mind:
unknowns:

This was important because confidence without context is not very useful.

An advisor saying:

confidence: high

matters much less than knowing:

confidence: high, assuming customer acquisition remains below X

The final council can therefore surface not only what it believes, but what must remain true for that recommendation to hold.


Adaptive depth instead of maximum reasoning every time

Not every decision deserves the same computational process.

Claude Council therefore supports three deliberation modes.

ModeAdvisorsPeer ReviewDebateBest For
Quick3Low-cost, reversible decisions
Standard5ConditionalNormal high-stakes decisions
Deep5 expandedAlwaysHigh-cost or difficult-to-reverse decisions

The architecture trades additional computation for additional scrutiny only when the decision justifies it.


06 / The Challenge

Consensus is not always a success condition

A surprisingly difficult problem in multi-agent systems is that adding agents does not guarantee independent thinking.

Five agents can still converge on the same attractive argument.

That creates a dangerous failure mode:

CODE
agreement
   ≠
correctness

Claude Council therefore measures the strength of agreement during peer review.

If consensus is unusually strong, the system becomes more skeptical, not less.

A Prosecutor is asked to attack the dominant recommendation.

Only after that attack does a Defender receive both the consensus argument and the prosecution and attempt to defend it.

The debate therefore becomes sequential:

consensus → attack → defense

rather than two agents independently producing opposing essays.


Preserving useful disagreement

A second problem appears during synthesis.

Even if the council produced useful minority arguments, a final summarization step can accidentally erase them while creating a clean recommendation.

I addressed this with two separate chairman passes.

CODE
                   Council State
                        │
              ┌─────────┴─────────┐
              ↓                   ↓

     Consensus Chairman     Dissent Chairman
              │                   │
              └─────────┬─────────┘
                        ↓

               Dissent Preservation
                        ↓

                  Final Verdict

The first chairman is intentionally majority-oriented.

The second is intentionally minority-oriented.

A final dissent-preservation pass compares both outputs and restores important arguments that the majority synthesis weakened or omitted.

The final goal is not artificial compromise.

It is:

make a recommendation while remaining explicit about why it could still be wrong.


07 / Decision Memory

Claude Council also keeps a persistent record of previous decisions.

Each completed run writes structured metadata to a journal, including:

A user can later record what actually happened:

CODE
decision
   ↓
recommendation
   ↓
real-world action
   ↓
outcome
   ↓
future council context

Before a new council begins, the system can search this history for related decisions.

That means previous decisions are not only archived.

Their outcomes can become context for future deliberation.


Closing the feedback loop

This creates a simple but important feedback cycle:

After enough recorded decisions, the system can perform meta-analysis over the journal to look for recurring calibration patterns.

For example:

This moves the project from a stateless prompting workflow toward an experiment in decision-process calibration over time.


08 / Output

Every full council produces two artifacts.

Decision Report

A visual HTML report containing the important decision state:

Full Transcript

A Markdown transcript preserving the complete deliberation process.

CODE
decision
   ↓
advisor reasoning
   ↓
peer reviews
   ↓
debate
   ↓
chairman synthesis
   ↓
dissent ledger
   ↓
final verdict

The report is intended for quickly understanding the conclusion.

The transcript exists for inspecting how the system reached it.


09 / Current State

Claude Council currently supports the complete decision workflow from question framing to persistent outcome tracking.

Working now

The complete system can be invoked directly inside Claude Code:

/claude-council <decision>


10 / What This Project Demonstrates

Claude Council started from a simple question:

Would several reasoning agents produce better decisions than one?

The more interesting engineering problem became determining how those agents should interact.

The project pushed me to think about:

The value of the system does not come from having five agents instead of one.

It comes from giving those agents different responsibilities, controlled information flow, and opportunities to challenge one another.


11 / Next

There are several directions I want to explore further.

The larger goal is to explore how multi-agent systems can produce better-calibrated reasoning, not simply more reasoning.