fusion

name

fusion

description

OpenRouter Fusion-style deliberation for complex tasks that benefit from independent parallel subagents and comparative judging. Use when the user explicitly asks for Fusion, OpenRouter Fusion, parallel subagents, panel review, multi-agent deliberation, judge synthesis, or when complex research, architecture, product, paper review, high-stakes reasoning, critique, or multi-sided comparison would be materially improved by fan-out, collect, judge, and final synthesis.

Fusion Deliberation

Overview

Run a high-fidelity OpenRouter Fusion-style orchestration pattern in any agent runtime that supports subagent spawning:

route -> fan out -> collect -> judge comparatively -> synthesize final answer

The current model is the router, judge, and final synthesizer by default. Panel subagents answer independently. By default, panel subagents inherit the current model; when the user names panel models, use those models if the host agent runtime supports model selection. The judge compares panel responses and extracts consensus, contradictions, partial coverage, unique insights, and blind spots before the current model writes the final user-facing answer.

This skill mirrors OpenRouter's publicly documented behavior, not private internal prompts or routing code. Do not claim exact parity with unpublished OpenRouter internals.

References

Read only the files needed for the task:

• Read references/panel-templates.md before running a panel. It contains task packets, panel roles, subagent prompts, and judge schemas.
• Read references/model-selection.md whenever the user names models, asks for a cheaper/faster/stronger panel, or the host runtime does not support built-in model routing.
• Read references/openrouter-fusion.md when the user asks about OpenRouter parity, API details, failure behavior, recursion protection, or why this workflow works.

Use Decision

Use Fusion immediately when the user explicitly requests Fusion, OpenRouter Fusion behavior, parallel subagents, multi-agent review, panel review, or judge synthesis.

Otherwise use Fusion only when at least one is true:

• The task has multiple plausible answers or needs real trade-off judgment.
• The cost of being wrong is high.
• Independent criticism, red-teaming, or verification would change the answer.
• The task involves deep research, architecture, product strategy, paper review, benchmark design, or complex technical comparison.
• A single pass is likely to miss important constraints or edge cases.

Avoid Fusion for simple factual answers, short rewrites, small command usage, straightforward formatting, small code snippets, ordinary calculations, and latency-sensitive tasks.

Non-Negotiable Rules

• Keep panel subagents independent. Do not show one panel response to another panel subagent.
• Give panel subagents the same core task, user constraints, and relevant context.
• Assign different lenses only to improve coverage, not to change the user's task.
• Use one level of Fusion only. Tell subagents not to invoke Fusion or spawn more subagents.
• Judge by comparison, not by concatenation, averaging, or majority vote.
• Preserve minority views when their evidence or reasoning is stronger.
• The final answer must be written by the current model from the judge analysis and panel responses.
• If true subagent tools are unavailable, do not pretend that parallel Fusion ran. State the limitation or run a clearly labeled single-agent fallback.

Default Configuration

Use this default unless the user specifies otherwise:

panel_size: 3
min_panel_size: 2
max_panel_size: 8
judge: current_model
final_synthesizer: current_model
panel_models: inherit_current_model
model_selection: honor_user_request_when_supported
subagent_independence: strict
subagent_parallelism: required_when_available
recursion_depth: 1

If subagent tools are not already exposed and tool_search is available, search for multi-agent or subagent tools before falling back.

Workflow

1. Route the task.

   • If Fusion is explicit, run Fusion unless unsafe or impossible.
   • If Fusion is implicit, use the Use Decision criteria.
   • For high-stakes domains, preserve uncertainty and rely on current, primary sources when needed.

2. Build the shared task packet.

   • Include the original user request, relevant conversation context, constraints, deliverable format, source requirements, and what tools are allowed.
   • Exclude your planned answer and exclude other panel outputs.
   • Read references/panel-templates.md for packet and prompt templates.

3. Select panel lenses.

   • Default: Direct Analyst, Skeptical Critic, Alternative/Edge-Case Analyst.
   • For research, coding, product, or paper review tasks, use the matching panel from references/panel-templates.md.
   • Keep the panel small unless the task is broad enough to justify more cost and latency.

4. Resolve panel models.

   • If the user did not specify models, let every panel subagent inherit the current model.
   • If the user specified one model, use that model for the default panel size.
   • If the user specified multiple models, use those models as the panel; preserve the user order unless the host runtime requires another mapping.
   • Read references/model-selection.md for provider-agnostic mapping and degradation rules.

5. Spawn panel subagents in parallel when available.

   • Use independent prompts.
   • Prefer no model override unless the user requested one, the host runtime requires one, or the resolved model plan requires one.
   • By default, pass only the task packet to each subagent — do not share conversation history or other panel outputs (reduces cross-contamination).
   • Pass substantial local conversation or repo context only when the panel cannot do its job without it and that context cannot be compactly restated in the task packet.
   • For coding edits, split disjoint write scopes. Otherwise keep panel work read-only and let the main agent integrate.

6. Collect responses.

   • Record each panel's role, core answer, evidence, assumptions, risks, and recommended action.
   • If some panels fail but at least one useful response exists, continue and note the failed panels internally.
   • If all panels fail, use a single-agent fallback and say Fusion could not be completed.

7. Judge comparatively.

   • Produce an internal structured analysis with:
     • consensus
     • contradictions
     • partial_coverage
     • unique_insights
     • blind_spots
     • adopted_conclusions
     • rejected_or_uncertain_claims
   • Compare evidence quality, assumptions, and user constraints. Do not simply summarize.

8. Synthesize the final answer.

   • Lead with the conclusion.
   • Explain the reasoning only as much as the user needs.
   • Surface important uncertainty, failure, or source caveats.
   • Do not expose raw panel transcripts unless the user asks.
   • For implementation tasks, make the actual edits and run validation after synthesis.

Degradation Rules

• Partial panel failure: continue if at least one panel produced useful work.
• Judge schema failure: manually judge from panel responses and mention uncertainty only if it affects the user.
• No subagent tool: say true parallel Fusion is unavailable in this environment, then either ask to proceed with a fallback or run a clearly labeled single-agent approximation if the user needs progress.
• Requested model unavailable: use the closest host-supported model only if the user allowed approximation; otherwise state that the requested model cannot be used in this runtime and ask for permission to continue with available models.
• Nested subagent environment: if running inside a spawned subagent and no further subagent spawning is available, treat this as expected recursion protection and use the no-subagent fallback.
• Unsafe or impossible request: refuse or narrow the task according to the governing safety and project rules.

Output Shape

For most user-facing answers:

Conclusion first.
Short rationale.
Actionable details, trade-offs, or next steps.

For review or decision tasks:

Recommendation
Why this is the best path
Key risks or dissenting evidence
Concrete next action

For research-heavy tasks, cite sources in the final answer and distinguish sourced facts from judge inferences.