An intent router looks simple when it is drawn as three arrows: normal conversation, retrieval, or tools. The hard part is not naming those routes. It is deciding what evidence makes one route more useful than the others, and what the system should do when that evidence is weak.
I began with the smallest useful distinction. Normal chat handles requests that can be answered from the conversation itself. Retrieval is chosen when the answer depends on the user’s private documents. Tools are reserved for actions or live information that cannot be produced reliably from memory. This definition turns the router from a topic classifier into a decision about where trustworthy evidence must come from.
The next step was to make uncertainty visible. Instead of forcing every message into a confident label, the router can return a reason, a confidence signal, and a safe fallback. A request such as “summarize the document we discussed” should not silently become normal chat when no document is available. It should ask for the missing source or explain that retrieval has no usable context.
Evaluation then becomes more concrete. I can build a small set of messages around the boundaries: a factual question that does not need private data, a question that clearly names a document, a request to send an email, and ambiguous cases that mention an action without actually asking the system to perform it. The useful metric is not only routing accuracy. It is whether the selected route gives the user a correct, recoverable experience.
The router is a small component, but it quietly shapes the whole product. When its decisions are understandable, the rest of the agent becomes easier to test. When they are hidden, every failure downstream looks mysterious.