AI Subagents Explained — Parallel AI Work

An AI subagent is a specialized agent spawned by a main "orchestrator" agent to handle one isolated task — with its own context window (the working memory the model reasons inside), its own system prompt, and its own tool set — that returns a single, summarized result. Subagents became a defining pattern of agentic AI in 2025 and 2026, used by Claude Code, Anthropic's own multi-agent research system, Devin, Microsoft's AutoGen and its successor Agent Framework, CrewAI, and OpenAI's Agents SDK. They exist because a single, linear conversation hits real limits once a task grows past a certain size — and understanding how they work explains a lot about why agentic AI tools suddenly got so much more capable in the last year.

Why subagents exist

Three pressures push agentic systems toward delegating work to child agents rather than doing everything in one long conversation.

The first is context window pollution. A context window is the fixed amount of text — measured in tokens, roughly word-fragments — a model can hold in its working memory at once. Long, exploratory tasks fill that window with search results, tool errors, and dead ends. Even models with windows in the hundreds of thousands of tokens degrade in reasoning quality as the window fills with irrelevant material, a problem researchers call "context rot."

The second is parallelism for speed. If three independent sub-tasks can run at the same time instead of one after another, the whole job finishes in roughly a third of the wall-clock time, even though total compute spent goes up. This only works when the sub-tasks genuinely don't depend on each other's results.

The third is specialization for quality. A subagent with a narrow, focused system prompt and only the tools it needs tends to outperform a generalist agent trying to do the same job inline, buried among a dozen other concerns. Anthropic's own research team found this held up empirically: their internal multi-agent research system, where a lead agent spins up three to five subagents that search in parallel, outperformed a single-agent Claude Opus setup by 90.2% on internal research evaluations.

Anthropic's engineering team reports its orchestrator-worker research system costs roughly 15 times the tokens of an ordinary single-turn chat to run — because every subagent is a full, separate LLM session with its own reasoning trace, not a lightweight function call.

The fix, in every framework that has converged on this pattern, is to push exploratory or narrow work into ephemeral child agents that report back a clean, distilled summary, leaving the parent agent's context uncluttered and its reasoning sharp.

How subagents work technically

The mechanism is more mundane than it sounds — it is closer to function calling than to anything resembling a hive mind.

1. The main agent (sometimes called the orchestrator or lead agent) decides a task is delegable and calls a tool, typically named something like Agent, Task, dispatch_agent, or, in OpenAI's terminology, a handoff.
2. The harness — the software layer running the agent loop — spawns a new, independent conversation for the subagent: a fresh system prompt, a scoped subset of the available tools, and the parent's task description as the subagent's first instruction.
3. The subagent runs its own agentic loop: it reads, calls tools, reasons, sometimes iterates for dozens of steps, until it produces a final answer.
4. That answer returns to the parent as a single tool result. The parent never sees the subagent's intermediate reasoning, dead ends, or false starts, only the conclusion.

Think of it like hiring a research assistant to spend an afternoon in the archives. You don't want a transcript of every book they opened and put back down; you want the two paragraphs of actual findings, with citations, so you can keep working. The subagent pattern automates that filtering step.

A second useful analogy: it's the difference between a manager who reads every email their team sends to each other, versus a manager who just gets a status report at the end of the day. The first approach doesn't scale past a small team. The second does, at the cost of losing visibility into exactly how the work got done.

How is a subagent different from a simple tool call?

A tool call (like a web search or a calculator) returns raw, structured data with no reasoning attached. A subagent is itself a full LLM session that reasons, plans, and calls its own tools before returning a synthesized answer. The subagent is "smart" in a way a plain tool call is not.

Does the parent agent see what the subagent did step by step?

No, not by default. The parent only receives the subagent's final summarized output. Some frameworks, including Claude Code, let a subagent stream intermediate progress to the user for transparency, but the parent model itself reasons only over the final result, not the full trace.

Common subagent patterns

Subagent type	Job	Typical tools
Search / research	Gather information from the web or a codebase	Web search, file read, grep
Code review	Review a diff for bugs, style, and security issues	File read, git diff
Test runner	Run tests and triage failures	Shell exec, file read
Planning	Decompose a goal into ordered sub-tasks	None — pure reasoning
UX / copy	Write microcopy with consistent voice and tone	File read, style guide
Deployment	Run a deploy and verify service health	Shell exec, HTTP requests
Security review	Scan for vulnerabilities or exposed secrets	File read, static analysis
Documentation	Read code and produce docs from it	File read, file write

Table: The eight subagent roles that show up most often across production agentic coding and research tools in 2026.

A real Claude Code session might chain four of these in a single task: a planning subagent decomposes the goal, a research subagent gathers context, a coding subagent implements the change, and a review subagent checks the diff before it's handed back to the user.

Products and frameworks that use subagents

The subagent pattern is no longer a research curiosity. It sits at the core of several widely used products, though each implements it a little differently. For a terminal-based example of an AI coding assistant, see our explainer on Aider, the terminal AI coding tool.

Claude Code ships subagents as a first-class, named feature. Developers define subagents in configuration files with a scoped tool allowlist (or a denylist that's applied first, if both are set), and the lead agent can dispatch work to them. A June 2026 update, which Anthropic calls Dynamic Workflows, lets the lead agent plan and fan out anywhere from tens to hundreds of parallel subagents within a single session for large-scale tasks, paired with a separate "grader" step that sends a subagent's output back for revision if it doesn't meet a quality rubric.

Anthropic's Claude multi-agent research system (the architecture behind Claude's web research feature) is the clearest documented case study of the pattern at scale: an orchestrator-worker system where a lead agent plans, spins up three to five subagents that search in parallel with their own context windows and tool access, and then synthesizes their findings through a separate citation pass. Anthropic has published detailed engineering notes on why this beat single-agent research systems and, separately, guidance on when multi-agent systems are worth the added cost and complexity at all — their answer is, not always.

OpenAI's Agents SDK built its multi-agent model around "handoffs," where one agent transfers a conversation permanently to another specialized agent (a triage agent handing a billing question to a refund agent, for example). In April 2026, OpenAI's "Next Evolution of the Agents SDK" release added a formal subagent primitive, in beta, that differs from a handoff in one important way: control returns to the parent agent once the subagent finishes, rather than the conversation transferring away permanently. OpenAI's stated rationale is that this pattern "consistently outperforms monolithic agents on long-horizon tasks."

Microsoft's AutoGen was the original popularizer of the multi-agent conversation framework starting in 2023, but the project's status changed significantly through 2025 and 2026. Microsoft placed the original AutoGen project into maintenance mode in October 2025, and the ecosystem split three ways: AutoGen v0.7.x continues as a research-oriented maintenance line, a community-led fork called AG2 kept backward compatibility with the older GroupChat style of multi-agent orchestration, and Microsoft Agent Framework became the official production successor, merging AutoGen's orchestration ideas with Semantic Kernel's enterprise stability. Microsoft shipped Agent Framework 1.0 on April 3, 2026. Anyone evaluating a new project on Microsoft's stack in 2026 is generally pointed toward Agent Framework or the community AG2 fork rather than legacy AutoGen.

CrewAI takes a role-based approach: developers define agents with named roles, assign them tasks with an expected output, and group them into a "crew" governed by a process model (sequential or hierarchical). CrewAI added an event-driven orchestration layer called Flows on top of crews, plus support for the Model Context Protocol and the Agent-to-Agent standard for interoperability with other frameworks. The company reports adoption across a majority of Fortune 500 companies and closed a Series A round led by Insight Partners to fund an enterprise tier with SOC 2 compliance and single sign-on.

LangGraph, built by LangChain, takes a lower-level, graph-based approach: developers define agents and the edges between them explicitly as a state machine, giving fine-grained control over exactly when and how control passes between agents, at the cost of more manual wiring than role-based frameworks like CrewAI.

Devin, from Cognition, uses internal planning and execution agents to break a coding task into stages, though Cognition has published far less technical detail on its internal architecture than Anthropic or OpenAI have on theirs.

MetaGPT applies the same idea to simulate a software team: agents assigned roles like product manager, architect, and engineer collaborate on a single software project, each working from a shared specification document rather than free-form chat.

Architectures compared

Architecture	Description	Pros	Cons
Monolithic	One agent, one context window, sequential tool use	Simple, full visibility into every step	Context bloats fast; slows down on large tasks
Sequential pipeline	Agent A hands off to Agent B, which hands off to Agent C	Clear stages, easy to debug in isolation	No parallelism; brittle at each hand-off point
Subagent (orchestrator-worker)	Lead agent dispatches children and aggregates results	Parallel, specialized, clean parent context	Information loss in summaries; higher token cost
Swarm / peer	Multiple peer agents communicate with each other freely	Maximally flexible	Hard to debug; costly; prone to coordination loops

Table: The four dominant multi-agent architectures in production agentic systems, ranked roughly by how widely each is used as of mid-2026.

The subagent pattern has become the default across the industry because it captures most of the benefit of a full multi-agent system — parallelism, specialization — while preserving a single source of truth: the parent's plan. A swarm architecture, where agents talk directly to each other with no central coordinator, is more flexible in theory but is notoriously difficult to debug when two agents disagree or loop on the same exchange. Anthropic's own engineering guidance is candid about this trade-off, recommending multi-agent architectures only for tasks that genuinely parallelize — open-ended research and broad exploration — and recommending against them for tasks with tight interdependencies between steps, where a single agent working sequentially is both cheaper and more reliable.

Risks and limitations

Subagents solve real problems, but the pattern introduces new failure modes that don't exist in a single-agent system.

Information loss. The subagent's full reasoning trace is collapsed into a summary before it reaches the parent. If the parent later needs a detail that didn't make it into that summary, the only fix is spinning up another subagent to go find it again.

Cost. Each subagent is a full, independent LLM session, not a lightweight function call. Anthropic reports its orchestrator-worker research system runs at roughly 15 times the token cost of a single ordinary chat turn. A task that dispatches five parallel subagents can easily cost several times what the equivalent inline work would, even accounting for the wall-clock time saved.

Coordination failures. When two subagents' scopes overlap even slightly, they can return contradictory findings, and the parent has no built-in way to know which one is right without a further verification step.

Bad summaries. If a subagent's final report omits a critical detail — because it judged it unimportant, or because it ran out of steps before fully exploring — the parent acts on incomplete information without knowing anything was missing.

Latency from synchronization. Even when subagents genuinely run in parallel, the parent has to wait for the slowest one to finish before it can synthesize a final answer. A single subagent stuck in a long tool-call retry loop can bottleneck an entire five-way parallel dispatch.

Are subagents worse for tasks with tight interdependencies?

Yes. Subagents are built for tasks that decompose cleanly into independent chunks, like searching five unrelated topics at once. Tasks where step three depends on the exact output of step two do worse when split across agents with siloed context, because the necessary detail often gets lost in the hand-off summary.

Best practices that consistently raise reliability

The community — and Anthropic's own published engineering guidance — has converged on a small set of rules that show up across nearly every serious production deployment of the pattern.

1. Write self-contained prompts. A subagent has no memory of the parent's conversation. Any context it needs to do the job has to be included explicitly in its initial instruction, or it will guess, and guessing is where most subagent failures start.
2. Specify a single, well-defined return value. Tell the subagent exactly what to hand back: "a list of file paths with line numbers" or "PASS or FAIL with a one-sentence reason," not an open-ended "let me know what you find."
3. Keep scope narrow. Subagents reliably do worse on genuinely open-ended exploration than on targeted, bounded questions. If a task can't be phrased as a specific question, it's probably not ready to delegate.
4. Right-size tool access. A code-review subagent generally shouldn't have write access to the codebase it's reviewing; a research subagent generally shouldn't have shell execution access. Scoped tools also limit the blast radius of a subagent that goes off track.
5. Design for idempotency where possible. Subagents that can be safely re-run, without side effects piling up, make retries and error recovery dramatically simpler.
6. Read the summary, don't trust the count. A subagent reporting "found 12 issues" is not the same as verifying those 12 issues are real and worth acting on. The parent, or the human reviewing the parent's work, should read the actual content, not just the tally.
7. Use subagents sparingly. For a small task, under roughly five tool calls done inline, a single agent call is cheaper, faster, and easier to debug than spinning up a child session and later reconciling its summary.

When not to use subagents

Subagents are a tool for scale, and reaching for them by default on small tasks is a common mistake in early agentic-tool adoption. They pay off specifically when a task is big enough, and parallelizable enough, that the token and latency cost of a clean parent context outweighs the cost of spinning up and coordinating a child agent.

Avoid the pattern when the task is small, under roughly five tool calls handled inline; when a human or a downstream automated process needs the full reasoning trace for debugging or audit purposes, since subagents by design discard that trace; when the result is highly contextual and genuinely hard to summarize without losing the point of it; or when the total token budget for the task is tight, since even a modest fan-out of two or three subagents multiplies cost quickly.

For a broader view of how subagents fit into the wider landscape of autonomous AI systems, see our explainer on AI agents. For a look at the specific product that made "subagents" a household term among developers, see our piece on Claude Code.

What this means

Subagents are not a new kind of intelligence — they're an engineering pattern for managing a resource-constrained system, the same way a company org chart is a pattern for managing what a single manager can keep track of. The context window is the scarce resource, and delegation, with the loss of detail that comes with it, is the price of keeping it usable at scale. That trade-off is now explicit and quantified: Anthropic's own numbers show a roughly 90% quality gain on research tasks purchased at roughly 15 times the token cost. Expect that ratio, not the existence of the pattern itself, to be the thing frameworks keep optimizing through 2026 and beyond, as subagent orchestration moves from Claude Code and research prototypes into mainstream production software.

FAQs

Q: What is an AI subagent? A: A specialized AI agent spawned by a main agent to handle an isolated task, with its own context window, system prompt, and tools. It returns a single summarized result to the parent agent rather than exposing its full reasoning trace.

Q: Why use subagents instead of one big agent? A: To keep the main agent's context window free of clutter, to run independent sub-tasks in parallel for speed, and to specialize each agent's prompt and tools for higher quality on its narrow piece of the job. Anthropic reports a 90.2% quality improvement from this pattern on internal research evaluations.

Q: Do subagents share memory with the parent agent? A: No. Each subagent runs a fresh, independent conversation with no access to the parent's history. The parent has to pass any context the subagent needs directly in its initial instruction, and the subagent returns only its final summary, not its intermediate steps.

Q: How much more does a subagent-based system cost to run? A: Anthropic's engineering team reports its orchestrator-worker research system, which dispatches three to five parallel subagents per query, costs roughly 15 times the token usage of an ordinary single-turn chat. Cost scales with how many subagents are dispatched.

Q: Which products use subagents in 2026? A: Claude Code and Anthropic's own multi-agent research system, OpenAI's Agents SDK (which added a formal subagent primitive in April 2026), CrewAI, LangGraph, Microsoft Agent Framework and the community AG2 fork of AutoGen, and Devin from Cognition are the main production examples.

Q: What happened to Microsoft's AutoGen? A: Microsoft placed the original AutoGen project in maintenance mode in October 2025. It split into three paths: AutoGen v0.7.x as a research-oriented maintenance line, a community-led AG2 fork that kept the older GroupChat API, and Microsoft Agent Framework, the official production successor that shipped version 1.0 on April 3, 2026.

Q: Are subagents the same thing as a "handoff" in OpenAI's Agents SDK? A: No, and the distinction matters. A handoff transfers the conversation to another agent permanently. A subagent, added as a formal primitive to OpenAI's SDK in April 2026, returns control to the parent agent once it finishes its task, the same pattern Claude Code and Anthropic's research system use.

Q: What's the main downside of the subagent pattern? A: Information loss. A subagent's internal reasoning collapses into a summary before the parent sees it, so any detail that didn't make it into that summary is effectively gone. Cost is the second major downside, since it multiplies with every parallel subagent dispatched.

Q: Are subagents the same as multi-agent systems generally? A: Subagents are one specific form of multi-agent system: a hierarchical one, where a parent dispatches to children and reclaims control afterward. Broader multi-agent systems can also use peer-to-peer or "swarm" topologies where agents communicate directly with each other without a central coordinator, though those are harder to debug and less common in production.

Q: When should a task not use subagents? A: When it's small enough to finish in a handful of tool calls inline, when someone needs the full reasoning trace for debugging or audit purposes, when the result is too contextual to summarize cleanly, or when the token budget for the task is tight. Anthropic's own guidance recommends single-agent designs by default and multi-agent designs only for tasks that genuinely parallelize.

---

Read next:

• AI Agents Explained — How Autonomous AI Systems Actually Work
• What Is Claude Code? Anthropic's AI Coding Tool
• Complete AI Guide 2026