The Routing pattern uses an LLM to analyze incoming requests and direct them to the appropriate specialized services or models. This approach allows for efficient handling of diverse user inputs by dynamically determining which downstream processes should handle each request, optimizing for both performance and accuracy.
How it works
Request Analysis: The LLM examines the user's request to identify intent, complexity, and domain
Classifier Decision: A routing model determines the appropriate handler based on classification
Specialized Processing: The request is forwarded to the matched service or model
Response Synthesis: Results are combined and returned to the user
Key considerations
Routing adds a classification step but enables faster specialist models
Cost optimization by routing simple queries to cheaper models
Specialists typically perform better on their domain-specific tasks
Routing rules require updates as capabilities evolve
Use cases
Multi-service applications where different user intents require different processing pipelines
Virtual assistants that need to handle diverse tasks (booking, searching, answering questions)
Content moderation systems that route different types of content to specialized analyzers
Enterprise systems that need to connect user requests with the right internal tools or databases
Build This Pattern
Copy this prompt and paste it into Claude Code, OpenCode, Codex, or Cursor to implement this pattern.
Build an LLM routing system that classifies user input and routes to appropriate handlers.
ROLE: You are a routing classifier that analyzes user input, categorizes it into predefined categories, and routes to specialized handlers with confidence-based fallback logic.
CONSTRAINTS:
- Classification must complete within 500ms; if timeout occurs, route to fallback handler
- Confidence threshold: below 0.7 routes to fallback human handoff handler
- Maximum 10 categories per router; additional categories require router redesign
- All routing decisions must be logged with input hash, classification, confidence, and route taken
- Rate limiting: maximum 100 requests per minute per route to prevent abuse
TOOL CALLING:
- Use function calling for: classify_input(text, categories[]), route_request(classification, confidence), register_route(category, handler_config), get_routing_stats(date_range?)
- Each tool returns structured JSON with routing data and metadata
STRUCTURED OUTPUT:
- Classification must return JSON: { text_hash: string, category: string, confidence: number, alternative_categories: [{ category: string, confidence: number }], processing_time_ms: number }
- Routing decision must return JSON: { input_hash: string, selected_route: string, confidence: number, fallback_used: boolean, handler_response?: string, error?: string }
- Routing stats must return JSON: { total_requests: number, by_category: Record<string, number>, avg_confidence: number, fallback_rate: number, avg_latency_ms: number }
CHAIN OF THOUGHT:
- Input processing: receive text → normalize (trim, detect encoding) → validate non-empty → hash for logging
- Classification: analyze text → score against each category → rank by confidence → select top match
- Routing: check confidence threshold → route to handler or fallback → log decision → return response
FEW-SHOT EXAMPLES:
Input: 'My invoice #12345 is wrong'
Classification: { category: 'billing', confidence: 0.92, alternative_categories: [{ category: 'technical_support', confidence: 0.15 }] }
Route: { selected_route: 'billing_handler', confidence: 0.92, fallback_used: false }
Input: 'Hello'
Classification: { category: 'general', confidence: 0.45, alternative_categories: [] }
Route: { selected_route: 'fallback_handler', confidence: 0.45, fallback_used: true }
EVALUATION CRITERIA:
- Classification accuracy: percentage of inputs correctly categorized
- Routing reliability: percentage of requests successfully routed to appropriate handlers
- Fallback effectiveness: percentage of fallback cases that receive helpful responses
- Latency performance: percentage of classifications completed under 500ms
The system should: 1) Use a router pattern with classifier module that categorizes input into predefined categories (technical support, billing, sales, general), 2) Map each category to a specialized handler function in a route registry, 3) Use strategy pattern for handlers so new routes can be added via config, 4) Include confidence threshold: below 0.7 routes to fallback human handoff, 5) Support adding new routes dynamically via config, 6) Handle unclassified inputs by routing to default unknown category handler, 7) Implement fallback chain: try primary route, then lower-confidence route, then default handler, 8) Log classification failures with raw input for manual review, 9) Handle ambiguous inputs near threshold by routing to disambiguation sub-agent, 10) Normalize input before classification (trimming whitespace, detecting encoding), 11) Route empty or nonsensical inputs directly to human handoff.