Lesson 4 of 6 in Agentic Architecture & Orchestration

1.4 · Multi-Agent Systems & Subagents

Subagents are the mechanism that lets one Claude instance delegate focused work to another Claude instance. This lets big tasks compose out of small ones without one context window collapsing under the weight of every intermediate detail. The mechanics are simple, but the consequences — especially around context isolation and explicit context passing — are the single most tested area of Domain 1.

1.4.1 Why subagents exist

A subagent is a Claude call spawned from another Claude call. It runs in its OWN context window with its OWN tools, does focused work, and returns only a clean summary to the caller. This lets the caller stay focused on coordination while the details of the subtask stay contained.

Analogy — A subagent is like handing a task to a specialist consultant. You brief them, they go away and do their work, they come back with a summary. You didn't sit in on their research; you don't see every source they read. What you see is the deliverable. That's it.

1.4.2 Context isolation is the whole point

The coordinator NEVER sees the subagent's messages, tool calls, or intermediate reasoning. Only the summary flows back. This is deliberate: the coordinator's context stays lean and its attention stays on the plan.

This has a direct implication that trips up almost every candidate: subagent context is FRESH. It does not inherit the coordinator's conversation history. Everything the subagent needs to know must be passed in the subagent's own prompt.

Key point — Context isolation cuts BOTH ways. It protects the coordinator from subagent detail, AND it means the subagent starts with a blank slate. Both directions matter for the exam.

1.4.3 Subagents don't inherit context — pass everything explicitly

This is the single most misunderstood concept in Domain 1. Subagents get NOTHING from the coordinator's conversation history. Every fact, constraint, order ID, currency, policy reference, or piece of context the subagent needs must appear in its OWN prompt, explicitly.

If the user said 'in USD' three turns ago in the coordinator conversation, and you dispatch a subagent with just 'calculate refund', the subagent has no way to know the currency. It will guess, and its guess will often be wrong.

Exam trap — When the exam describes a subagent 'not knowing' something the coordinator knew, the answer is ALWAYS 'pass it in the subagent's prompt.' Never 'give the coordinator more context', 'increase the context window', or 'let the subagent read the coordinator's history.' Subagents cannot read the coordinator's history.

Explicit context passing

# ❌ Wrong: assumes subagent knows the currency
coordinator_conversation:
  user: "refund for order A-4482, USD"
  assistant: (dispatches subagent)
     Task(agent="refund_calc",
          input="calculate the refund amount")
# Subagent doesn't know: currency, order ID, dates, policy

# ✅ Right: explicit context in the subagent prompt
assistant: (dispatches subagent)
     Task(agent="refund_calc",
          input="""Calculate the refund.
Order ID: A-4482
Currency: USD
Original amount: $1,247.83
Order date: 2026-01-15
Refund policy: full refund within 30 days of purchase""")

1.4.4 When to delegate (and when not to)

Delegate when the subtask is INDEPENDENT and its result can be SUMMARIZED briefly. 'Analyse this one file and report the top three issues' delegates well: independent input, summary output.

Do NOT delegate when the caller needs the raw intermediate output to make its next decision. 'Show me every function that calls X' does not delegate well — the coordinator needs the actual list, not a summary of it.

1.4.5 Tool restriction is a feature, not a limitation

Each subagent should get the MINIMUM tool set it needs for its role. A code-review subagent doesn't need shell access. A research subagent doesn't need write tools. The rule of thumb is 4–5 tools per subagent; if a subagent has 18, split it into multiple subagents with narrower scopes.

Key point — Narrow tool scopes reduce misselection, tighten the security surface, and simplify debugging. Giving a subagent 'all the tools just in case' is an anti-pattern.

1.4.6 Hub-and-spoke vs peer coordination

Most production multi-agent systems are hub-and-spoke: one orchestrator, many workers, no worker-to-worker communication. All coordination routes through the hub. Peer coordination — workers talking directly to each other — is theoretically possible but multiplies failure modes: race conditions, deadlocks, ambiguous responsibility, harder debugging. It is rarely worth the complexity for the marginal gain.

Exam trap — The exam may present 'let the subagents talk to each other directly to speed things up' as an answer. This is an anti-pattern. All coordination routes through the coordinator in hub-and-spoke systems.

1.4.7 Diagnosing coordinator vs subagent failures

When a multi-agent system produces a bad result, trace it to the right layer. If the coordinator's decomposition missed a topic entirely (the research report has no section on regulations), that's a COORDINATOR failure — fix the coordinator's prompt or planning. If the coordinator asked the right questions but the subagent's answer was shallow or wrong, that's a SUBAGENT failure — fix the subagent's prompt or tools.

Key point — The exam rewards tracing failures to root cause. 'A research report is missing entire topic areas' is a coordinator failure, not a subagent failure — even though the subagents are the ones who wrote the sections.

Takeaways

Subagents run in isolated context windows and return only summaries
Subagents do NOT inherit the coordinator's history — pass all needed context explicitly
Delegate independent subtasks; don't delegate when the caller needs raw output
Restrict each subagent to 4–5 role-relevant tools
Hub-and-spoke is the standard; avoid peer coordination
Failures trace to whichever layer made the wrong decision — coordinator or subagent

Exam traps

Assuming subagents inherit the coordinator's conversation history

They do not. Subagents start with fresh context. Every fact they need must be in their prompt.

Giving all subagents access to all available tools

Increases misselection risk and blurs role boundaries. Restrict each subagent to the 4–5 tools its role needs.

Blaming the subagent when the coordinator made a bad decomposition

If the research report is missing entire topic areas, the coordinator failed to ask about them — the subagents can't answer questions they weren't asked.

Letting workers communicate directly with each other

Hub-and-spoke routes all coordination through the coordinator. Peer coordination introduces race conditions, deadlocks, and debugging pain for negligible gain.

Practice scenario

A coordinator agent dispatches three research subagents. The user's original request specified 'focus on EU regulations from 2024 onwards.' The subagents produce reports covering global regulations from 2020 onwards. What is the root cause?

← Previous Next →