A subagent isn't free parallelism, nor a way to make Claude Code "think better" — it's a specific tool for isolating context when an intermediate task would generate too much noise in the main conversation.
A subagent in Claude Code is a separate instance of the agent, with its own system prompt, its own restricted tool set, and — crucially — its own context isolated from the main conversation. When the main agent delegates a task to a subagent, it executes its work independently (reading files, running commands, reasoning about the problem) and on completion returns only a summary to the main agent, not the full detail of every intermediate step it took.
This is fundamentally different from simply "asking Claude to do several things in the same conversation" — the difference is in what context persists. Without subagents, every file read, every command run, and every debugging iteration stays in the main conversation's history, consuming context space and, in long conversations, increasing the risk that relevant information gets diluted among operational noise.
The most common conceptual mistake is thinking of subagents as a way to "speed up" work through parallelism. While it's true multiple subagents can run on independent tasks, the main reason to use them isn't speed — it's preventing the detail of a secondary task from polluting the main task's context.
A concrete example: if you ask Claude Code to "implement the payment endpoint and check for security vulnerabilities in the authentication module," the security review might involve reading a dozen files, reasoning about several attack vectors, and dismissing most of them as not applicable. That whole exploration process adds no value if it stays in the main context — what matters is the final finding. Delegating that review to a subagent means the main agent only receives "a SQL injection vulnerability was found on line 84 of auth.py," without the detail of the fifteen lines that got ruled out along the way.
Delegating has a cost: every subagent starts without the accumulated context of the main conversation, so if the task depends heavily on decisions or discoveries already made in the current session, you have to communicate them explicitly in the delegation instruction — the subagent doesn't infer them on its own. For short, sequential tasks where the next step depends directly on the immediately prior result (for example, "read this file, now edit it, now run the corresponding test"), delegating adds coordination overhead with no real benefit: it's simpler and faster for the main agent to do it directly.
The practical heuristic: use subagents for parallel or mutually independent lines of work (reviewing multiple unrelated modules, running different test suites), and direct work for sequential operations on a single file or a strictly linear flow.
A subagent can — and in most cases should — have a more restricted tool set than the main agent. A "code review" subagent probably only needs Read and Grep, with no access to Bash or Edit — it shouldn't be able to modify the code it's reviewing. This restriction isn't just good security practice; it also reduces the subagent's decision space, making it more predictable and focused on the specific task delegated to it.
Every invoked subagent involves its own call to the model with its own token consumption — delegating isn't free. For trivial tasks, the overhead of starting a subagent (defining the task's context, waiting for its full execution, processing the returned summary) can outweigh the context-isolation benefit being sought. The practical rule is to reserve delegation for tasks where the intermediate work would be genuinely voluminous, or where the isolation of responsibility (a review subagent not being able to edit code, for example) provides a security guarantee that's worth it on its own.
When introducing subagents into a team workflow, it's best to start with two or three well-defined, high-value roles — for example, a security-review subagent, a test-execution-and-diagnosis subagent, and an external-documentation-research subagent — instead of fragmenting every possible task into its own subagent. Measuring how much context gets saved and how much total time the complete task takes (delegation included) versus doing everything in the main conversation is the most reliable way to decide whether it's worth expanding the pattern to more roles on the team.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel