Subagents and Context Isolation

Language models work within a limited context window, and quality often drops as that window fills with search results, file contents and old tool outputs, even before the hard limit is reached. Subagents deal with this by splitting the work. The main agent, sometimes called the orchestrator or lead, writes a task description and starts a subagent with a clean context, often with a narrower set of tools. The subagent explores, calls tools and reasons, then sends back a summary. Only that summary enters the main agent's context. The pattern appears in real products. Claude Code, for example, lets users define subagents with their own instructions and tool permissions, and several coding and research agents send exploration work out to parallel workers. Anthropic has written about a multi-agent research system in which a lead agent runs subagents in parallel. It reported gains on broad research questions and much higher token use than a single agent. The tradeoffs are real. Cost goes up because each subagent reloads instructions and repeats some exploration. Coordination gets harder: parallel subagents cannot see each other's work, so they may duplicate effort or make incompatible choices. That is a particular problem when tasks are tightly linked, as in writing different parts of one piece of code. Information is lost because a summary drops details the main agent might have needed, and the subagent knows only what its task description told it. One misconception is that more agents always means better results. Some practitioners argue that for tightly linked work, a single agent with well-managed context is more reliable. Subagents work best for tasks that are independent, heavy on reading and easy to summarize: searching, surveying, checking and gathering.