This system lets you dynamically route incoming user queries to the most appropriate AI agent based on the query’s content.

Let’s see it in action. Imagine a user asking about a product warranty.

{
  "query": "What is the warranty period for the AlphaWidget 5000?",
  "routing_rules": [
    {
      "agent_id": "sales_agent",
      "description": "Handles sales inquiries, product information, and pricing.",
      "keywords": ["buy", "price", "purchase", "product info", "warranty", "guarantee"]
    },
    {
      "agent_id": "support_agent",
      "description": "Deals with technical issues, troubleshooting, and post-purchase support.",
      "keywords": ["troubleshoot", "fix", "broken", "error", "support", "help"]
    },
    {
      "agent_id": "billing_agent",
      "description": "Manages billing, invoices, and payment issues.",
      "keywords": ["bill", "invoice", "payment", "charge", "refund"]
    }
  ]
}

When the query "What is the warranty period for the AlphaWidget 5000?" comes in, the system scans the routing_rules. It finds that "warranty" is a keyword in the sales_agent’s rules. Therefore, the query is routed to sales_agent. If the query was "My AlphaWidget 5000 is making a strange noise," it would match "broken" and "support" and be routed to support_agent.

The core problem this solves is avoiding the need for users to select an agent or for a human to triage. It also prevents agents from being overloaded with irrelevant queries. Imagine a support agent getting asked about pricing all day – not ideal for them or the customer.

Internally, the system uses a combination of keyword matching and potentially more sophisticated Natural Language Understanding (NLU) models. The routing_rules define the intelligence. Each rule has an agent_id (where the query should go), a description (helpful for humans to understand the rule’s intent), and a list of keywords. The system iterates through these rules, checking if any keywords from the query appear in the keywords list of a rule. The first rule that matches typically wins, though more complex systems might use scoring or fallback mechanisms.

The exact levers you control are the routing_rules. You can add new agents, modify existing keywords, and adjust the order of rules if you have overlapping keywords and want to prioritize one agent over another. For instance, if you wanted to prioritize "support" over "sales" for a query like "I need help with my warranty," you’d ensure the support_agent rule had "warranty" in its keywords and appeared before the sales_agent rule in the list.

The surprise here is how effective simple keyword matching can be, even for complex-sounding tasks. The magic isn’t in a hyper-advanced AI understanding the nuance of "warranty," but in mapping specific terms to predefined destinations. A query like "I want to buy the AlphaWidget 5000 with a warranty" could be matched by "buy" to sales, or "warranty" to sales. If you had a rule for "warranty" that routed to a specialized "warranty_claims_agent" and it was listed before the general "sales_agent," that query would go there instead. This allows for granular control without needing to train a massive NLU model for every possible intent.

The next concept to explore is how to handle queries that don’t match any rules, or how to implement confidence scoring for more nuanced routing.

Want structured learning?

Take the full Prompt-engineering course →