Supervisor and subagents, when to split and what each one returns

A due-diligence agent researches five areas of a company (legal, finance, customers, technology and staff) in a single conversation. It takes an hour and the report mixes up findings: it attributes to finance a risk that came from a contract. Each area is independent and produces a huge amount of text, and all of it lives in the same context. This is the textbook case for a supervisor (orchestrator) that splits the work among subagents.

What you gain by splitting

A subagent is another Claude instance with its own prompt, its own tools and its own context window. That gives you three things:

• Context isolation: each area’s searches, reads and long outputs stay in the subagent. The supervisor receives only what matters.
• Parallelism: independent areas run at the same time, so total time gets close to that of the slowest area.
• Specialization: each subagent can have its own prompt, its minimal tools and even a different model (a Haiku to classify, a more capable model to analyze contracts).

In Claude Code and in the Agent SDK, a subagent is defined with a description (which tells the main agent when to delegate), its prompt, its tools and its model, and the main agent launches it with the Agent tool.

When to split and when not to

Signal	Decision
Independent subtasks that generate a lot of context	Supervisor with subagents
Parts that could run in parallel and today wait one after another	Supervisor with subagents
Steps that depend heavily on the previous one	A single agent, or a workflow
A small task that fits comfortably in one context	A single agent
“More agents to make it more robust”, with no concrete problem	Don’t split

Each subagent costs its own tokens and coordination adds latency. Splitting is justified when it tackles a real problem: context that fills up, findings that get mixed, or a wait that can be parallelized.

What each subagent receives

The subagent doesn’t see the supervisor’s conversation. Everything it needs has to go in the delegation:

• the concrete goal and scope (“only active customer contracts”);
• the data already known that it doesn’t need to look up again;
• which tools to use and what not to do;
• the exact format of what it must return.

A vague delegation (“research the legal side”) produces duplicated work across subagents or gaps nobody covers.

What each subagent returns

What comes back must be a condensed result, not the transcript of the work:

• findings in a fixed structure (for example, JSON with risk, severity, evidence and source);
• the source of each claim, so the supervisor can verify it and doesn’t mix up origins;
• what it couldn’t find out, stated explicitly, instead of silence.

The supervisor is responsible for splitting the work, collecting the results, resolving contradictions and assembling the final answer. If subagents return everything they read, the supervisor’s context fills up again and the advantage is lost.

The typical traps

• Splitting a sequential task into several agents that hand the work to one another, gaining nothing.
• Delegating with one line, as if the subagent knew what the supervisor had discussed.
• Having each subagent return its full searches instead of a summary with sources.
• Giving every subagent every tool, instead of the minimum for its part.
• Adding a “reviewer” or “planner” subagent without a problem that calls for it.

On the exam

Look for two clues: independent subtasks and a context that fills up or gets mixed. If they appear together, the answer is a supervisor that delegates each part to a subagent, in parallel, and receives condensed results with their source. If the task is small or each step depends on the previous one, rule out the options that add agents. And if the problem is that subagents repeat work or return too much, look for the option that improves the delegation or the format of what they return.