Claude subagents are separate, specialized instances of Claude that a main conversation can spin up to handle one piece of work, then report back.
Each one gets its own context window, its own instructions, and its own tool access. It does not see the rest of your conversation, and your main conversation does not see its internal steps, only the result it hands back.
That sounds like a small detail. It changes how I actually run my own AI operating system.
What are Claude subagents
A subagent is a focused Claude instance built for one kind of task. Claude Code ships with a few built in, including Explore, Plan, and a general-purpose subagent, and you can define custom ones for tasks you repeat often.
The main conversation delegates a task to a subagent, the subagent works through it independently, and only the final result comes back into the main thread.
Nothing in between gets added to your main context. That is the entire point.
According to Anthropic’s own documentation on custom subagents, each one runs with its own system prompt, its own allowed tools, and its own permissions, scoped specifically to what that task needs.
How Claude subagents actually work
Every subagent runs in its own context window, separate from the conversation that called it. It can have a custom system prompt, a specific set of tools it is allowed to use, and permissions scoped to just that task.
That isolation is what makes them useful. A side task that would otherwise flood your main conversation with search results, log output, or file contents you will never look at again instead happens somewhere else entirely.
You get the answer. You do not get the mess it took to find it.
This connects directly to how token cost actually works. I wrote about that in AI token cost, because every extra token sitting in your context gets reprocessed on every future turn. A subagent that reads ten files and returns one paragraph keeps those ten files out of your main context for good.
Multiple subagents can also run in parallel on independent pieces of the same problem. Each one works blind to what the others are doing, which matters more than it sounds like it should.
How to use Claude subagents
In Claude Code, you invoke a subagent by describing the task and letting Claude decide when delegation makes sense, or by naming a specific subagent type directly when you know exactly what you want.
The built-in Explore subagent is meant for open-ended searching, locating a file, a function, a pattern, across a codebase you do not know well yet. Plan is meant for architecture decisions before code gets written. General-purpose covers everything else.
Custom subagents get defined with their own system prompt and tool restrictions, so you can build one that only ever reads files and never writes them, or one scoped to a single narrow job you run often.
You can also chain the pattern. A main conversation spins up one subagent to gather information, then spins up a second one to act on what the first one found, without either one ever seeing the other’s full internal process.
Claude subagent examples from my own AIOS
I do not use subagents as a novelty. They are the actual mechanism behind the review process I run before anything real ships on softDev23.
I call that process Loop Engineering. Before a launch decision or a real structural change goes live, several separate subagent instances review the same work independently, each one blind to what the others conclude.
Each subagent is told directly to find the flaws, not approve the work. A separate instance then reconciles every verdict into one final call, with a scoreboard instead of a flat yes or no.
That structure is also the direct answer to AI sycophancy. A single Claude instance reviewing its own output tends to agree with the reasoning that produced it, because it is the same reasoning. Separate subagent instances with no memory of how the work got made do not have that bias.
A more mundane example from the same week. Before drafting this exact post, I had a subagent-style check run across the live site to confirm the keyword was not already covered by an existing post.
That check pulled and compared several posts, checked slugs, statuses, and even a couple of scheduled-but-unpublished drafts I did not know existed yet. None of that needed to sit in my main working context afterward. Only the final yes or no answer did.
It caught something worth mentioning. Two other keywords I had planned to write about that same day turned out to already be live, one of them published just two days earlier.
Without a dedicated check pulling that information into an isolated pass, I would have duplicated content that already existed.
Why isolate context instead of one long conversation
You could, in theory, just keep everything in one conversation and ask Claude to be thorough. In practice that gets expensive and messy fast.
Every additional token sitting in a long conversation gets reprocessed on every subsequent turn. A subagent that goes off, reads a pile of files, and returns a two-sentence summary keeps all of that reading out of your main context permanently, not just for the current turn.
There is also a quality reason, not just a cost one. A subagent with a narrow system prompt and limited tools stays focused on exactly one job. A single sprawling conversation drifts, and drift is where quality slips.
Isolation also makes independent judgment possible in the first place. If a review subagent could see the reasoning behind the work it is reviewing, it would anchor on that reasoning instead of forming its own view.
There is a real tradeoff worth naming honestly. Spinning up a subagent has its own setup cost and its own token usage, so it is not free. The savings show up over the life of the conversation, not on the very first exchange, which is why it matters most for anything long-running or repeated.
Claude subagent best practices
Give a subagent one clear job, not a vague area of responsibility. Narrow scope is what makes the isolation worth it.
Restrict tool access to only what that specific task needs. A subagent that only reads files should not also have write access, even if it is technically available.
Do not use a subagent for something short enough to just do directly in the main conversation. The setup cost is not worth it for a one-line answer.
For anything genuinely high stakes, run more than one subagent independently on the same question rather than one subagent you trust blindly. That is the actual mechanism behind Loop Engineering.
Write the subagent’s instructions as if it will never see any other context, because it will not. Vague instructions that rely on shared context from the main conversation are the most common way custom subagents fail.
Subagents vs skills and MCP
These get confused constantly, including by me at first. A subagent is a separate instance with its own context. A skill is a set of instructions and reference material a single instance reads when relevant. MCP is a connection to an outside tool or data source.
I broke down the full comparison, including where subagents fit against skills and agents generally, in Claude skills vs agents. The short version: skills shape how one Claude behaves, subagents are separate Claudes doing separate work, and MCP is what any of them can reach out and use.
A subagent can use a skill while it works. A subagent can also call an MCP tool. They stack, they are not competing options.
Claude subagents, quick answers
What is the difference between a subagent and a skill? A subagent is a separate Claude instance with its own context window. A skill is reference material and instructions a single instance loads when a task matches it.
Do subagents cost more? They add tokens for their own work, but they usually cost less overall by keeping large intermediate output, file contents, search results, logs, out of your main context permanently.
Can I create a custom subagent? Yes. Claude Code lets you define a custom subagent with its own system prompt, allowed tools, and scope.
Can multiple subagents run at once? Yes, independent subagents can run in parallel on separate pieces of the same task, which is exactly how a multi-reviewer process like Loop Engineering works.
When should I use a subagent instead of just asking directly? When the task would flood your main conversation with output you will not need to reference again, a big search, a multi-file read, a long log.
Where this actually runs
This is not a feature I read about and then wrote up. Subagents are the actual engine behind the review process that catches real problems in my own work before they ship.
If you want to see the full system this runs inside, join the AIOS waitlist.
