ensemble-solving

Ensemble Problem Solving

Generate multiple solutions in parallel by spawning 3 subagents with different approaches, then evaluate and select the best result.

When to Use

Activation phrases:

• "Give me options for..."
• "What's the best way to..."
• "Explore different approaches..."
• "I want to see alternatives..."
• "Compare approaches for..."
• "Which approach should I use..."

Good candidates:

• Architecture decisions with trade-offs
• Code generation with multiple valid implementations
• API design with different philosophies
• Naming, branding, documentation style
• Refactoring strategies
• Algorithm selection

Skip ensemble for:

• Simple lookups or syntax questions
• Single-cause bug fixes
• File operations, git commands
• Deterministic configuration changes
• Tasks with one obvious solution

What It Does

1. Analyzes the task to determine if ensemble approach is valuable
2. Generates 3 distinct prompts using appropriate diversification strategy
3. Spawns 3 parallel subagents to develop solutions independently
4. Evaluates all solutions using weighted criteria
5. Returns the best solution with explanation and alternatives summary

Approach

Step 1: Classify Task Type

Determine which category fits:

• Code Generation: Functions, classes, APIs, algorithms
• Architecture/Design: System design, data models, patterns
• Creative: Writing, naming, documentation

Step 2: Invoke Ensemble Orchestrator

Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]

The orchestrator handles:

• Prompt diversification
• Parallel execution
• Solution evaluation
• Winner selection

Step 3: Present Result

The orchestrator returns:

• The winning solution (in full)
• Evaluation scores for all 3 approaches
• Why the winner was selected
• When alternatives might be preferred

Diversification Strategies

For Code (Constraint Variation):

| Approach | Focus |

|----------|-------|

| Simplicity | Minimal code, maximum readability |

| Performance | Efficient, optimized |

| Extensibility | Clean abstractions, easy to extend |

For Architecture (Approach Variation):

| Approach | Focus |

|----------|-------|

| Top-down | Requirements → Interfaces → Implementation |

| Bottom-up | Primitives → Composition → Structure |

| Lateral | Analogies from other domains |

For Creative (Persona Variation):

| Approach | Focus |

|----------|-------|

| Expert | Technical precision, authoritative |

| Pragmatic | Ship-focused, practical |

| Innovative | Creative, unconventional |

Evaluation Rubric

| Criterion | Base Weight | Description |

|-----------|-------------|-------------|

| Correctness | 30% | Solves the problem correctly |

| Completeness | 20% | Addresses all requirements |

| Quality | 20% | How well-crafted |

| Clarity | 15% | How understandable |

| Elegance | 15% | How simple/beautiful |

Weights adjust based on task type.

Example

User: "What's the best way to implement a rate limiter?"

Skill:

1. Classifies as Code Generation
2. Invokes ensemble-orchestrator
3. Three approaches generated:

• Simple: Token bucket with in-memory counter
• Performance: Sliding window with atomic operations
• Extensible: Strategy pattern with pluggable backends

1. Evaluation selects extensible approach (score 8.4)
2. Returns full implementation with explanation

Output:

## Selected Solution

[Full rate limiter implementation with strategy pattern]

## Why This Solution Won

The extensible approach scored highest (8.4) because it provides
a clean abstraction that works for both simple use cases and
complex distributed scenarios. The strategy pattern allows
swapping Redis/Memcached backends without code changes.

## Alternatives

- **Simple approach**: Best if you just need basic in-memory
  limiting and will never scale beyond one process.

- **Performance approach**: Best for high-throughput scenarios
  where every microsecond matters.

Success Criteria

• 3 genuinely different solutions generated
• Clear evaluation rationale provided
• Winner selected with confidence
• Alternatives summarized with use cases
• User understands trade-offs

Token Cost

~4x overhead vs single attempt. Worth it for:

• High-stakes architecture decisions
• Creative work where first attempt rarely optimal
• Learning scenarios where seeing alternatives is valuable
• Code that will be maintained long-term

Integration

• feature-planning: Can ensemble architecture decisions
• code-auditor: Can ensemble analysis perspectives
• plan-implementer: Executes the winning approach