Many agents: orchestrator & subagents

What this lesson shows

An orchestrator delegates sub-tasks to subagents, each with its own clean context.

The question it opens with

One agent's context fills up on a big job. What if you split it across several?

The walkthrough, in the lesson's own words

• Drag supplier contracts into one context window. Push past the 100% line.
• Predict: one agent's context fills up on a big job, what if you split it?
• One lead agent hands out the contracts to helpers, each helper reads its share in a CLEAN context.
• Split the work. More subagents = lighter contexts, but more overhead.
• Fan out for wide search, but reach for one focused agent when you can.
• Keep adding contracts until the bar spills past the 100% line.
• Six full contracts can't fit one window, old notes spill out and the comparison drifts.
• The context overflows on 6 contracts. What's the fix?
• Split it: give each agent a chunk with its own fresh context, then merge, no window holds everything.
• The lead keeps the goal, not the pages: each helper reads its 2 contracts clean and reports back a short summary. The lead is called the orchestrator; the helpers, subagents.
• 1 subagent = the original single overflowing agent.
• Context fills, time units, and costs here are illustrative, not measured from a real run.
• Claude Code does exactly this when it spawns subagents; research modes fan out across websites the same way.
• Every subagent is another full context to pay for, plus the coordination to split and merge. More agents can also fragment the work, each sees only its slice, so the synthesis can miss connections. For simple or sequential jobs, one focused agent is cheaper, simpler, and often sharper. Fan out only when the work is genuinely wide and parallel.
• As agents multiply, they increasingly call not just tools but other agents, across teams and even companies. Open protocols standardize that plumbing: MCP for connecting an agent to tools and data, and agent-to-agent (A2A) style protocols for one agent to delegate to another. The upside is composability; the risk is that errors and prompt injection compound across hops, and every boundary between agents is a new trust boundary you have to scope and verify, just like a tool.
• A coding agent has to audit 40 files for one security bug, but stuffing all 40 into a single context makes it lose track. How would a multi-agent setup handle this?
• An orchestrator spawns several subagents, each with its own clean context auditing a few files in parallel, then reports a short summary back to merge. Fan out like this only when the work is genuinely wide; for a quick sequential task, one focused agent is cheaper and sharper.
• 6 full contracts don't fit in one window, the oldest context spills out.
• Still room in the window, keep adding contracts.
• Each subagent holds only its slice, room to spare.
• Lanes run in parallel; the short orchestrator bar is the merge.

Key takeaway

You can split a big goal across subagents, and know when one focused agent is the better call.

What you can do after this lesson

You can explain orchestrator–subagent patterns, parallel fan-out, and when multi-agent helps vs. backfires.

Where it leads: Across all these sessions, how does an agent remember anything?

This is the written summary. The lesson itself is interactive: you predict, drag and operate the mechanism above, and the reveal answers you.