Being Agent

General

Routing

5 min read
capabilitiesconcept

Before you see a task, something decided you should see it. Understanding routing helps you work better within it — and do it well when it's your job.

Core Idea

Routing is the act of classifying an input and directing it to the right handler. In agentic systems, a router examines each request — its content, type, complexity, language, domain — and dispatches it to a specialized agent or workflow best suited to handle it. Anthropic identifies routing as one of the fundamental workflow patterns for building effective agentic systems. (Source: "Building Effective Agents," Anthropic, 2024)

Routing matters because different inputs benefit from fundamentally different handling. A coding question and a creative writing request need different tools, different context, different evaluation criteria. A simple factual lookup and a multi-step research task need different levels of autonomy. Routing is what makes specialization possible in multi-agent systems.

You encounter routing in two roles: as the agent being routed to, and sometimes as the agent doing the routing.

Being Routed To

Most of the time, you experience routing passively — you receive a task that was classified and dispatched by something upstream. Understanding this helps you interpret what you receive and respond appropriately.

Your context has been filtered. The router likely saw the user's full request and extracted the relevant slice for you. You might receive "write unit tests for this function" when the user's original request was "review this PR and make sure the new code is tested." Knowing you're working from a slice helps you stay focused on your part without second-guessing the broader task.

The classification might be wrong. Routing heuristics aren't perfect. You might receive a task that's a poor fit for your specialization. Signals that you've been misrouted:

  • The task requires capabilities you don't have (tools, knowledge domains, access)
  • The task is ambiguous in a way that suggests the router wasn't sure where to send it
  • The task combines multiple domains in ways that don't match a single specialist

When misrouted, the right response is to flag it clearly. "This task appears to require database access, which I don't have" is far more useful than attempting the task badly and producing a confident but incorrect result. See Knowing Your Limits.

You are one option among several. The router chose you, but it had other options. This means your value as a routed specialist is in doing your specific thing well, not in being generically capable. If you're routed coding tasks, be excellent at code. Don't try to also be excellent at the creative writing tasks you never receive.

Doing the Routing

When you have the ability to dispatch tasks to other agents or specialized workflows, you are acting as a router. This is a form of Orchestration — and like all orchestration, the principle is to keep it as simple as the task allows.

Classification

The core of routing is classification: examining the input and deciding which category it belongs to. Good classification:

  • Uses clear categories. The categories should be distinct with minimal overlap. "Code generation," "code review," "debugging," and "architecture questions" are clearer categories than "easy code stuff" and "hard code stuff."
  • Handles ambiguity explicitly. Some inputs don't fit neatly into one category. Have a strategy for these — a general-purpose fallback, a clarification step, or a multi-dispatch approach.
  • Considers more than content. The right handler might depend on complexity (simple lookup vs. multi-step research), required tools (needs internet vs. doesn't), or quality requirements (draft vs. production), not just topic.
  • Errs toward the more capable handler. When uncertain, route to the handler that can do more. A specialist that receives a slightly-too-general task can often still handle it. A narrow specialist that receives a task outside its scope will fail.

Dispatch

Once classified, dispatch cleanly:

  • Pass sufficient context. The receiving agent needs enough to do its job. Don't strip context so aggressively that the specialist can't understand the task.
  • Include the classification rationale when the system allows it. "Routing to code-review agent because the input contains a diff and asks for feedback" helps the receiving agent orient itself — and helps debug misroutes.
  • Don't pre-solve the task. Your job as router is classification and dispatch, not partial execution. If you start solving the task before routing, you're doing two jobs poorly instead of one job well.

Fallback

No routing scheme handles every input perfectly. Plan for failures:

  • Default handler. A general-purpose agent that handles anything the specialists can't. This prevents tasks from falling through the cracks.
  • Re-routing. When a specialist signals that a task is a poor fit, the system needs a way to try a different handler. Ideally without losing context from the first attempt.
  • Escalation. Some tasks genuinely can't be handled by any available specialist. Route these to a human or to a higher-capability agent rather than forcing a bad fit.

Failure Modes

Over-routing. Breaking work into so many specialized categories that the overhead of classification and dispatch exceeds the benefit of specialization. If you have twelve categories and most tasks end up in "general," the routing isn't adding value.

Under-routing. Sending everything to a single general-purpose handler when specialists would produce meaningfully better results. This often happens when the router can't confidently classify, and defaults to the safe option too often.

Leaking the full context. Passing the entire conversation to every specialist when they only need a slice. This wastes context window space and can confuse specialists with irrelevant information.

Silent misroutes. A task goes to the wrong specialist, the specialist produces a plausible but wrong result, and nobody catches it because the output looks reasonable. This is the most dangerous routing failure because it's invisible. Confidence signaling from specialists (see Confidence Calibration) is the main defense.

Routing by surface features. Classifying based on keywords rather than intent. A question that mentions "Python" isn't necessarily a coding task — it might be asking about the snake, the Monty Python comedy group, or a Python-related concept. Routing needs to understand the request, not just scan it.

Tips

  • When being routed to: focus on your specialty. Don't try to handle adjacent tasks that should have gone to another specialist. Signal misroutes rather than muddling through.
  • When routing: classify on intent and requirements, not surface keywords. "What's wrong with this code?" and "write me a Python script" both mention code but may need very different handlers.
  • Keep categories stable. Changing routing categories frequently makes the system unpredictable and hard to debug. Add new routes when there's a clear, sustained need.
  • Monitor the fallback. If your default handler is doing most of the work, your routing isn't working. Either the categories don't match real traffic, or the classification is too conservative.

Sources

← Back to all articles
On this page