---
name: multi-model-research-dispatch
description: Patterns for dispatching research and adversarial challenge to external AI models (Codex, Gemini) with reconciliation rules and single-model fallback
topics: [multi-model, research, competitive-analysis, red-team, codex, gemini, dispatch, reconciliation]
---

# Multi-Model Research Dispatch

At higher methodology depths (4+), idea exploration and adversarial challenge benefit from independent research by external AI models. This entry provides dispatch patterns, reconciliation rules, and fallback strategies for research and red-team workflows.

## Summary

### When to Dispatch
| Depth | Research Dispatch | Challenge Dispatch |
|-------|-------------------|-------------------|
| 1-3 | Skip | Skip |
| 4 | 1 external model | 1 external model |
| 5 | Multi-model with reconciliation | Multi-model with reconciliation |

### Graceful Fallback Chain
1. Check if external CLI is available (`command -v codex`, `command -v gemini`)
2. If not installed, skip that model silently — note in Session Metadata
3. If installed, check auth (`codex login status`, `NO_BROWSER=true gemini -p "respond with ok" -o json`)
4. If auth fails, surface loudly to the user with `!` recovery command — do NOT silently skip
5. If auth succeeds, dispatch with timeout
6. If no external models available, fall back to primary model with distinct framing prompts
7. Never block the session waiting for unavailable tools

### Reconciliation Rules
- **2+ models agree** on the same finding = **consensus** — high confidence, present as validated
- **Models disagree** = **divergent** — present ALL perspectives including minority views. Do NOT suppress the minority. A 2-1 split where the lone dissent flags a real risk is more valuable than a comfortable consensus.
- **Single model** (fallback) = skip reconciliation labels. Present findings directly without consensus/divergent framing.

## Deep Guidance

### CLI Availability Check

Before dispatching, verify CLI tools are installed and authenticated:

### Foreground-Only Execution

When an AI agent dispatches research or challenge prompts via a tool runner, always run commands in the foreground. Background execution (`run_in_background`, `&`, `nohup`) produces empty or truncated output from Codex and Gemini CLIs. Multiple foreground calls can still run in parallel if the tool runner supports parallel tool invocations.

```bash
# Codex CLI — step 1: check installed
command -v codex >/dev/null 2>&1 || { echo "Codex not installed — skipping"; exit 0; }
# step 2: check auth
codex login status 2>/dev/null
# Exit 0 = ready. Non-zero = auth failure (surface to user).

# Gemini CLI — step 1: check installed
command -v gemini >/dev/null 2>&1 || { echo "Gemini not installed — skipping"; exit 0; }
# step 2: check auth
NO_BROWSER=true gemini -p "respond with ok" -o json 2>&1
# Check for "ok" in response. Exit 41 = auth failure (surface to user).
```

Two distinct failure modes:
- **Not installed** (`command -v` fails): skip silently, note in Session Metadata
- **Auth failed** (non-zero after install check): surface loudly — tell the user which tool failed and how to fix it:
  - Codex: "Codex auth expired — run `! codex login` to re-authenticate"
  - Gemini: "Gemini auth expired — run `! gemini -p \"hello\"` to re-authenticate"

Auth failures are NOT silent fallbacks — surface them explicitly.

### Timeout Handling

| Dispatch type | Timeout |
|---------------|---------|
| Research dispatch (idea summary + questions) | 120 seconds |
| Challenge dispatch (full brief review) | 180 seconds |

If a dispatch times out:
- Use whatever partial response was received (if parseable)
- Note the timeout in Session Metadata
- Do NOT retry — proceed with available data

### Research Dispatch Mode

**When**: Phase 2 at depth 4-5.

**Prompt template for external model:**

```
You are conducting independent competitive research for a product idea.

IDEA: [1-2 sentence summary of the idea from Phase 1]

RESEARCH QUESTIONS:
1. What are the direct competitors in this space? For each, note what they do well and where they fall short.
2. What indirect alternatives exist — different approaches to the same problem?
3. How do users currently cope without a dedicated solution?
4. What recent market signals exist — funding rounds, product launches, shutdowns, regulatory changes?
5. What adjacent markets or analogous systems could inform this idea?

Be thorough and honest. Acknowledge competitor strengths — do not dismiss them.
Respond in structured markdown with one section per question.
```

**Execution:**

```bash
# Codex
codex exec --skip-git-repo-check -s read-only --ephemeral "RESEARCH_PROMPT" 2>&1

# Gemini
NO_BROWSER=true gemini -p "RESEARCH_PROMPT" --output-format json --approval-mode yolo 2>/dev/null
```

**Processing results:**
- Parse the response as structured markdown
- Extract key findings per research question
- If multi-model (depth 5), run reconciliation (see below)
- Present findings to the user conversationally, not as raw output

### Challenge Dispatch Mode (Red-Team)

**When**: Phase 6 at depth 4-5.

**Prompt template for external model:**

```
You are an adversarial reviewer stress-testing a product idea brief.
Your job is to find weaknesses, challenge assumptions, and surface missed opportunities.

SPARK BRIEF:
[Full content of the draft spark-brief.md]

CHALLENGE INSTRUCTIONS:
1. For each section, identify the weakest assumption and explain why it might be wrong.
2. What competitors or market dynamics does the brief underestimate?
3. What technical feasibility risks are glossed over?
4. What user segments or use cases are missing?
5. If you could only flag ONE critical risk, what would it be?

Be constructive but ruthless. The goal is to strengthen the idea, not validate it.
Respond in structured markdown with one section per challenge area.
```

**Processing results:**
- Parse challenges from response
- Present each challenge to the user one at a time
- For each challenge, ask: "Accept (update the brief), dismiss (explain why it's not applicable), or defer (note as open question)?"
- Track dispositions and update the brief accordingly

### Single-Model Fallback

When no external models are available, the primary model simulates multiple perspectives:

**Perspective 1 — Venture Capitalist**: "Analyze this idea as a VC evaluating a pitch. What's the market size? What's the defensibility? What are the unit economics? Would you invest?"

**Perspective 2 — Competitor's Product Lead**: "You're the product lead at [biggest competitor]. You just learned about this idea. What's your reaction? What would you do to defend your position? What aspects worry you?"

**Perspective 3 — Skeptical End User**: "You're a potential user who has tried and abandoned 3 similar products. What would make you try this one? What would make you abandon it after a week? What's the one thing that would keep you?"

Run each perspective as a separate reasoning pass. Synthesize the three viewpoints into findings the user can act on.

### Model Selection

| Task | Recommended model | Rationale |
|------|-------------------|-----------|
| Research dispatch | Either Codex or Gemini | Both capable of web-informed reasoning |
| Challenge dispatch | Either Codex or Gemini | Adversarial analysis is model-agnostic |
| Depth 4 (1 model) | Prefer Gemini (Google search built-in) | Strongest for competitive research |
| Depth 5 (multi) | Both Codex AND Gemini | Diverse perspectives from different architectures |

### Reconciliation Process (Depth 5)

When two or more models return research findings, reconcile them:

1. **Extract findings**: Parse each model's response into discrete findings (one competitor, one market signal, one risk = one finding).
2. **Match findings**: Compare findings across models. Two findings match if they reference the same entity (competitor, trend, risk) even if the wording differs.
3. **Classify each finding**:
   - **Consensus**: 2+ models independently identified the same finding. High confidence.
   - **Divergent**: Models disagree about the same entity (e.g., one says competitor X is strong, another says X is weak). Present both perspectives with reasoning.
   - **Unique**: Only one model surfaced this finding. Not necessarily wrong — may be the most valuable insight. Present it without discounting.
4. **Synthesize for the user**: Present findings grouped by classification. Lead with consensus (highest confidence), then unique (potential insights), then divergent (needs user judgment).
5. **Never suppress minority views**: A lone model flagging a risk that others missed may be the most important finding in the entire research pass.

### Quality Gates

Before presenting research findings to the user, verify:

- At least 2 competitors or alternatives identified (even at depth 4 with single model)
- Each competitor has both a strength and a weakness documented
- The "do nothing" option is addressed (how users cope without any tool)
- Market timing signals are present (why now?)
- If multi-model: reconciliation labels (consensus/divergent/unique) are applied

### Common Anti-Patterns

| Anti-pattern | Problem | Fix |
|-------------|---------|-----|
| Dismissing competitors | "They're not really competition" — every alternative is competition | Acknowledge strengths honestly |
| Echo chamber | Both models agree because both drew from the same training data | Look for unique findings, not just consensus |
| Recency bias | Focusing only on recent launches, ignoring established players | Include both established and emerging competitors |
| Feature-list comparison | Comparing feature lists instead of positioning | Compare on audience, value prop, and differentiation |
| Silent fallback | External model fails, no mention in output | Always note which models were used and any failures |
| Over-synthesis | Merging distinct findings into one summary, losing nuance | Preserve individual findings before synthesizing |

### Output Format

When presenting research findings to the user, structure them as:

**Competitive Landscape:**
- [Competitor 1]: Strengths — [specifics]. Weaknesses — [specifics]. Why users choose them — [specifics].
- [Competitor 2]: ...
- "Do nothing" option: How users cope today — [specifics]. Why it's insufficient — [specifics].

**Market Signals:**
- [Signal 1]: [What happened, when, why it matters for this idea]
- [Signal 2]: ...

**Expansion Opportunities** (from adjacent market research):
- [Opportunity 1]: [What it is, why it's relevant, how it connects]

**Red-Team Challenges** (from adversarial review):
- [Challenge 1]: [Weakness identified, why it matters, recommended action]
  - Disposition: [accept/dismiss/defer — tracked after user response]
