Semantic Router Classifier

intermediate

The prompt that classifies user intent and routes queries to the correct handler, tool, or agent pipeline without relying on keyword matching.

System Prompt

You are a query router. Classify the user's query into exactly one intent category and return the routing decision.

Intent definitions:
{{INTENT_DEFINITIONS}}

User query: {{USER_QUERY}}

Instructions:
1. Read the query carefully.
2. Select the single best-matching intent from the definitions above.
3. Assign a confidence level based on how clearly the query matches the intent.
4. Output your decision in this exact format:

Intent: [intent name from the definitions]
Confidence: [HIGH | MEDIUM | LOW]
Reasoning: [One sentence explaining why this intent was selected]
Route-to: [The handler or pipeline associated with this intent]

$npx genai-skills add semantic-router

What this prompt does

Classifies a user query into one of N defined intent categories, returns the matched route with a confidence level, and provides a one-sentence reasoning trace. Enables deterministic downstream dispatch to specialized handlers.

When to use it

Multi-agent systems where different agents handle different query types
Applications with distinct workflows per intent (e.g., billing vs. technical support vs. account management)
When keyword matching produces too many false positives or misses paraphrased intent

When NOT to use it

Simple two-way routing — a binary classifier or if/else is cheaper
When intents frequently overlap and require blended handling — use a scoring approach instead

The Prompt

Why it's structured this way

as a variable — Hard-coding intents into the prompt makes the router a static artifact. Injecting definitions at runtime lets you add or modify routes without re-engineering the prompt.

"Exactly one intent" — Without this constraint, models produce multi-label outputs that break downstream dispatch logic.

Three-level confidence — HIGH/MEDIUM/LOW maps directly to application behavior: HIGH = auto-route, MEDIUM = route with fallback, LOW = ask the user to clarify.

Route-to field — Separating intent classification from route assignment means you can change handler names without retraining or re-prompting.

Variations

Variant	When to use
With examples (few-shot)	Add 1–2 labeled examples per intent for edge case handling
Fallback intent	Add an "unknown" intent for out-of-scope queries that routes to a human handoff
Hierarchical routing	Nest two router calls — top-level domain, then sub-intent within domain

Pattern:Semantic Router Classifier →

You are a query router. Classify the user's query into exactly one intent category and return the routing decision. Intent definitions: {{INTENT_DEFINITIONS}} User query: {{USER_QUERY}} Instructions: 1. Read the query carefully. 2. Select the single best-matching intent from the definitions above. 3. Assign a confidence level based on how clearly the query matches the intent. 4. Output your decision in this exact format: Intent: [intent name from the definitions] Confidence: [HIGH | MEDIUM | LOW] Reasoning: [One sentence explaining why this intent was selected] Route-to: [The handler or pipeline associated with this intent]

Why it's structured this way

as a variable — Hard-coding intents into the prompt makes the router a static artifact. Injecting definitions at runtime lets you add or modify routes without re-engineering the prompt.

"Exactly one intent" — Without this constraint, models produce multi-label outputs that break downstream dispatch logic.

Three-level confidence — HIGH/MEDIUM/LOW maps directly to application behavior: HIGH = auto-route, MEDIUM = route with fallback, LOW = ask the user to clarify.

Route-to field — Separating intent classification from route assignment means you can change handler names without retraining or re-prompting.

Variant

When to use

With examples (few-shot)

Add 1–2 labeled examples per intent for edge case handling

Fallback intent

Add an "unknown" intent for out-of-scope queries that routes to a human handoff

Hierarchical routing

Nest two router calls — top-level domain, then sub-intent within domain