Router Pattern

The mental model: a research coordinator dispatching specialists

Imagine a research coordinator who receives a question, say, some unidentified bones just got dug up. The coordinator identifies which experts need to weigh in: an archaeologist, a geologist, a materiologist. It breaks the question into a targeted piece of work for each specialist, sends all three tasks in parallel, waits for their findings, and synthesizes everything into one unified report.

That's the router pattern: a multi-agent architecture where a classification step, not an agent, analyzes the input, breaks it into subtasks, identifies which specialist agents should handle each piece, dispatches all of them in parallel, and synthesizes the results into a single response.

It's optimized for exactly one kind of situation: queries that benefit from consulting multiple knowledge sources simultaneously. If your task is a single, sequential ask, this pattern isn't for you. Parallel dispatch is the whole point.

For example: "What are the economic, environmental, and social impacts of electric vehicles?" The coordinator breaks this into three parts (economics, environmental science, sociology), runs all three at once, and synthesizes a final answer. Depending on the question, it might spin up three specialists, or five, or seven.

The key insight: parallel dispatch to specialists, then synthesis of results.

Characteristics of the router pattern

1. A classification step always runs first - the router analyzes and decomposes the query, identifying the distinct parts and which agents should handle each.
2. Parallel execution is native - multiple agents work simultaneously, always. This isn't an option you can toggle off; it's the pattern's reason for existing.
3. Each agent receives a targeted piece - the classifier packages a domain-specific instruction for each specialist it identifies, not the raw original query.
4. Selective routing - even if the system has fifteen possible specialists registered, only the ones relevant to this particular task get invoked.
5. Result synthesis - a dedicated synthesis step combines every agent's output into one unified response before it reaches the user.
6. Stateless and isolated - each agent's work happens independently, with no context from any other agent. The archaeologist's findings are a world away from the geologist's, until synthesis pulls them together.

Fan-out in LangGraph, using Send

After the classification step, you typically end up with something like:

classification = [
    {"source": "archaeologist", "query": "Assess the bone's morphology and age..."},
    {"source": "geologist", "query": "Analyze the surrounding sediment layer..."},
    {"source": "materiologist", "query": "Determine the mineral composition..."},
]

Send is the star of the fan-out step, it loops over the classification and dispatches one Send object per target agent:

def route_to_specialists(state: ResearchState):
    return [
        Send(item["source"], {"query": item["query"]})
        for item in state["classification"]
    ]

workflow.add_conditional_edges("classify", route_to_specialists)

For collecting results back, use a state field with an additive reducer, otherwise every parallel branch overwrites the last one instead of accumulating:

class ResearchState(TypedDict):
    classification: list[dict]
    results: Annotated[list, operator.add]

Each dispatched node appends its own finding to results; the synthesis step then reads the fully collected list and produces the final answer.

Router vs. sub-agents

These two patterns look deceptively similar (both call multiple specialists), but they differ in almost every dimension:

Benefits vs. trade-offs

Benefits:

• Parallel execution - native to the pattern, giving a significant latency reduction versus any sequential flow.
• Targeted queries - each agent receives an optimized, domain-specific sub-question instead of the raw original query.
• Selective routing - only relevant agents get invoked, even out of a large registered pool.
• Clean separation - no context leaks between agents; each does its work undisturbed.
• Scalable - keep adding specialists; the classifier decides who's relevant and calls them in parallel.
• Predictable - arguably the most predictable of all the multi-agent patterns. You know the steps, the decisions, and how it wraps up, which makes debugging straightforward.
• Cost control - because you know up front which agents will run, you can tune things like max_tokens per agent with confidence, generous limits for elaborate research, tight limits when you just need compact findings, without truncating a dynamic decision-making flow like you risk with sub-agents.

Trade-offs:

• Stateless by default - built for one-shot fan-out. Multi-turn conversations need extra work (checkpointers, re-feeding state into the classification step).
• Classification overhead - an LLM call is spent just to decompose the query before any real work starts.
• Rigid predictability - there's no dynamic re-routing mid-flight; once dispatched, the plan doesn't adapt.
• Synthesis quality depends on prompting - a weak synthesis prompt produces a shallow or muddled final report; the instructions for how to combine results need to be explicit.
• No agent-to-agent interaction - agents never consult each other, not even indirectly through a supervisor. If a task needs specialists to build on each other's findings, this isn't the right pattern.
• Query decomposition quality matters - if the classifier splits the query poorly, everything downstream is garbage in, garbage out. The classifier's prompt deserves as much care as any specialist's.

When to use this pattern

Use the router pattern for tasks that genuinely decompose into independent, parallel sub-questions answered by different specialists, with no need for those specialists to talk to each other or adapt mid-flight.

Common use cases

• Multi-source knowledge retrieval - searching documents, websites, discussion boards, and code simultaneously.
• Research queries - consulting multiple databases or information sources for one composite answer.
• Comparison questions - "Ronaldo or Messi?" spins up one specialist per subject, gathering stats, history, and soft skills in parallel before comparing.
• Aggregation queries - "What are the top 5 agentic tools?" runs the research, then synthesizes a ranked answer.
• Opinion gathering - "What do different news outlets say about X?" pulls and compares takes from multiple sources.
• Agentic RAG with multiple retrievers - pulling from several vector stores or databases for different content types, then merging into one context.
• API aggregation - calling multiple APIs in parallel and synthesizing their combined results; in many ways the foundational use case the others above are built on.