Agent router vs model router

"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.