Routing Logic

How the router skill classifies research requests as quick scan or deep dive -- criteria, depth signals, default behavior, and routing rationale.

The /research router skill is the single entry point for all research requests. After interviewing the user, it classifies the request as either a quick scan (2-4 steps) or a deep dive (5-8+ steps). This page documents the classification criteria, how they are evaluated, and the rationale tracking that supports routing quality improvement.

Classification Criteria

The router evaluates five dimensions from the interview extraction:

Dimension	Scan signal	Deep signal
Question complexity	Single focused question with 1-2 sub-questions	Multi-faceted question with 3+ sub-questions
Explicit depth signals	"quick", "overview", "summary", "brief", "glance"	"thorough", "comprehensive", "deep dive", "detailed", "full analysis"
Comparison scope	Simple comparison (1-2 options, 1-2 dimensions)	Complex comparison (3+ options or 3+ dimensions)
Decision stakes	Low-stakes or informational	Significant trade-offs or consequences
Topic breadth	Well-defined, narrow topic	Broad, novel, or cross-referencing required

No single dimension is decisive -- the router weighs all five together.

Default Behavior

When ambiguous, default to scan. The rationale: deliver fast value first, then offer to go deeper if the user needs more. A scan that surfaces the right answer quickly is better than a deep dive the user did not need.

This default is stated explicitly in the router skill instructions:

"Default when ambiguous -- deliver fast value, offer to go deeper"

Routing Examples

These examples from the skill prompt illustrate the classification in practice:

User prompt	Route	Reasoning
"Research the current state of WebAssembly adoption"	Scan	General topic, focused, no depth signal
"Give me a thorough competitive analysis of AI code assistants"	Deep	Competitive analysis, explicit "thorough" signal
"Should I use Postgres or MongoDB?"	(Ask first)	Decision support, but missing context (use case, scale)
"Research databases"	(Ask first)	Ambiguous topic, unclear scope
"Compare React, Vue, and Svelte for building our new admin dashboard"	Deep	Decision support, 3 options, specific context
"Quick look at what Stripe charges"	Scan	General topic, explicit "quick" signal

Note that some prompts trigger clarifying questions before routing. The router never asks more than 2 questions -- if still uncertain after 2, it makes reasonable assumptions and notes them in the plan.

Routing Rationale

After deciding scan vs deep, the router composes a routingRationale string that captures the full decision logic. This is stored in the skill execution metadata for later analysis of routing accuracy.

A well-formed rationale includes:

How many options are being compared (if applicable)
How many dimensions/criteria the comparison involves
Ambiguity level of the request
Depth signals detected (or their absence)
Final decision with reasoning

Example Rationales

Scan routing:

"2 options, 3 well-defined criteria, well-known products, no depth signal. Defaulting to scan -- focused decision with clear constraints."

Deep routing:

"5+ competitors, user said 'comprehensive', multi-dimensional comparison needed. Routing to deep -- breadth of options and explicit depth signal."

Ambiguous-to-deep routing:

"Single topic, broad scope ('tell me about AI'), no depth signal but topic is vast. Routing to deep -- topic breadth requires structured decomposition."

Research Type Interaction

The research type (general_topic, competitive_analysis, decision_support) is orthogonal to the scan/deep decision. Any research type can be routed to either mode:

Research type	Scan plan	Deep plan
`general_topic`	2-3 steps: search, analyze, synthesize	5-7 steps: search x2, extract, analyze, critique, checkpoint, synthesize
`competitive_analysis`	3-4 steps: search, extract, analyze, synthesize	6-8 steps: search x2, extract, analyze, critique, checkpoint, synthesize, custom
`decision_support`	3 steps: search, analyze, synthesize	6-7 steps: search x2, extract, analyze, critique, checkpoint, synthesize

The key structural differences between scan and deep plans:

Search steps -- scans have 1, deep dives have 2 (broad then focused)
Critique step -- deep only, for self-assessment and confidence gating
Checkpoint step -- deep only, for user review mid-execution
Branching conditions -- deep only, for adaptive quality gates

Observability

Routing decisions are observable through two paths:

Skill execution metadata -- the delegatedTo and routingRationale fields in skill_execution.metadata record every routing decision. Query these from the admin API or Drizzle Studio to analyze patterns.

Admin UI -- the Skill Executions View at /admin/skill-executions shows the metadata JSON for each execution, including routing data. Filter by skill name to isolate routing decisions (the router skill is always research, while delegated skills are research-scan or research-deep).

Improving Routing Accuracy

The routing rationale and execution outcome data enable a feedback loop:

Review completed executions in the admin UI
Compare the routing rationale to the outcome (did the scan answer the question, or did the user need more?)
Identify misclassification patterns (e.g., competitive analyses with 3+ options being routed to scan)
Update the routing criteria in .claude/skills/research/SKILL.md

The priorResearchCheck metadata also provides signal -- if users frequently choose "refresh" or "unique" on scan results, the scan may not be producing sufficient depth.

Skill Definitions -- plan templates for each research type and mode
Execution Flow -- how routing fits into the full lifecycle
Lifecycle Tracking -- where routing data is stored and how to query it