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:

[Member] Perspective

Assessment: [1-2 sentence summary]

Key Considerations:

1. [Point 1]
2. [Point 2]
3. [Point 3]

Recommendation: [Specific recommendation]

Concerns: [Any reservations or risks]

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

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]

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.