Multi-agent

Multi-agent systems coordinate specialized components to tackle complex workflows. However, not every complex task requires this approach—a single agent with the right (sometimes dynamic) tools and prompt can often achieve similar results.

​

Why multi-agent?

When developers say they need “multi-agent,” they’re usually looking for one or more of these capabilities:

• Context management: Provide specialized knowledge without overwhelming the model’s context window. If context were infinite and latency zero, you could dump all knowledge into a single prompt—but since it’s not, you need patterns to selectively surface relevant information.
• Distributed development: Allow different teams to develop and maintain capabilities independently, composing them into a larger system with clear boundaries.
• Parallelization: Spawn specialized workers for subtasks and execute them concurrently for faster results.

Multi-agent patterns are particularly valuable when a single agent has too many tools and makes poor decisions about which to use, when tasks require specialized knowledge with extensive context (long prompts and domain-specific tools), or when you need to enforce sequential constraints that unlock capabilities only after certain conditions are met.

​

Patterns

Here are the main patterns for building multi-agent systems, each suited to different use cases:

​

Choosing a pattern

Use this table to match your requirements to the right pattern:

• Distributed development: Can different teams maintain components independently?
• Parallelization: Can multiple agents execute concurrently?
• Multi-hop: Does the pattern support calling multiple subagents in series?
• Direct user interaction: Can subagents converse directly with the user?

​

Visual overview

​

Performance comparison

Different patterns have different performance characteristics. Understanding these tradeoffs helps you choose the right pattern for your latency and cost requirements. Key metrics:

• Model calls: Number of LLM invocations. More calls = higher latency (especially if sequential) and higher per-request API costs.
• Tokens processed: Total context window usage across all calls. More tokens = higher processing costs and potential context limits.

​

One-shot request

User: “Buy coffee”

A specialized coffee agent/skill can call a buy_coffee tool. Key insight: Handoffs, Skills, and Router are most efficient for single tasks (3 calls each). Subagents adds one extra call because results flow back through the main agent—this overhead provides centralized control.

​

Repeat request

Turn 1: “Buy coffee” Turn 2: “Buy coffee again”

The user repeats the same request in the same conversation. Key insight: Stateful patterns (Handoffs, Skills) save 40-50% of calls on repeat requests. Subagents maintain consistent cost per request—this stateless design provides strong context isolation but at the cost of repeated model calls.

​

Multi-domain

User: “Compare Python, JavaScript, and Rust for web development”

Each language agent/skill contains ~2000 tokens of documentation. All patterns can make parallel tool calls. Key insight: For multi-domain tasks, patterns with parallel execution (Subagents, Router) are most efficient. Skills has fewer calls but high token usage due to context accumulation. Handoffs is inefficient here—it must execute sequentially and can’t leverage parallel tool calling for consulting multiple domains simultaneously.

​

Summary

Here’s how patterns compare across all three scenarios: Choosing a pattern:

---