What subagents are
When you ask Claude to handle a complex multi-step task, it sometimes delegates parts of the work to separate sub-sessions called subagents. Each subagent runs with its own context window, completes a focused task, and returns its output to the main session.
You don't always see this happening. The orchestrating Claude manages it, and from your end the session looks continuous. But behind it, multiple instances may have worked in parallel — each without knowledge of what the others did.
This is what makes agentic workflows faster for complex work. It's also what makes them fail in ways that are harder to trace than single-session errors.
The model selection problem
By default, Claude spawns lighter, cheaper models — Sonnet or Haiku — for subagent tasks, regardless of the complexity of what's being delegated. For knowledge-intensive tasks like research, analysis, or synthesis, this means worse results than if the main session had handled it directly.
You can override this default. Specifying in your CLAUDE.md that subagents should use Opus changes which model handles delegated work. The difference is pronounced for anything requiring careful reasoning across many sources.
This is a configuration choice, not a technical constraint. It defaults to cheaper because cheaper is often fine. It's only a problem when you don't know it's happening.
Hallucination chains
When one subagent's output becomes the next subagent's input, errors compound. A fabricated statistic in step one becomes an assumed fact in the analysis at step two, which becomes a headline candidate at step three.
This is different from a single-session error because you can't easily trace it back. By the time the error surfaces, it's been through multiple layers of processing — each of which treated the previous layer's output as reliable input.
The mitigation: treat subagent handoffs like source handoffs. Verify outputs before passing them to the next stage. Intermediate results aren't vetted reporting — they're working material.
A multi-reporter analogy
Multi-reporter investigations work the same way. You assign different reporters to different document sets, then synthesize their findings into the published story. The synthesis is only as reliable as the verification at each handoff.
If one reporter passes along a claim they didn't verify, and it enters the synthesis without being checked, it ends up in print. The editor reviewing the synthesis doesn't know which reporter sourced that claim or whether it was confirmed.
Subagent pipelines have the same failure mode. The orchestrating Claude receives outputs and synthesizes them. It has no way to know which subagent was sloppy and which was careful. The only defense is verification at the handoff points, before outputs become inputs.
Designing for subagent use
Keep subagent tasks focused: one clear objective, defined inputs, defined output format. Narrower tasks with more subagents handling them outperforms broader tasks with fewer subagents — not just for speed, but because context pollution happens at the subagent level too. A subagent given too broad a mandate will fill in gaps with inference.
Define the output format explicitly. A subagent that returns prose when you needed structured data forces the next stage to parse ambiguity — or introduces one of its own.
When you give Claude access to your documents through MCP, you're creating the conditions for subagent use. Files get processed, results get passed around, context windows fill up and spin off. Understanding how those sub-sessions work helps you design those pipelines so errors don't disappear into the handoffs.
SOURCE: Adapted from "Subagent control" pattern, originally by The Agentic Lab, extracted and organized at github.com/jamditis/stash.
NEXT: Head to Module 4 to configure Claude Code with MCP and build your first agent pipeline.