Agent Routing

What it is

Choosing which agent should receive a unit of work before that agent begins. The inputs are the incoming request or task and the set of agents currently available; the output is an identity. It happens at the edge of a system when a message arrives, and inside a coordinated effort when a supervisor assigns a step.

Why it matters

Once more than one agent exists, something has to choose, and that something is usually an accident of how the product grew — a conditional in a request handler, or the first match in a list. Making the choice an explicit, inspectable decision is what allows specialised agents to exist at all: narrow agents are more reliable and easier to evaluate than one agent that does everything, but they are only worth building if work reliably reaches the right one. The choice also carries entitlement consequences, because it determines which tools and which data scopes the work will be processed under.

What this decision is, and two things it is not

Picking a model and picking an agent are different decisions with different consequences. A model choice changes who answers one request; an agent choice changes the instructions, the permitted tools, the memory, and the autonomy under which the whole task proceeds — see Model Routing for the former, which may also happen inside whichever agent is chosen here. Separately, this is a decision taken before work starts: moving a task that is already under way to a different agent, with everything it has accumulated, is a transfer, not a selection.

Key decisions

• What the choice reads: an intent declared by the caller, a classifier over the request, similarity against agent descriptions, or deterministic rules over structured fields.
• Whether a choice holds for a session or is retaken per message. Switching agents mid-conversation is far more disruptive than switching models, because the new agent does not have the working context the previous one built.
• What happens when nothing matches well: a generalist fallback, an explicit unroutable outcome, or a clarifying question to the user. Having no third option forces every request into the nearest agent.
• Whether more than one agent may be selected, which immediately creates a reconciliation problem that did not previously exist.
• Whether the decision is entitlement-aware, since the best-matching agent may be one this caller or tenant is not permitted to use.

Failure modes

• Choices are made from agent descriptions written as promotional copy, so whichever agent claims the broadest competence absorbs traffic it handles badly.
• The decision is itself a model call on the critical path, and its tail latency exceeds that of the agent it selects.
• Wrong choices are invisible because the receiving agent answers anyway — plausibly and incorrectly — instead of declining work outside its scope.
• Session continuity is absent, so a follow-up such as "and the second one?" is decided afresh and lands on an agent with no idea what the first one was.
• A newly published agent quietly takes work from an existing one because their descriptions overlap; quality drops with no deployment to attribute it to.
• Rules hard-code agent names, so a rename or retirement breaks the decision path in a way the catalogue cannot see.
• Decisions are not recorded, so a quality regression cannot be attributed to the choice rather than to the agent that received it.
• Entitlement is checked after the choice rather than during it, producing a refusal where a different agent could have served the request.

Related capabilities

• Agent Registry — supplies the candidate set and its declared facts
• Agent Handoff — what happens when work must move after it has started
• Multi-agent Orchestration — the scheme within which supervisors make this choice
• Agent Definition — declares the facts a rule can test
• Autonomy Levels — the chosen agent brings its own permission envelope

Applies: Production readiness · Design questions