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):

For Architecture (Approach Variation):

For Creative (Persona Variation):

Evaluation Rubric

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
4. •Evaluation selects extensible approach (score 8.4)
5. •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