conway-1968-how-do-committees-invent

license	Apache-2.0
name	conway-1968-how-do-committees-invent
description	Apply Conway's homomorphism principle to multi-agent system design, recognizing that agent coordination structure predetermines system architecture and capability.
category	Research & Academic
tags	["conways-law","organization","systems-design","architecture","communication"]

SKILL: Conway's Law for Agent Systems

Source: "How Do Committees Invent?" by Melvin E. Conway (1968)

Description: Apply Conway's homomorphism principle to multi-agent system design, recognizing that agent coordination structure predetermines system architecture and capability.

Core insight: Agent coordination topology isn't infrastructure—it's an active constraint that makes certain solution architectures literally impossible to discover, regardless of agent capability.

DECISION POINTS

Agent Count Selection

Problem Complexity Assessment:
├─ Simple (< 3 sub-components)
│  └─ Use 1-2 agents with direct communication
├─ Moderate (3-6 sub-components)
│  ├─ If components are independent → Use 3-4 agents, minimal coordination
│  └─ If components must integrate → Use 2-3 agents, full communication mesh
└─ Complex (7+ sub-components)
   ├─ Can decompose cleanly → Use hierarchical coordination (5-8 agents)
   ├─ Requires tight integration → Limit to 3-4 agents, accept slower progress
   └─ Unknown decomposition → Use single agent until structure emerges

Communication Model Selection

If coordination needs are:
├─ Sequential handoffs → Use pipeline topology (A→B→C)
├─ Parallel + merge → Use star topology (A,B,C → D)
├─ Collaborative design → Use mesh topology (all-to-all)
├─ Hierarchical review → Use tree topology (leaves→branches→root)
└─ Exploratory research → Use single agent initially

Task Delegation Framework

Before delegating subtasks, check:
├─ Can you clearly define interfaces between subtasks?
│  ├─ Yes → Safe to delegate with defined communication
│  └─ No → Keep unified until interfaces emerge
├─ Will subtasks need runtime coordination?
│  ├─ Yes → Ensure agents can communicate during work
│  └─ No → Can use minimal coordination
└─ Is this delegation reversible if integration fails?
   ├─ Yes → Proceed with monitoring
   └─ No → Consider keeping unified longer

FAILURE MODES

1. Resource Fungibility Fallacy

Symptom: "We have 10 agents available, let's use them all to go faster" Detection: When agent count decisions are driven by availability rather than coordination topology Fix: Evaluate coordination requirements first, then determine optimal agent count. Often fewer agents with better coordination outperform many agents with poor coordination.

2. Neutral Delegation Illusion

Symptom: Creating agent assignments without considering architectural implications Detection: When task decomposition focuses only on workload distribution, not system boundaries Fix: Design delegation as preliminary architecture. Map communication needs between subtasks before assigning agents.

3. Coordination Efficiency Trap

Symptom: Restricting agent communication to "reduce overhead" then wondering why solutions are suboptimal Detection: Limited communication paths producing fast convergence to poor solutions Fix: Recognize communication restrictions as solution space constraints. Open necessary paths even if coordination seems expensive.

4. Integration Capability Confusion

Symptom: Expecting better prompts or more capable agents to fix poorly integrated outputs Detection: Repeated integration failures despite agent improvements Fix: Examine coordination structure. Integration requires communication paths during design, not just assembly logic after completion.

5. Reorganization Fantasy

Symptom: Trying to "fix" system architecture through output processing while keeping coordination unchanged Detection: Architecture problems persist despite multiple fix attempts that don't change agent coordination Fix: Change coordination topology to match desired architecture. The homomorphism cannot be bypassed.

WORKED EXAMPLES

Example 1: API Design System

Scenario: Design a REST API for an e-commerce platform

Poor approach (ignoring Conway):

• Assign 6 agents: Authentication, Products, Orders, Payments, Users, Integration
• Minimal communication between agents during design
• Each agent designs their piece independently

Result: 6 separate API designs that don't integrate well, inconsistent patterns, authentication/authorization scattered across services

Conway-aware approach:

• Start with 2 agents: API-Design-Lead + Integration-Validator
• API-Design-Lead creates overall structure and interface patterns
• Integration-Validator continuously checks cross-service consistency
• Add specialized agents only after core architecture is stable

Coordination topology: Centralized with validation feedback loop System outcome: Coherent API with consistent patterns, clean service boundaries

Key insight: More agents created more disconnected subsystems because coordination topology was fragmented

Example 2: Research Report Generation

Scenario: Generate comprehensive analysis of market trends with multiple data sources

Initial attempt:

• 5 agents: Data-Collector, Trend-Analyzer, Competitor-Research, Market-Sizing, Report-Writer
• Sequential handoffs: Data → Analysis → Research → Sizing → Writing

Problem: Report-Writer receives incompatible analysis formats, trend timeframes don't align, competitor data uses different market segments than sizing data

Conway diagnosis: Pipeline topology created rigid boundaries, no coordination during analysis phase

Revised approach:

• 3 agents: Research-Coordinator, Analysis-Specialist, Integration-Writer
• Research-Coordinator maintains overall coherence, communicates continuously with Analysis-Specialist
• Integration-Writer involved from start to ensure compatible formats

Key decision: Fewer agents with richer communication > more agents with handoff boundaries

QUALITY GATES

Task completion checklist:

• Agent coordination topology explicitly mapped and matches desired solution architecture
• Communication paths exist for all required integration points between agent outputs
• Decision made on agent count based on coordination needs, not resource availability
• Task delegation includes interface specifications between subtasks
• Verification that required solution features are structurally possible given coordination topology
• Assessment of what architectures current coordination makes unreachable (documented)
• Integration validation points established if multiple agents involved
• Recovery plan exists if coordination structure proves insufficient
• Clear escalation path to single agent if coordination complexity exceeds benefits

NOT-FOR BOUNDARIES

Don't use this skill for:

• Single-agent tasks: Conway's Law applies to coordination between agents, not individual agent capability
• Simple sequential workflows: If tasks have clear handoffs with no integration needs, standard pipeline patterns suffice
• Fixed system architectures: If solution architecture is predetermined and proven, use standard multi-agent patterns
• Real-time reactive systems: Conway focuses on design-time coordination, not runtime event handling

Use other skills instead:

• For individual agent optimization → Use capability enhancement skills
• For known problem decompositions → Use standard orchestration patterns
• For performance optimization → Use agent efficiency and resource management skills
• For runtime coordination → Use event-driven architecture patterns

When to delegate elsewhere:

• If adding more agents would improve performance without changing architecture → Standard scaling approaches
• If coordination structure is dictated by external constraints → Focus on optimization within constraints
• If system architecture requirements are non-negotiable → Use implementation-focused skills