Four Multi-Agent System Patterns Compared: Subagents, Skills, Handoffs, Routers

A familiar story: a team builds an elaborate agent system with several models, tangled routing and agents that spawn other agents, then finds that a single-agent version thrown together over a weekend beats it on latency, debuggability and every other metric that matters. Getting out of that trap starts with seeing that almost every serious multi-agent system is built from four patterns, and knowing what each one costs you and what it buys.

Do you need multiple agents at all?

Usually not. Reaching for a multi-agent framework in week one is common, driven by hype and the appeal of a diagram full of arrows, and the result is often fragile and pricey where one agent with good prompts would have done better.

Two situations do justify the extra machinery. One is the context window ceiling. You can't stuff legal analysis, medical coding, financial modeling and sentiment handling into one prompt and expect coherent output, since a crowded context drags down quality and slows responses. The other is team ownership. When one team owns inventory and another owns order fulfillment, making them share one monolithic prompt invites conflicts, broken deployments and confusion over who owns what. With either problem in play, the patterns below become a practical answer instead of architecture for its own sake.

Subagents: the chief of staff

Think of a chief of staff who never does the work personally but knows exactly who to ask. A main supervisor agent holds the big picture. When it needs CRM data pulled, an email drafted or a calculation run, it invokes a specialized subagent as if it were a tool, gets the result back and assembles everything.

The appeal is cleanliness. Each subagent works in isolation with its own narrow context, so nothing bleeds between domains: the legal subagent knows nothing about inventory. That isolation pays off when domains are large and distinct, since each specialist can carry deep instructions without competing for space with unrelated material. It also makes testing easier, because one subagent can be evaluated on its own. The price is an additional model call per request, because results travel back up through the supervisor, so three subagents mean three extra round trips. Latency-sensitive apps feel that quickly.

It suits research platforms that hand work to domain specialists, personal assistants coordinating calendar, email and tasks at once, and healthcare triage where a lead agent dispatches to clinical subagents in parallel. One published research setup, with a large model leading and smaller models as subagents, reportedly beat a standalone large model by more than 90% on internal benchmarks. Parallel reasoning in separate context windows is powerful when the task calls for it.

Skills: one agent, many hats

Technically this is still a single agent, though it doesn't act like one. It begins each conversation knowing only the names and short descriptions of the skills available, and loads a skill's full context when something relevant comes up. A generalist doctor works the same way, pulling up the specialized protocol when a particular condition appears and not memorizing all of them for every consultation.

The practical win is independence. A Python team maintains the Python skill and a database team maintains the SQL skills, each as its own package, and nobody coordinates around a shared prompt. For distributed engineering organizations that's a real relief. The catch is token buildup: the longer a conversation runs and the more skills it loads, the heavier the context gets, which eventually hurts both cost and quality late in a session. It's manageable but real.

Skills fit coding assistants shifting between frontend, backend and infrastructure modes, creative tools switching writing styles, and support agents that load specialist knowledge depending on the customer's actual problem.

Handoffs: the relay race

If subagents are parallel delegation and skills are dynamic specialization, handoffs are sequential progression, closest to how people move through a complicated process. A user starts with Agent A. Once something is said or a condition is met, control passes to Agent B, with its own system prompt, tools and maybe personality, and later to Agent C. All the while the state, meaning everything discussed and decided, goes along with each transfer.

Transitions are driven by state. Agents don't simply call one another; they update shared state, and that state decides who is active next. In effect it's a state machine with agents as the states.

That's a natural shape for multi-stage support flows (triage, then diagnosis, then resolution), legal intake where conflict checks must precede matter intake, and checkout flows where payment can't begin before the cart is confirmed. The trade-off people forget is that sequential means no parallelism: if you must query three knowledge bases at once, look elsewhere. It's for workflows where Step B truly can't start until Step A finishes. State management is also hard, and when a handoff chain breaks, debugging isn't trivial, so budget extra time for tracing and observability tooling before committing to this route.

Router: the air traffic controller

Conceptually it's simple. Something at the front classifies each incoming query and dispatches it to the right specialist or specialists. They run in parallel, and their results are merged into a single response. The router keeps no state, so every request is handled independently.

Its strength is throughput. A question spanning three knowledge domains hits all three agents at once, and total time is roughly that of the slowest call, not the sum. In an enterprise knowledge base, an employee's question might touch HR policy, IT security guidelines and finance compliance; the router fires all three agents together and synthesizes one answer, where otherwise you'd need three queries or one overloaded agent holding three domains.

The honest limit is that stateless means memory-less. A follow-up question arrives with no trace of what came before, a real problem for conversational products. The usual fix wraps the router in a stateful outer agent that keeps the history, though that combines patterns and adds complexity. Routers fit high-volume systems with clearly separate verticals, anything needing several knowledge sources simultaneously, and cases where per-request consistency matters more than conversational continuity.

Choosing

It needn't be agonizing.

• Several distinct domains, clean parallel execution and centralized control point to subagents.
• One agent with many specializations, owned by different teams, points to skills.
• A workflow that is inherently sequential, with preconditions and state carried forward, points to handoffs.
• Large query volumes across distinct verticals, needing parallel work without conversation history, point to a router.

One more consideration is performance. The stateful patterns, skills and handoffs, save roughly 40 to 50 percent of model calls on repeat requests because they remember earlier context. Subagents and routers are stateless and pay the same cost every time, but in return get strong context isolation, which matters for large-domain parallel workloads.

Restraint comes first

Don't build multi-agent systems to feel sophisticated; build them to solve a problem you've actually hit. A sensible progression is one agent with genuinely good prompts, then tools, and only then multi-agent patterns, once you've met a concrete wall such as context overflow, friction over team ownership or a need for parallelism a single agent can't supply. The teams with the best systems tend to be those who resisted complexity longest and could explain why every piece existed.

What comes next

Think of these four patterns as the basic grammar of multi-agent design at present, with new vocabulary arriving fast. Persistent local agents that keep memory across sessions and connect to personal files and apps are moving from research into products. The Model Context Protocol, reported at 97 million installs in early 2026, is turning into the plumbing that lets agents from different providers talk without custom integration. Agent networks that spawn new agents dynamically, scaling their own workforce to task complexity, are starting to appear. Subagents, skills, handoffs and routers underpin all of it, so absorbing them now gives a head start. A rule of thumb for deciding: write down the concrete problem first, name the pattern that answers it, and only then draw the diagram. Start simple, be honest about what you need, and when you do go multi-agent you'll know which door to pick.