Routing separates task selection from task execution
Agentic routing is an architectural pattern rather than a single named algorithm. It emerged as LLM systems gained specialized models, tools, and agents that should not all receive every request.
The router solves selection; the chosen destination performs the work.
The router owns destination choice. The selected model, tool, workflow, or person owns execution.
A router is not a planner or a mixture-of-experts gate
A planner decomposes one task into steps. A tool selector chooses an operation inside an agent loop.
A mixture-of-experts gate activates internal model components, while an agentic router chooses among externally visible execution paths.
These layers may coexist, but their metrics differ. A router is judged by destination choice, a planner by the adequacy of its decomposition, and an executor by the result it produces.
Rules should win when the boundary is already explicit
If a request carries a product identifier, region, or user-selected workflow, ordinary code can route it without a model. A learned classifier earns its cost only for ambiguity the available fields do not resolve.
Hybrid routing often uses rules for permissions and known cases, then a model for the remainder. That keeps safety decisions deterministic while preserving flexibility for natural-language intent.
Routing errors have asymmetric costs
Sending a simple question to an expensive general model wastes money, but sending a refund request to an under-authorized answer bot can block the user. Evaluation should weight each error by what the wrong destination can do, not report accuracy alone.
Support triage makes the failure cost visible
A billing question can go to a read-only account agent, while a refund request must take a path with stronger authentication and an approval step. Routing both to the same broad agent increases its permissions and makes failures harder to contain.
The single-agent versus multi-agent analysis helps decide whether those destinations should exist at all. The common misuse is adding an LLM classifier where a stable field or explicit user choice would route more reliably.
A fallback path must preserve the original request
When the router is uncertain, it can ask a clarifying question, choose a constrained general path, or escalate to a human. Silently choosing the top label hides uncertainty and makes later failures look like executor failures.
The fallback should receive the original request and the router’s evidence, not only its predicted label. That preserves the information needed to correct a bad route.
Continue with these glossary entries: