In this guide
Agent vs Subagent
There's no technical difference between them. An agent becomes a subagent the moment another agent calls it instead of a person. Same loop, same kind of decision-making — only the caller changes. In practice, a system prompt built for a person is wrong for a subagent, and vice versa — same for tool scope.
An agent on its own
Picture the ordinary, top-level case: a person hands it a goal, it works out the steps itself, and the person reads whatever it comes back with. No fixed script tells it what to do at each step — its own judgment carries it through. That's the setup most people picture when they hear the word "agent."
What a subagent is
A subagent is the exact same kind of system, invoked by another agent instead of a person. It runs in its own isolated context and takes on one bounded slice of a larger task. It hands its result back to whatever called it — not to a human waiting on the other end.
Agent vs subagent, side by side
| Agent | Subagent | |
|---|---|---|
| Who calls it | A person | Another agent |
| Who reads the result | The person directly | The calling agent, not a person |
| System prompt needs | General enough for open-ended human requests | Narrow, scoped to one specific kind of task |
| Tool access | Broad enough to cover whatever a person might ask | Only what the bounded task requires |
| Model choice | Usually the strongest one available — it has to handle anything | Often a smaller, cheaper, faster one, since the task is narrow |
| How many run at once | One, in conversation with a person | Several in parallel, when the work splits cleanly |
Why the distinction still matters for design
Because the two roles want different instructions. An agent built for people needs to handle vague, open-ended requests and explain itself in a way a human can follow. That's also why its tool access is usually kept broad enough to cover whatever a person might ask next. A subagent doesn't need any of that. It needs a narrow, precise brief and a tightly scoped set of tools, since the thing reading its output is another agent, not someone who benefits from a conversational explanation.
Two practical consequences follow from that. Because a subagent's task is narrow, it often doesn't need your best model — a smaller, cheaper, faster one will handle one bounded job as well as a large one, and the cost difference matters once you're making a lot of these calls. And because each subagent works in its own isolated context, several can run at the same time when a task splits into independent pieces, which a single agent talking to a person cannot do. The subagent page covers how that isolation works.
The same underlying agent can genuinely serve both roles at different times. A code-review agent a developer talks to directly on Monday can be the exact same system a larger pipeline calls as a subagent on Tuesday. What changes isn't the agent's core design, but which system prompt and tool scope you hand it for that particular call. Design for both roles from the start, rather than assuming a system built for one will work fine in the other.