Classification and Routing
Next come the applied tasks, and the first is the most common: sort the input into classes and send it onward. A router doesn't answer the question, it picks the next contract. The less the categories overlap and the clearer the consequence of an error, the more reliable the routing.
A correct router is a narrow prompt: exactly one route, a closed list, explicit consequences.
# Goal
Choose exactly one route for the next step.
# Routes
- faq: a general question that needs no account data
- account_read: the status or a fact of a specific account is needed
- refund_preview: the user wants to assess refund eligibility
- technical: product diagnosis is required
- human: policy conflict, a threat, a legal promise, or an unknown class
# Rules
- Classify the intent, not individual keywords.
- If one fact is missing to choose between two routes, return clarify.
- Don't call a downstream action and don't answer the user.
# Output
{ route, reason_code, missing_field, normalized_language }Routing quality is almost entirely determined by the category boundaries. Before launch it is worth asking yourself four questions.
- Can two classes apply at once? If so, you need multi-label or a different level of abstraction.
- Is there an unknown or human category? Without it the model is forced to guess the nearest route.
- What happens on an error? Expensive classes require confirmation or a secondary check.
- Is a model even needed? SKUs, enums, and exact commands are cheaper and more reliable to route with ordinary code.
And routing has a pleasant side effect - it separates instructions into different contracts.
Routing separates prompts. Anthropic gives support as a natural example: FAQ, refund, and technical get different downstream processes, prompts, and tools. This reduces the mutual interference of instructions.