Summary

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

  1. Request Analysis: The LLM examines the user's request to identify intent, complexity, and domain
  2. Classifier Decision: A routing model determines the appropriate handler based on classification
  3. Specialized Processing: The request is forwarded to the matched service or model
  4. 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.