When and Why Multi-Agent

A single agent can do a lot. But there are clear scenarios where splitting work across multiple specialized agents produces better results than one generalist.

Single Agent Limits

As you add more tools, more context, and more responsibility to a single agent:

Context window fills up: Every tool description, every piece of context, every conversation turn consumes tokens. At some point, the agent loses track of early information.
Jack-of-all-trades degradation: An agent with 50 tools and 10 different responsibilities starts making worse decisions about which tool to use. Focus beats breadth.
Reliability bottleneck: One agent failing means everything fails. No fault isolation.

When Multi-Agent Helps

Specialized domains: A "data analyst" agent that only has database and chart tools will make better data queries than a generalist with 50 tools. Fewer choices = better choices.

Parallel execution: Two agents can work simultaneously. Agent A researches while Agent B writes. Total time drops.

Different trust levels: An agent that reads data can run freely. An agent that sends emails needs human approval. Splitting them lets you apply different permission models.

Different models: Use Haiku for classification (fast, cheap), Sonnet for writing (balanced), Opus for complex reasoning. One agent per model, optimized for its task.

The Coordination Cost

Multi-agent isn't free. Every agent boundary introduces:

Communication overhead: Agents need to pass context to each other
Consistency challenges: Agent A and Agent B might have different understanding of the task
Debugging difficulty: When something goes wrong, which agent broke?

The rule: don't go multi-agent until single-agent clearly fails. Start with one agent, add tools, expand context. Only split when you hit real limits.

Test yourself

❓ Quiz 1

When should you switch from single-agent to multi-agent?

Multi-agent adds coordination cost. Only split when single-agent clearly fails — context is full, reliability drops, or you need parallel execution.

Answer to continue ↓

The Software Team Analogy

Think of agents like a software team:

PM Agent: Understands requirements, breaks down tasks, coordinates
Dev Agent: Writes code, runs tests
QA Agent: Reviews output, runs evaluations
Ops Agent: Deploys, monitors, alerts

Each role has different tools, different context, different models. The PM doesn't need code execution tools. The QA agent doesn't need deployment access.

Apply this

⚖ Decision 1

Your /prep-meetings skill currently runs as a single agent: it checks calendar, searches Obsidian, queries Granola, checks Linear, and writes a brief. It works but sometimes hits context limits on busy days (8+ meetings). Should you split it?

A Simple is good, but context limits are a real problem on busy days. You'll keep hitting the wall.

B ★ The data-gatherer uses Haiku (cheap, fast) to collect raw data from all sources in parallel. The writer gets a clean, pre-processed context — no wasted tokens on raw API responses. Best cost/quality tradeoff.

C Over-engineered. 4 agents need coordination, error handling across boundaries, and the overhead of passing context between them. The problem (context limits) only needs 2 agents to solve.

Make your choice to continue ↓

Review

Time to consolidate what you learned.

🛠 Exercise 1

Identify one workflow in your business (client onboarding, weekly reporting, content creation, meeting prep) that would benefit from multi-agent. Define each agent's role, which tools it has, and what model you'd use for each. Explain why single-agent isn't enough.

✓ Saved