The council pattern, and when not to use it

A deliberation system is a small bureaucracy. It has offices, a meeting room, and minutes. Sometimes you want a bureaucracy: slow, plural, accountable. Sometimes you want an oracle: one strong model, one prompt, one answer. Most teams pick by temperament. They should pick by the shape of the question, and they can do it on day one.

Two shapes

The council pattern is simple to describe. Several specialised agents draft opinions in parallel. Each advisor has its own system prompt, its own retrieval scope, its own tools, and ideally its own model. The drafts are blind: no advisor sees another's work. A deliberation stage then reads all of them, dissents first, and produces one output with a written rationale. In the building, this is a floor of small offices around one meeting room. The walls keep each advisor's judgment intact; the corridor carries drafts, not gossip.

The oracle is simpler still: one capable model, one well-built prompt, one answer. A single large room with a very good desk. It is cheaper, faster, and easier to eval, and it is the right shape more often than the multi-agent literature suggests.

What deliberation buys

The council earns its cost on judgment-shaped questions: the ones where no verifier exists, where the answer is a position rather than a fact. Should we ship this migration plan. Is this contract clause acceptable. Which of these three architectures will we regret least in a year. Three properties matter here, and the oracle has none of them.

Dissent surfaces what a single pass smooths over. Ask one model to “consider multiple perspectives” and you get a tour, not a fight. The model narrates disagreement it does not actually have. Parallel blind drafts produce real disagreement, because the advisors hold different context, different retrieval, and different instructions about what to protect. The security advisor was told to be paranoid about the audit trail; the delivery advisor was told to be paranoid about the deadline. When they collide, something true about the tradeoff becomes visible.

The deliberation log is an auditable rationale. When someone asks, six months later, why the system recommended against the vendor, you have the drafts, the dissents, and the adjudication in writing. For regulated work, that log is the difference between a defensible decision and a shrug. An oracle gives you an answer and a vibe.

Specialised memory beats one giant context. Each advisor retrieves against its own corpus and keeps its window small and relevant. The alternative, one oracle with everything stuffed into two hundred thousand tokens, attends to everything and privileges nothing; retrieval precision drops as the haystack grows, and effective attention degrades long before the window is full. We have said it before: memory is architecture, not storage. The council is one way to give that sentence walls.

The tax

None of this is free, and the invoice arrives in three currencies.

• Latency. Wall clock is the slowest advisor plus a full deliberation pass: two serial hops at minimum, often three with verification. Councils do not belong on interactive paths.
• Tokens. N drafts plus an adjudicator that re-reads all of them costs roughly N plus one times the oracle, before retrieval. Compaction helps (advisors should emit structured positions with evidence and confidence, not essays), but the multiplier remains.
• Orchestration. Timeouts, partial failures, structured output contracts between stages, and N plus one prompts to version and eval instead of one. Every seat needs its own eval set; so does the adjudicator, scored against held-out human decisions, not against agreement.

And the failure modes are specific enough to deserve names.

Fake diversity. Six advisors generated from one prompt template with the noun swapped share one set of priors. They converge instantly, and you pay six times for one opinion. Diversity has to be structural: different corpora, different tools, different constituencies to protect, different models where budget allows. If you cannot say what each seat knows that the others do not, you have one advisor with six letterheads.

Consensus collapse. A deliberation stage that summarises the drafts has averaged them, and averaging is not adjudication. The adjudicator must be prompted to rule: name the strongest dissent, state why it wins or loses, and commit. If its output reads like meeting minutes, you built a compressor, not a judge.

Sycophancy cascades. Language models agree with confident text placed in front of them. Let advisors see each other's drafts and the later ones drift toward the earlier ones; show them a provisional ruling “for review” and they will endorse it. Keep the drafts blind, and have the adjudicator read dissents before it reads the majority. The order is load-bearing.

Laundered uncertainty. The quiet failure. A council gets built because no human wants to own a decision, and “the system weighed the options” makes acceptable cover. Agents cannot resolve an organisational stalemate; they can only make it more expensive. If the council splits and nobody is named to break the tie, the missing piece is escalation to a human, and that should be a first-class output of the system, not an error state.

When not to build one

Four criteria, each sufficient on its own.

1. The answer is verifiable. If you can run the code, execute the query, or check the number against a schema, deliberation is waste. Use an oracle plus a verifier; a unit test is a better adjudicator than any prompt, because it cannot be argued with. Councils are for questions where verification is impossible, not merely inconvenient.
2. The path is latency-critical. Anything conversational, anything inline, anything a user is watching. Councils live in asynchronous work: reviews, plans, reports, the outputs someone reads over coffee rather than awaits on screen.
3. The calls are low-stakes and high-volume. Classification, routing, extraction. The marginal value of a second opinion is near zero, and the token multiplier never stops running. Spend the budget on structured outputs and a real eval suite instead; both compound, and the council does not.
4. The organisation has one genuine expert. If a single senior person's judgment is what you are trying to absorb, build one room and build it well, with escalation back to that person when confidence drops. Manufacturing four colleagues they do not have dilutes their signal and launders it through consensus. One real expert beats five invented perspectives.

The day-one test

Before any code, answer five questions in writing.

1. Could a verifier (tests, a query, a schema check) confirm the answer? If yes: oracle plus verifier. Stop here.
2. Will anyone ever read the rationale? If no one will open the deliberation log, you do not need to produce one.
3. Can you name the seats? List the advisors and what each one knows, retrieves, or protects that the others do not. Synonyms (“careful reviewer”, “thorough reviewer”) mean fake diversity. Stop here.
4. Can the answer wait? If the latency budget is measured in seconds, oracle.
5. Who breaks a tie? If the honest answer is nobody, the problem is escalation, not architecture. Fix that first.

Five answers pointing the same way, and the council will earn its floor space. Anything less, take the single room.

Deliberate where judgment lives. Declare everywhere else.

Most buildings need one good room before they need a meeting room. Add the second only when you can say who sits in each chair, and why the chairs disagree.