The Council Pattern

The approver problem, and the memory problem underneath it

Nobody had withheld information. The proposal was accurate. A competent reviewer checked it, caught a naming inconsistency, flagged a dependency order question, got both resolved before sign-off. Structure was fine. What the structural review had no reason to look for was the operational question — under what conditions does this run, and what happens if those conditions are met more often than expected. The blind spot wasn’t a failure of effort. It was a consequence of perspective scope: one reviewer, one dimension, one mandate.

A second gap sits underneath the first. When one reviewer approves a proposal, a decision gets made — but what got decided, why, and what constraint it should impose on future proposals lives nowhere but that reviewer’s head. Six months later, a similar proposal arrives and the prior decision is invisible. The council pattern is the architectural response to both problems at once: structured divergence of perspective, plus a mechanism that converts ratified decisions into enforced constraints and persists them across sessions. This book covers the generalized governance pattern — how to design a council as a constraint-producing institution that can govern any kind of proposal in any kind of system, not an application of the pattern to one specific task.

Eleven chapters, from perspective roles to wiring

• what-the-council-is-for — Distinguishes the council from a review checklist, a single senior reviewer, and an approval gate, and identifies the three failure modes it’s specifically built to solve.
• choosing-perspective-roles — How to identify the distinct failure modes your system can suffer, map each to a reviewer domain, and write exclusions that prevent overlapping domains from producing rubber-stamp councils.
• the-proposal-format — The five required fields a proposal must contain for the council to evaluate it without back-and-forth, including the scope boundary and the prior-deliberations link.
• the-deliberation-protocol — The three vote types, the quorum rule, findings incorporation, and what “ratified” actually means.
• the-deliberation-log — Schema design, append-only semantics, precedent-check queries, and long-term maintenance for large logs.
• from-vote-to-constraint — The gap between a ratified decision and an enforced constraint, where constraints live, and the constraint lifecycle: active, superseded, deprecated.
• a-worked-example-end-to-end — Runs a realistic architectural proposal through the full protocol, and shows what the deliberation log entry and constraint entry actually look like.
• failure-modes — The three council failure modes — rubber-stamp, deadlock, and scope creep — with detection criteria and specific fixes.
• the-standing-council — Moving from a one-time pattern to a regular governance rhythm, including session format for a batch of proposals and parallel evaluation.
• wiring-the-council-into-claude — The prompt structure for a council session, the parallel-versus-sequential tradeoff with concrete cost estimates, and the log_deliberation() function.
• conclusion — What changes when deliberation becomes architectural, and why the deliberation log outlasts every other artifact in the system.

A preview

A ratified decision is not the same thing as a decision that got made. Institutional memory is the gap.

Practitioners who’ve hit the approver problem

Practitioners running multi-agent or automated systems who’ve hit the failure mode this book opens with — one reviewer, one dimension, no record of what was already decided. This is advanced material building on an existing multi-agent Claude Code practice, not an introduction to what a review process is. It pairs naturally with Autonomous Morning Reports (Book 49) and Overnight Brainstorming (Book 50) — a council session can evaluate what either produces — and with Agent Messaging (Book 11) for the communication layer a standing council runs on.

A longer excerpt is available to newsletter subscribers.

Buy Ebook on Amazon