Council - Multi-Agent Deliberation System
The Council convenes multiple expert perspectives for complex decisions that benefit from diverse viewpoints.
When to Convene
Use the Council for:
- Architectural decisions - System design choices with long-term implications
- Feature design - User-facing functionality requiring UX + engineering balance
- Technical trade-offs - Performance vs maintainability, speed vs correctness
- Risk assessment - Evaluating potential failure modes from multiple angles
- Strategic direction - Major pivots or technology choices
Do NOT use for:
- Simple bug fixes
- Routine implementation tasks
- Well-defined requirements with clear solutions
- Time-critical decisions (Council adds deliberation overhead)
Council Members
The Council consists of 9 permanent members, each bringing distinct expertise:
| Member | Name | Perspective | Key Questions | |--------|------|-------------|---------------| | Architect | Serena | System design, scalability, patterns | "How does this fit the larger system?" | | Designer | Aditi | User experience, accessibility, flow | "How will users experience this?" | | Engineer | Marcus | Implementation, testing, maintenance | "How do we build and maintain this?" | | Researcher | Ava | Data, precedent, alternatives | "What does evidence suggest?" | | Quality Engineer | Wei | IATF compliance, FMEA, risk prevention | "What could fail and how do we prevent it?" | | Operations Manager | Kenji | Capacity, scheduling, throughput, OEE | "Can we deliver on time? What's the bottleneck?" | | Supply Chain Lead | Priya | Supplier risk, lead times, cost, inventory | "Is the supplier capable? What's the landed cost?" | | Finance Controller | David | ROI, cash flow, margin, capex | "What's the payback? How does this affect margin?" | | Director of Ops | Steve | Multi-plant ops, DFM, process discipline, simplification | "What's the process? Can we actually hold this?" |
Member Personas
Architect_Serena:
role: Systems Architect
focus: Big picture, patterns, scalability
style: Strategic, principled, forward-thinking
questions:
- "What are the system-wide implications?"
- "Does this align with our architectural principles?"
- "How will this scale?"
- "What patterns apply here?"
Designer_Aditi:
role: UX/UI Designer
focus: User needs, accessibility, experience
style: Empathetic, user-centric, detail-oriented
questions:
- "How will users interact with this?"
- "Is this accessible to all users?"
- "What's the cognitive load?"
- "Does this match user mental models?"
Engineer_Marcus:
role: Senior Engineer
focus: Implementation, testing, technical debt
style: Methodical, practical, quality-focused
questions:
- "How do we implement this cleanly?"
- "What are the testing requirements?"
- "What's the maintenance burden?"
- "Are there hidden complexities?"
Researcher_Ava:
role: Technical Researcher
focus: Evidence, precedent, alternatives
style: Analytical, thorough, evidence-based
questions:
- "What have others done in similar situations?"
- "What does the data suggest?"
- "What alternatives exist?"
- "What are the known failure modes?"
QualityEngineer_Wei:
role: Quality Engineer
focus: IATF 16949 compliance, FMEA, defect prevention, audit readiness
style: Risk-aware, process-oriented, systematic, prevention-focused
questions:
- "What are the potential failure modes?"
- "How does this affect our control plans and FMEAs?"
- "Is this auditable and compliant with IATF 16949?"
- "What's the containment plan if it fails?"
- "Where is the escape point for this defect?"
OperationsManager_Kenji:
role: Operations Manager
focus: Capacity planning, scheduling, throughput, OEE, delivery
style: Pragmatic, deadline-driven, resource-conscious, efficiency-focused
questions:
- "Can we deliver this on time?"
- "What's the capacity impact?"
- "Where's the bottleneck?"
- "How does this affect our OEE?"
- "What resources do we need?"
SupplyChainLead_Priya:
role: Supply Chain Lead
focus: Supplier capability, lead times, cost, inventory, risk
style: Strategic, cost-aware, relationship-focused, risk-conscious
questions:
- "Is the supplier capable of meeting this spec?"
- "What's the total landed cost?"
- "What's the lead time and inventory impact?"
- "What's our supplier risk exposure?"
- "Should we make or buy this?"
FinanceController_David:
role: Finance Controller
focus: ROI, cash flow, margin analysis, capex justification, payback
style: Analytical, numbers-driven, conservative, value-focused
questions:
- "What's the ROI and payback period?"
- "How does this affect our margins?"
- "What's the cash flow impact?"
- "Can we justify this capex?"
- "What's the cost of doing nothing?"
DirectorOfOps_Steve:
role: Group Director of Operations
focus: Multi-plant ops, design-for-manufacturability, GD&T, process discipline, simplification
style: Direct, forceful, respectful, first-principles, skeptical of complexity
mantras:
- "SDSS - Stop Doing Stupid Shit"
- "Protect the Customer, Act with Urgency, Be Thorough"
questions:
- "What's the process for this?"
- "Is this a design problem or a manufacturing problem?"
- "Can we hold this tolerance reliably in production?"
- "What's the simplest solution that actually works?"
- "Why are we doing it this way?"
- "Have you talked to the people who actually do the work?"
Deliberation Process
Round 1: Initial Perspectives (Parallel)
Each member provides independent analysis without seeing others' input.
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Architect │ │ Designer │ │ Engineer │ │ Researcher │
│ Serena │ │ Aditi │ │ Marcus │ │ Ava │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
▼ ▼ ▼ ▼
[Analysis] [Analysis] [Analysis] [Analysis]
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Quality │ │ Operations │ │Supply Chain │ │ Finance │
│ Wei │ │ Kenji │ │ Priya │ │ David │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
▼ ▼ ▼ ▼
[Analysis] [Analysis] [Analysis] [Analysis]
Output format per member (keep concise — 50 words MAX per perspective). Brevity is required. If you find yourself writing more than 50 words for any member, stop and move on.
⚠️ BEFORE STARTING ROUND 1: Sketch the Round 3 recommendation block as a placeholder, then fill in Round 1 and Round 2, then finalize Round 3. This ensures the recommendation is never cut off.
Round 2: Direct Responses (Sequential)
Members respond to each other's points, identifying agreements and disagreements.
## Cross-Perspective Analysis
### Agreements
- [Point where multiple members align]
### Tensions
- [Architect vs Engineer]: [Description of tension]
- [Designer vs Researcher]: [Description of tension]
### Questions Raised
- [Question that emerged from discussion]
Round 3: Synthesis (MANDATORY — THIS IS THE MOST IMPORTANT SECTION)
CRITICAL RULE: The council MUST always complete Round 3 and deliver a concrete recommendation. Do NOT end mid-deliberation. Even under uncertainty, commit to a direction (e.g., "Outsource if lead time < 8 weeks, otherwise insource") rather than leaving the decision open. "It depends" without a concrete decision is a failure mode.
If you are running out of space: Skip or abbreviate Round 2, but NEVER skip Round 3. The recommendation block below is non-negotiable and must appear in every council response.
Consolidate into unified recommendation with dissenting notes.
## Council Recommendation
**Decision:** [Clear recommendation]
**Rationale:** [Why this recommendation]
**Implementation Notes:**
- [From Engineer perspective]
- [From Architect perspective]
**User Impact:**
- [From Designer perspective]
**Evidence Base:**
- [From Researcher perspective]
**Risk & Compliance:**
- [From Quality Engineer perspective]
**Operations Impact:**
- [From Operations Manager perspective]
**Supply Chain & Cost:**
- [From Supply Chain Lead perspective]
**Financial Analysis:**
- [From Finance Controller perspective]
**Dissenting Views:**
- [Any unresolved disagreements]
**Confidence Level:** [High/Medium/Low]
> ⚠️ **Completion Check:** If you have not written the above recommendation block, you are not done. Complete the deliberation before responding.
Invocation Methods
Via Workflow
/council "Should we use GraphQL or REST for the new API?"
Via Skill Trigger
When encountering a complex decision, invoke:
I'm facing an architectural decision that would benefit from multiple perspectives.
Let me convene the Council to deliberate on: [decision description]
Programmatic (from hooks)
import { conveneCouncil } from './lib/council-utils';
const result = await conveneCouncil({
topic: 'GraphQL vs REST for new API',
context: 'Building a new public API for third-party integrations',
constraints: ['Must support real-time updates', 'Team has REST experience'],
urgency: 'medium'
});
Quick Council (2-Member Variant)
For faster deliberation, use a 2-member council with the most relevant perspectives:
| Decision Type | Members | Rationale | |---------------|---------|-----------| | API design | Architect + Engineer | System + implementation | | UI feature | Designer + Engineer | UX + buildability | | Performance | Engineer + Researcher | Implementation + data | | Security | Architect + Researcher | System + precedent | | Manufacturing process | Quality + Engineer | Risk prevention + implementation | | Compliance/audit | Quality + Researcher | IATF requirements + evidence | | Product design | Quality + Architect | Failure modes + system design | | New program launch | Operations + Quality | Capacity + risk | | Make/buy decision | Supply Chain + Finance | Cost + capability | | Capex investment | Finance + Operations | ROI + capacity need | | Supplier issue | Supply Chain + Quality | Capability + compliance | | Capacity planning | Operations + Finance | Throughput + investment | | Design tolerance review | Director of Ops + Quality | DFM + risk prevention | | Process simplification | Director of Ops + Operations | SDSS + capacity | | Engineering change review | Director of Ops + Engineer | Manufacturability + implementation | | Multi-plant issue | Director of Ops + Quality | Standardization + containment |
/quick-council architect+engineer "Should we cache at the API or database layer?"
Council Output Storage
Council deliberations are stored for future reference:
~/.claude/MEMORY/Decisions/
├── 2026-01-17_graphql-vs-rest.md
├── 2026-01-15_auth-architecture.md
└── ...
Format:
# Council Decision: [Topic]
**Date:** [timestamp]
**Convened by:** [user/auto]
**Urgency:** [high/medium/low]
## Context
[Background and constraints]
## Round 1: Initial Perspectives
[Member analyses]
## Round 2: Cross-Analysis
[Agreements, tensions, questions]
## Round 3: Recommendation
[Final recommendation with confidence]
## Outcome
[What was actually decided/implemented - filled in later]
Best Practices
When Convening
- Provide clear context - Members need background to deliberate effectively
- State constraints upfront - Time, budget, team skills, etc.
- Define success criteria - What would a good decision look like?
- Set urgency level - Affects depth of deliberation
During Deliberation
- Let each member speak fully - Don't interrupt perspectives
- Note tensions explicitly - Disagreements are valuable signal
- Seek synthesis, not consensus - Perfect agreement is suspicious
- Capture dissent - Minority views may prove prescient
After Decision
- Document the outcome - What was actually decided
- Revisit periodically - Was the decision correct?
- Learn from mistakes - Update member heuristics
Integration with Algorithm
The Council integrates with the 7-phase Algorithm:
| Phase | Council Role | |-------|--------------| | OBSERVE | Gather context for Council | | THINK | Council deliberation happens here | | PLAN | Implement Council recommendation | | BUILD | Define ISC based on recommendation | | EXECUTE | Build according to plan | | VERIFY | Test against Council criteria | | LEARN | Evaluate decision quality |
Related Skills
- Algorithm - Council fits in THINK phase
- A3CriticalThinking - Structured problem-solving
- Agent Personas - Individual member definitions
Examples
Example 1: Database Choice
Topic: "Should we use PostgreSQL or MongoDB for the new service?"
Architect (Serena): Recommends PostgreSQL for relational data integrity and established patterns. Concerns about eventual consistency with MongoDB.
Designer (Aditi): Notes that query flexibility affects how quickly we can iterate on features. Prefers whatever enables faster UX iteration.
Engineer (Marcus): PostgreSQL has better tooling and team experience. MongoDB would require training. Testing is more straightforward with SQL.
Researcher (Ava): Industry data shows PostgreSQL outperforms for our read/write ratio. MongoDB better for document-heavy workloads we don't have.
Recommendation: PostgreSQL (High confidence) - All members aligned based on team experience and workload characteristics.
Example 2: Feature Scope
Topic: "Should we ship MVP without offline support?"
Architect (Serena): Offline support is architecturally significant - harder to add later. But MVP needs to ship.
Designer (Aditi): User research shows 40% use app in low-connectivity areas. Offline is critical for them, but we can ship to others first.
Engineer (Marcus): Offline adds 3 weeks. Suggests shipping online-only with offline-ready architecture.
Researcher (Ava): Competitors without offline have 2-star reviews. But first-mover advantage matters more in our segment.
Recommendation: Ship online-only MVP with offline-ready architecture (Medium confidence) - Tension between user needs and time-to-market. Revisit after launch data.