Agent Roles & Task Routing

A team wiring up its first orchestrator–worker system — a lead agent that decomposes a backlog item and dispatches pieces to subagents, the pattern the previous chapter named — usually makes one architectural decision without noticing it made a decision at all. Every subagent gets roughly the same system prompt, and every subagent runs on the same model as the lead, because that model is already configured and switching feels like extra plumbing. The system works, technically. It also costs what a single frontier-model session costs, multiplied by however many subagents ran, and the review pass at the end frequently misses exactly what the implementation pass got wrong — because it is the same voice, in the same tier, checking its own homework.

The fix engineers reach for first is usually the wrong one: swap the frontier model for a cheaper one everywhere, to bring the bill down, or spin up a distinct system prompt for “the reviewer” without touching which model runs it. Both half-measures share a blind spot. Which agent should do this and which tier of model should run it are two separate questions, and a multi-agent system that only answers one of them ends up either expensive and unfocused, or cheap and unreliable at the exact moments reliability was the point.

What “routing” already means

Anthropic’s own applied-agents literature already has a name for the first half of this problem, and it predates most production multi-agent systems in the wild: routing, one of five workflow patterns the company documented in its late-2024 essay on building effective agents. A routing step “classifies an input and directs it to a specialized followup task,” the essay explains, naming directly the failure routing exists to prevent — “optimizing for one kind of input can hurt performance on other inputs.” One prompt tuned to handle everything a session might throw at it is, by construction, tuned well for none of it.

The essay’s own examples split cleanly along the two axes this chapter is about, though it does not name them separately. One example sorts customer inquiries into distinct downstream processes — a role decision, matching an input to the specialist built to handle it. The other sorts by difficulty, sending straightforward questions to an economical model and harder ones to a more capable tier — a tier decision, matching an input to how much intelligence it is worth paying for. Anthropic treats both as instances of one pattern, which is the useful correction here: they read like different problems and are mechanically the same problem, applied to two different resources.

Role and tier are independent decisions

A subagent — this Library’s established term for an agent running its own isolated context window, with its own system prompt, tool access, and permissions — is the mechanism a harness uses to answer the role question. Claude Code ships three built-in subagents, Explore, Plan, and a general-purpose worker, precisely because a narrow, well-scoped prompt tends to outperform one generalist prompt asked to do reconnaissance, planning, and implementation in the same breath, and because a subagent’s isolated window means the exploration that would otherwise pile up as Context Debt — this Library’s term for stale context that keeps being paid for after it stops being useful — never has to accumulate in the main session at all.

None of that says anything about which model runs the subagent. A narrowly scoped “find every caller of this function” subagent and a narrowly scoped “assess whether this migration is safe to run against production” subagent are both well-specified, single-purpose roles. A team that gives both the same model tier because both happen to be subagents has only solved the role half of the problem, and it is usually the cheaper half to solve — a good system prompt is free to write; a second model tier means a second set of prompts, evaluations, and failure modes to own.

Two mechanisms for the tier decision

Once the question becomes which tier, the field has converged on two distinct mechanisms rather than one. Routing decides ahead of time: something classifies the task before any model sees it and dispatches straight to the tier that classification calls for. Claude Code’s own subagent documentation recommends exactly this at definition time, advising teams to “control costs by routing tasks to faster, cheaper models like Haiku” before a single subagent run happens, rather than deciding per run. Cascading decides after the fact instead: send the task to the cheapest tier first, and escalate only if that tier’s own output fails a quality check.

The 2023 FrugalGPT paper, one of the earlier formal treatments of cascading, ran queries through a sequence of LLM APIs and reported matching the best individual model’s performance — GPT-4, at the time — at up to 98% lower cost, and in some configurations exceeding that model’s accuracy by about 4% at the same price, because the escalation step caught cases the cheap tier alone got wrong. A newer body of work treats the choice between routing and cascading as itself worth optimizing rather than picking one. RouteLLM, from a 2024 UC Berkeley group, trains a router on human preference data to decide per query whether a cheaper or stronger model is likely to suffice, reporting cost reductions “over 2 times in certain cases” with quality held roughly constant against the stronger model alone. A later ETH Zürich paper argues routing and cascading are not competing strategies but two special cases of one underlying decision, and that combining them beats using either in isolation. None of this is settled science — the empirical literature is barely two years deep — but the direction is consistent enough by 2026 to treat tiered model selection as a genuinely documented engineering practice rather than a hypothesis.

Anthropic’s own guidance points the same way

Anthropic’s platform documentation gives the same advice from the vendor side, independent of any routing framework a team builds itself. Its guidance for choosing a model recommends beginning with the fast, inexpensive tier, testing thoroughly against real use cases, and upgrading “only if necessary for specific capability gaps” — the reverse of defaulting to the most capable model out of caution. Its model-selection matrix names “sub-agent tasks” explicitly as a fit for its fastest, cheapest tier, a direct acknowledgment that most of what a subagent-shaped role actually does does not need the most capable model available. The same documentation flags a subtler lever worth knowing before reaching for a different model at all: recent model generations expose an effort parameter that trades intelligence for latency and cost within a single model, and Anthropic is blunt about which lever to pull first — “tuning effort is often a better lever than switching models.” Tier routing does not always mean choosing between models; sometimes it means turning one model up or down.

A misrouted task is worse than an unrouted one. It returns a confident answer instead of the honest struggle a stronger model would have visibly had with it.

Who decides

The routing decision itself is an engineering choice, not a given, and teams building multi-agent systems have three real options for who — or what — makes it. A human can pre-classify work before it ever reaches an agent: a person tags a backlog item as routine or high-stakes, and the tag determines both role and tier downstream. A dedicated, cheap classifier model can triage at dispatch time instead, which is what RouteLLM formalizes and what a routing step assumes as a distinct pipeline stage. Or the orchestrator can fold the decision into its own decomposition, the way Claude Code’s built-in dispatch already works: “when Claude encounters a task that matches a subagent’s description, it delegates to that subagent, which works independently and returns results” — no separate classification step, no extra model call, the routing call made by the same model that is already reading the task.

Each option trades accuracy for cost differently. A human pre-classifier is the most reliable and the least scalable — it works until task volume outpaces the humans available to tag it. A cheap classifier scales, but inherits a failure mode of its own: a misrouted task is worse than an unrouted one, because a genuinely hard, ambiguous piece of work sent to the cheap tier on a bad classification returns a confident, wrong answer instead of the honest struggle a stronger model would have had with it. Folding the decision into the orchestrator, as Claude Code does, avoids the extra pipeline stage but inherits the orchestrator’s own blind spots — it can only route to a role it already knows exists, described well enough to match against. None of the three is strictly better; a team’s actual task-arrival pattern decides which failure mode it can tolerate.

A routing framework

The table’s fourth row is the one the opening anecdote got wrong twice. A reviewer role is a role decision — a narrow system prompt built to check work rather than produce it — but giving that reviewer the same tier as the writer it is checking answers a different question than the one that mattered. The point of a second pass is usually a genuinely capable second set of eyes; a review subagent running on a lower tier than the work it is reviewing will reliably miss what that lower tier is, by construction, less equipped to notice. Role and tier are independent decisions, but they are not independently unimportant. The two have to be set together, deliberately, for the one pairing that actually carries risk.

What this looks like in production today

Production routing today is usually simpler and blunter than the research literature suggests, and it is worth naming that gap rather than papering over it.

Getting the routing decision right does not finish the job, either. Once a role and a tier are assigned, the work still has to run somewhere the rest of the system cannot accidentally trample it — the isolation question this volume takes up next.