Subagents and multi-agent systems.

Key terms

Subagent

An agent that another agent starts and hands a task to. It works in its own context window, with its own instructions and tools, and returns a result.

Multi-agent system

Several agents working together on one job. Anthropic defines an agent here as an LLM autonomously using tools in a loop.

Orchestrator (lead agent)

The agent that plans the job, splits it into tasks, hands them out, and combines the results.

Worker

A subagent that does one delegated task for the orchestrator and reports back.

Delegation message

What the lead agent writes when it hands off a task. For a new subagent, it’s often all the subagent knows about the job.

Single-threaded agent

One agent that does every step itself, in one continuous context, so each step can see every earlier one.

The idea

In lesson 2 you saw one agent work in a loop. In lesson 3 you gave it tools. The natural next thought is a team: if one agent is good, surely five agents, each with its own job, are better? That’s how a lot of multi-agent designs get proposed.

Sometimes they are better. Often they aren’t. This lesson shows what happens when one agent hands work to another, where the gains come from, and what they cost, so you can look at a proposed design and ask the questions that decide it. The running example is still the made-up furniture store.

The lesson, in seven parts

1. 1What a subagent is.

   Think about asking a colleague to research something. They read twenty pages and come back with a one-page summary. You don’t get their browser history. You get the answer, and your desk stays clear.

   A subagent works the same way. Anthropic’s documentation for its coding assistant, Claude Code, says each subagent “runs in its own context window with a custom system prompt, specific tool access, and independent permissions.” It does the work in its own context and returns only the summary. In Anthropic’s writing, the agent that hands out the work is called the orchestrator, or the lead agent.

   So a subagent has four parts:

   • A task, handed to it by another agent.
   • Its own context window, separate from the lead agent’s (everything a model can see while it writes, from lesson 1).
   • Its own instructions and tools, often narrower than the lead agent’s.
   • A result it hands back, usually much shorter than the work behind it.

   Notice what a subagent isn’t. It isn’t a smarter model, and it isn’t a person. It’s often the same kind of model with a narrower job and a clean desk. And it usually doesn’t see the conversation that came before: the same documentation says the main agent writes a delegation message that summarizes the task, and the subagent works from that. (Claude Code also offers a “fork”, a subagent that starts with a copy of the whole conversation. It trades a clean desk for full context.)

2. 2The orchestrator-workers pattern.

   In their December 2024 guide, Anthropic engineers Erik Schluntz and Barry Zhang describe a workflow they call orchestrator-workers: “a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.” The key word is dynamically. The subtasks aren’t fixed in advance; the orchestrator decides them based on the request in front of it.

   Anthropic’s Research feature, described in a June 2025 engineering post, uses this pattern. A lead agent plans, then starts subagents that search different parts of the question at the same time. They hand their findings back, and the lead agent combines them and decides whether more research is needed.

   Here’s the room makeover request, split that way:

   Agent	Its task	Its tools	What it hands back
   Lead agent	Understand the request, split it, combine the results	Starts subagents	One answer to the shopper
   Sofa finder	Find three sofas that match the shopper’s taste	Catalog search	Three sofas, with links
   Fit checker	Check each sofa against the shopper’s doorway	Doorway-size check	Fits, or doesn’t, for each sofa
   Delivery planner	Find the earliest delivery for each sofa that fits	Delivery date check	A date for each sofa

   Made-up example. The store, its agents, and its tools are invented for this lesson.

   Look at the last three rows again. The fit checker can’t start until the sofa finder has picked sofas. The delivery planner needs to know which ones fit. This split looks like a team working side by side, but most of it is a queue. Keep that in mind; it matters in part 6.

3. 3Why teams split the work.

   There are three real reasons to hand work to subagents. Each one answers a real limit of a single agent.

   • Separate context. A subagent can read fifty product pages, and only its short answer lands in the lead agent’s context window. Anthropic’s Research post calls this compression. Lesson 1 showed why it helps: a crowded context window gets less accurate.
   • Parallel work. Independent parts can run at the same time. Anthropic reports that having the lead agent start 3 to 5 subagents in parallel, and having subagents use 3 or more tools in parallel, cut research time “by up to 90% for complex queries.”
   • Focused instructions and tools. Each subagent gets its own prompt and tools. A fit checker that has only the doorway-size check can’t place an order by mistake. Lesson 6, on guardrails, returns to this.

   The same post reports that, on Anthropic’s internal research eval, a system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents “outperformed single-agent Claude Opus 4 by 90.2%.” Read the conditions before you repeat that number. It’s an internal test of research tasks, and Anthropic says these systems excel especially at breadth-first questions that follow many independent directions at once. It also says why: “Multi-agent systems work mainly because they help spend enough tokens to solve the problem.” In its analysis of a browsing test, token usage by itself explained 80% of the variance in performance.

4. 4What splitting costs: tokens and coordination.

   That last point is also the first cost. In the same post, Anthropic writes: “In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” Its conclusion is a product decision, not an engineering one: multi-agent systems need tasks where the value is high enough to pay for the extra performance.

   The second cost is coordination. Anthropic describes early versions spawning 50 subagents for simple queries, and subagents repeating each other’s searches because their instructions were vague. Its fix is worth copying into any design review: each subagent needs “an objective, an output format, guidance on the tools and sources to use, and clear task boundaries.” It also wrote effort rules into the lead agent’s prompt, so simple fact-finding gets just one agent, while complex research might use more than 10 subagents.

   • Harder debugging. Anthropic notes that agents aren’t deterministic between runs, even with identical prompts, and that small changes to the lead agent can unpredictably change how subagents behave. It added full production tracing to see why agents failed. Lesson 7 covers how.
   • More waiting. At the time of the post, Anthropic’s lead agents waited for each set of subagents to finish, so the whole system could be blocked by one slow subagent. Claude Code’s documentation adds that a subagent that starts fresh may need time to gather context.

5. 5Lost context: each agent right, the answer wrong.

   The cost that surprises teams most doesn’t show up in a diagram. Each subagent knows only what it was told.

   Walden Yan of Cognition, which builds an AI coding agent, makes this case in a June 2025 post titled “Don’t Build Multi-Agents.” His example: split “build a Flappy Bird clone” into a background task and a bird task. One subagent misreads its part and builds a background in the style of a different game. The other builds a bird that doesn’t look like a game asset and moves nothing like the one in Flappy Bird. The lead agent is left combining two misunderstandings.

   He draws two principles from it. First: “Share context, and share full agent traces, not just individual messages.” Second: “Actions carry implicit decisions, and conflicting decisions carry bad results.” Even when each subagent gets the earlier context, two subagents that can’t see each other’s work can make choices that don’t fit together.

   At the made-up store, it looks like this. Early in the chat, the shopper mentions two flights of stairs. The lead agent asks the fit checker one question: “Will the Harbor fit a 30-inch door?” The fit checker answers correctly. Nobody checks the stairs. Every agent did its job, and the sofa may still not reach the living room.

6. 6When one agent is better, and how to judge a split.

   On this point, the sources agree more than their titles suggest. Anthropic’s Research post says tasks where all agents need the same context, or with many dependencies between agents, aren’t a good fit for multi-agent systems today; most coding tasks, for example, have fewer truly parallel parts than research. Yan’s simplest answer is a single-threaded agent, and he writes that “the simple architecture will get you very far.” Schluntz and Zhang recommend finding the simplest solution possible, and only increasing complexity when needed.

   Claude Code’s documentation gives a practical version: keep work in the main conversation when it needs frequent back-and-forth, when several phases share a lot of context, or when speed matters. Use subagents when a task produces lots of output you won’t need again, or when the work is self-contained and can return a summary.

   Now go back to the room makeover. The parts depend on each other. The shopper will go back and forth (“What about in green?”). And everything hangs on details from the conversation, like the stairs. That points to one agent with three tools. Here’s how a team might check that, with made-up results:

   Same 50 room makeover requests	One agent, three tools	Lead agent and three subagents
   Answers fully correct	44	43
   Missed a detail the shopper gave earlier	2	6
   Average wait	14 seconds	22 seconds
   Tokens per request	Baseline	About 3 times the baseline

   Made-up numbers, for illustration only. Run the comparison on your own requests; lesson 5 shows how to build the test set.

   The template

   We’d split [job] into [subagents] because [the parts are independent / there’s too much to read / each needs its own tools]. We’ll keep the split only if, on [test set], it beats one agent with the same tools, at no more than [token and wait budget].

   Filled in, for the made-up furniture store

   We’d split “style my room” into four category finders because each reads dozens of product pages and none needs the others’ work. We’ll keep it only if, on 50 real styling requests, it beats one agent at matching the shopper’s style, at no more than three times the tokens. (Made-up example.)

   Write that sentence before anyone builds the split. It turns an argument into a test.

7. 7Questions to ask your engineers.

   You don’t need to design the agents. You need to make sure the design was chosen for a reason, and tested against the simpler option. Here’s a starting set:

   Ask

   • What does each agent know when it starts, and what does it hand back? Which parts wait for another?
   • Did we compare this with one agent that has the same tools, on the same test set?
   • How many tokens does one request use, split versus single, and what caps the number of subagents?
   • When an answer is wrong, can we trace which agent made the mistake?
   • What can each subagent’s tools do? Can any of them change an order or charge a card?
   • If one subagent fails or runs slow, what does the shopper see?

   Avoid

   • “More agents means a smarter system.” (Mostly it means more tokens; check whether they buy anything.)
   • “Let’s give each team its own agent.” (Split by what the task needs, not by your org chart.)
   • “Each agent got its part right, so the system works.” (Check the combined answer, not just the parts.)
   • “A big lab uses multi-agent, so we should too.” (Its task was breadth-first research. Is yours?)

   If the answers are vague, that’s your signal. A split nobody compared with one agent is a guess, and an expensive one.

With AI: AI can help you review these designs. Paste in a proposed split and ask an assistant to list the dependencies between the parts and what each agent would need from the conversation, then check its list against yours. Some AI coding assistants let you define subagents yourself (Anthropic’s Claude Code documentation, linked below, shows how), a quick way to watch a handoff happen.

MULTI-AGENT DESIGN REVIEW

The job (in the customer's words):

Proposed agents:
  Agent:          Task:          Tools:          Hands back:
  Agent:          Task:          Tools:          Hands back:
  Agent:          Task:          Tools:          Hands back:

Which parts wait for another? Which can run at once?

What each agent must know from the conversation, and how it gets it:

Tools that change something real (orders, payments):

Why split? [ ] independent parts  [ ] too much to read  [ ] separate tools or permissions

The simpler option we'll compare against (one agent, same tools):

Test set and quality measure:

Tokens and wait per request, split vs. single:

How we'll trace a wrong answer to the agent that caused it:

Decision, and what would change it:

Ask AI about this lesson

All lessons