Recursive Synthesis

Recursive Synthesis

Orchestrate multi-agent collaborative document synthesis through 6 phases to produce authoritative founding documents that require rigorous multi-perspective analysis.

Decision Points

Primary Execution Tree

Is this a founding document (constitution, charter, ADR)?
├── NO → Use single-author writing skills instead
└── YES → Continue to phase selection

Are 10+ perspectives genuinely needed?
├── NO → Use standard collaborative writing
└── YES → Continue to agent selection

Are there irreconcilable tensions expected?
├── NO → Use simplified consensus process
└── YES → Full 6-phase recursive synthesis
    │
    ├── Phase 0: Setup (always required)
    │   ├── Problem scope clear? → NO: Clarify before proceeding
    │   ├── Agents selected for max diversity? → NO: Redesign roster
    │   └── Ground rules established? → NO: Define steel-man rules
    │
    ├── Phase 1: Divergence
    │   ├── All 10 papers received? → NO: Wait/chase missing
    │   ├── Genuine diversity achieved? → NO: Replace echo agents
    │   └── Quality threshold met? → NO: Request rewrites
    │
    ├── Phase 2: Synthesis
    │   ├── Convergence > 50%? → YES: Proceed to commentary
    │   ├── Convergence 25-50%? → Flag high-tension synthesis
    │   └── Convergence < 25%? → Abort: Unsynthesizable problem
    │
    ├── Phase 3: Commentary
    │   ├── All steel-man sections present? → NO: Enforce requirement
    │   ├── Irreconcilable tensions flagged? → YES: Prepare dissenting appendix
    │   └── Constructive amendments provided? → NO: Request specifics
    │
    ├── Phase 4: Consolidation
    │   ├── Soul Document coherent? → NO: Lead Architect revision
    │   ├── Dissenting Appendix honest? → NO: Add minority voices
    │   └── Scope clearly documented? → NO: Define boundaries
    │
    ├── Phase 5: Reality Check
    │   ├── Any "COMPLEX" verdicts? → YES: Major rework required
    │   ├── Multiple "BUILD" verdicts? → YES: Address P0/P1 demands
    │   └── Majority "SHIP" verdicts? → YES: Proceed to final merge
    │
    └── Phase 6: Final Merge
        ├── Constitution authoritative? → NO: Strengthen principles
        ├── Practitioner's Guide actionable? → NO: Add concrete steps
        └── Editorial Notes complete? → NO: Document all decisions

Model Selection Decision Tree

Which agent type?
├── Philosophical/Complex reasoning → Use Opus
├── Domain-specific technical → Use Sonnet  
└── Senior practitioner judgment → Use Opus

Which phase?
├── Phase 1 (Divergence) → Mix: 4 Opus (complex), 6 Sonnet (technical)
├── Phase 2 (Synthesis) → Opus (long context required)
├── Phase 3 (Commentary) → Match Phase 1 model per agent
├── Phase 4 (Consolidation) → Opus (highest judgment)
├── Phase 5 (Reality Check) → Opus (senior practitioner)
└── Phase 6 (Final Merge) → Opus (best writing quality)

Failure Modes

Echo Chamber Collapse

Symptoms: All agents reach similar conclusions despite different prompts; position papers sound alike; no genuine tensions emerge Diagnosis: Agent selection lacks intellectual diversity OR prompts insufficiently enforce perspective differences Fix: Replace 3-4 agents with genuinely opposing viewpoints; strengthen agent persona prompts with specific belief systems; enforce no-cross-talk rules

Premature Convergence

Symptoms: Synthesis phase finds 80%+ agreement; few items in dissenting appendix; Reality Check agents have no major concerns Diagnosis: Problem wasn't complex enough to require recursive synthesis OR agent perspectives were too narrow Fix: Either abort to simpler process OR restart with more adversarial agent selection (add contrarians, edge cases, minority positions)

Context Window Degradation

Symptoms: Later phases lose nuance from earlier phases; agents reference incomplete information; final document doesn't reflect early insights Diagnosis: Token limits causing information loss between phases OR inadequate summarization strategy Fix: Use structured references instead of full text; create phase summaries at each transition; implement strategic excerpt selection

Analysis Paralysis

Symptoms: Agents get stuck in Phase 3 commentary requesting endless revisions; Lead Architect can't reconcile conflicting demands; Reality Check identifies problems but no solutions Diagnosis: No clear decision-making authority established OR quality gates too perfectionist Fix: Designate tie-breaking authority; set "good enough" thresholds; impose time boxes on each phase; accept documented tensions rather than forcing resolution

Complexity Theater

Symptoms: Process generates more meta-documents than actual content; agents debate methodology more than substance; final Constitution is less clear than original problem statement Diagnosis: Process became end in itself rather than means to clarity Fix: Enforce deliverable-focused phase gates; require every meta-document to improve end-user experience; Constitution must be simpler than process that created it

Worked Examples

Case Study: API Governance Constitution

Context: Engineering org with 50+ microservices needs unified API design principles. Current state: conflicting guidance, inconsistent implementations, integration friction.

Phase 0 Setup: Agent selection for maximum tension:

• REST Purist (OpenAPI, resource modeling)
• GraphQL Advocate (single endpoint, type safety)
• Performance Engineer (caching, latency optimization)
• Security Expert (auth, validation, threat modeling)
• Developer Experience (SDK generation, documentation)
• Event-Driven Architect (async messaging, eventual consistency)
• Legacy Systems Integrator (backwards compatibility)
• Domain Expert (business logic, service boundaries)
• Platform Engineer (infrastructure, deployment)
• Mobile-First Designer (bandwidth constraints, offline)

Phase 1 Divergence Results:

• REST Purist: "APIs must be resource-oriented with proper HTTP semantics"
• GraphQL Advocate: "Single endpoint with strong typing eliminates versioning hell"
• Performance Engineer: "Cache headers and compression are non-negotiable"
• Security Expert: "Zero-trust architecture with API gateway authentication"
• Developer Experience: "Auto-generated SDKs from machine-readable specs"

Key insight: These aren't just different opinions—they represent fundamentally different mental models of what an API should optimize for.

Phase 2 Synthesis Challenge: Synthesizer finds convergence on:

• Machine-readable specifications (100% agreement)
• Consistent authentication (90% agreement)
• Proper error handling (80% agreement)

But irreconcilable tensions:

• REST vs GraphQL (fundamental architectural choice)
• Sync vs Async (different consistency models)
• Developer convenience vs Performance optimization

Phase 3 Commentary Reveals:

• Performance Engineer steel-mans GraphQL: "Eliminates over-fetching, reduces round trips"
• GraphQL Advocate steel-mans REST: "Simpler caching, better HTTP tooling support"
• Both critique synthesis for trying to support both paradigms

Phase 4 Consolidation Decision: Lead Architect makes architectural choice: "REST-first with GraphQL gateway for specific use cases" Dissenting Appendix: Documents when GraphQL is preferred, migration path

Phase 5 Reality Check Catches:

• EM: "No rollout timeline provided - this will take 18 months minimum"
• PM: "No metrics for measuring adoption success"
• Design: "No user journey for external developers consuming these APIs"

Phase 6 Final Output:

• Constitution: 12 core principles with REST-first architecture
• Practitioner's Guide: Step-by-step API design checklist with templates
• Editorial Notes: Documents GraphQL exception criteria and review process

Quality Gates

Phase-by-Phase Completion Rubric

Phase 0 Complete When:

• Problem definition is one clear sentence
• 10 agents selected with maximum intellectual diversity
• Ground rules include steel-man requirement
• File structure created with all directories
• PM/EM/Design excluded from Phases 1-4

Phase 1 Complete When:

• All 10 position papers received (1500+ words each)
• Each paper states 3-5 non-negotiable principles
• Papers represent genuinely different perspectives (not echoes)
• No coordination detected between agents
• Each paper includes concrete examples/case studies

Phase 2 Complete When:

• Principle hierarchy created with ranked-choice logic
• Convergence analysis shows Universal/Strong/Minority/Unique categories
• All irreconcilable tensions explicitly mapped
• Structural skeleton addresses all major themes
• No position paper ignored or misrepresented

Phase 3 Complete When:

• All 10 commentaries received
• Every commentary includes 3-point steel-man section
• Critiques are specific with line numbers/quotes
• Constructive amendments proposed (not just problems)
• Irreconcilable tensions confirmed/refined

Phase 4 Complete When:

• Soul Document speaks with one coherent voice
• Commentary integration decisions documented
• Dissenting Appendix handles tensions honestly
• Document scope clearly bounded
• All major positions represented fairly

Phase 5 Complete When:

• All 3 reality reports received (PM/EM/Design)
• Each report includes SHIP/BUILD/COMPLEX verdict
• P0/P1 demands are specific and actionable
• Fresh perspective genuinely challenges assumptions
• Implementation concerns surfaced and prioritized

Phase 6 Complete When:

• Constitution is authoritative and stands alone
• Practitioner's Guide provides concrete next steps
• Editorial Notes explain all major decisions
• All P0 Reality Check demands addressed
• Final deliverable simpler than process that created it

Success Metrics

• Authoritative: Constitution resolves 80%+ of future disputes in domain
• Actionable: Practitioner can implement without further clarification
• Honest: Dissenting Appendix documents real tensions, not theater
• Bounded: Clear scope prevents mission creep
• Adoptable: Reality Check confirms implementability

NOT-FOR Boundaries

Do NOT use recursive synthesis for:

• Simple documentation: README files, API docs, how-to guides → Use single-author writing instead
• Time-sensitive decisions: Incident responses, urgent releases, hotfixes → Use rapid decision-making instead
• Uncontested domains: Well-established practices, purely technical specs → Use standard documentation instead
• Single-stakeholder documents: Team procedures, individual role definitions → Use collaborative editing instead
• Exploratory work: Research summaries, market analysis, brainstorming → Use research and analysis skills instead

When to delegate instead:

• For team formation → Use team-builder skill
• For execution planning → Use dag-planner skill
• For multi-phase coordination → Use orchestrator skill
• For conflict resolution → Use negotiator skill
• For quick consensus → Use facilitator skill

Anti-boundaries (when you SHOULD use this):

• Constitutional documents that will govern future decisions
• Architecture decisions with multiple valid approaches
• Organizational charters with competing values
• Any document where "getting it right" matters more than speed
• Situations where irreconcilable tensions must be surfaced, not buried