Chapter 8

Use a Router for Bounded Classification

A router chooses the right executor but doesn't have to become a long-term interlocutor or a universal supervisor. It works well when the categories are distinguishable: billing, technical support, fraud; frontend, backend, infrastructure; public docs, internal knowledge, repository search. And the cheapest reliable classifier should go first: exact rule, metadata, small model, and only then a more expensive fallback.

TypeScript

import type { AgentId, TaskKind, WorkItem } from "./types.js";

const ROUTES: Readonly<Record<TaskKind, AgentId>> = {
  plan: "planner",
  test: "tester",
  security: "security",
  docs: "docs",
  review: "reviewer"
};

export function routeTask(task: WorkItem): AgentId {
  return ROUTES[task.kind];
}

export function explainRoute(task: WorkItem): string {
  return `${task.kind} -> ${routeTask(task)} by deterministic policy`;
}

The router variants and their main risk are worth keeping in view.

Option · When it fits · Main risk

Rule-based - The category is already in the input or set by an exact condition; Rules grow without an owner
Model classifier - You need a semantic classification of a short input; An unstable route without a confidence policy
Fan-out router - One request contains independent domains; Duplicated context and extra workers

LangChain documents a router as a separate dispatch step that can call several agents in parallel and then synthesize the outputs. Unlike a supervisor, a router usually doesn't keep a long history and doesn't repeatedly decide what to do next.

Don't trust confidence as permission. The model's self-assessment is not a security boundary. Low confidence may send a task to human triage, but high confidence must not widen the chosen worker's rights.

The router distributed the input. When one owner needs to gather several experts and answer for the result, the final answer is kept with the manager.

Use a Router for Bounded Classification

Links