ARTICLE 02 · TAXONOMY · agentlist.io · 2026-09-25 · 7 min read # Agent router vs model router Both promise to route work to the right thing — one picks a model for an inference call, the other picks an agent for a task. They're different layers, and they compose. "Router" is doing two jobs in the agent vocabulary right now, and conflating them produces bad architecture diagrams. A **model router** chooses which LLM answers a request. An **agent router** chooses which agent owns a task. Same verb, different object, different layer of the stack — and in a serious deployment you often want both. ## The model router: inference-level dispatch A model router sits between your agent and the model providers. The unit it routes is a single call: given this prompt, this budget, these latency constraints — which model should answer? The answers are shaped like infrastructure: fall back when a provider is down, send cheap classification to a cheap model, reserve the frontier model for the hard steps. In this catalog that's the **model-router** category — OpenRouter as a hosted marketplace/gateway, LiteLLM as the self-hosted proxy and SDK. The contract is narrow and synchronous: request in, completion out. The model router never knows or cares what the task _is_ — it sees tokens, not tickets. ## The agent router: task-level dispatch An agent router operates one layer up. The unit it routes is a task: an inbound support conversation, a security alert, a ticket, a research brief. Its decision is "which agent — or which specialist inside a multi-agent system — owns this?" and the output is a delegated workflow that may span dozens of model calls, tool calls, and handoffs before anything comes back. That routing shows up in three distinct shapes across the catalog: - **Supervisors inside frameworks.** CrewAI's hierarchical processes, Microsoft Agent Framework's Magentic pattern, and LangGraph's supervisor/swarm topologies all put a coordinator agent in front of specialists — that coordinator is an agent router by function. - **Product routing in business agents.** Support employees like Sierra and Decagon classify and route conversations as part of the job; ops agents like incident.io and Rootly route alerts to the right runbook or responder. The router is a feature of the employee, not a product. - **Protocol-level delegation.** A2A's task exchange and agent communication platforms (Scout's ask/tell mesh) make "route this task to another agent" an interoperable call rather than a framework internal. ## Why people mix them up Both sell "route to the right thing," both live in front of a pool, and the boundary is genuinely blurring: model gateways are adding agent-aware routing (classify the request, pick a model _and_ a system prompt), and agent frameworks embed model routing as a feature. The distinguishing question that resolves it: does the router see a prompt, or a task? Prompt → model router. Task with identity, scope, and consequences → agent router. ## The quick diff **What gets routed**: Model router: a single inference call. Agent router: a whole task — a ticket, a conversation, an incident. **Decision inputs**: Model router: price, latency, context size, capability, fallback health. Agent router: which agent's skills, tools, and data scope fit the task. **Output**: Model router: one completion. Agent router: a delegated workflow — possibly many model calls, tool calls, and further delegation. **Where it lives**: Model router: between your agent and LLM providers (a proxy or SDK). Agent router: in front of your agents — a supervisor, dispatcher, or directory. **Catalog examples**: Model routers: OpenRouter, LiteLLM. Agent-routing behavior: CrewAI/Agent Framework supervisors, A2A delegation, ops agents triaging to runbooks. ### When you need which One agent, several models → model router. Several agents, incoming work → agent routing (a supervisor, a dispatcher, or an agent-communication protocol). Running a fleet of agents each of which should pick its own model → both, at their own layers: the agent router assigns the task, each agent's model router optimizes the inference. They compose; they don't compete. --- Source: [Agent router vs model router | agentlist.io](https://www.agentlist.io/articles/agent-router-vs-model-router). This is the public page rendered as Markdown; interactive controls require the website.