"Claude code subagents" gets searched by people who have already noticed the shape of the problem: one agent working a whole task inside a single context window runs out of room, or drifts, or tries to do research and write code in the same breath. Subagents are Claude Code's answer, a way to hand off a piece of the task to a separate session that comes back with only a result, not its whole train of thought.
What a subagent is, and why teams add them
A subagent in Claude Code is a separate agent invocation, defined once (a name, a description of when to use it, an allowed set of tools, optionally its own model) and then delegated to either automatically, when the main session's request matches the subagent's description, or explicitly, when a person or a script asks for it by name. It runs in its own context window: no conversation history from the main session, no accumulated back-and-forth, just the task it was handed and whatever files or tools it's allowed to touch. When it finishes, the main session gets a summary back, not a full transcript.
Teams reach for this for a plain reason: a single long session degrades. Context fills up with exploration that turned out to be a dead end, the model has to hold an ever-growing pile of prior steps in mind, and a task that mixes broad codebase search with focused editing does neither well in the same window. Splitting the search into one subagent and the edit into another keeps each piece focused, and keeps the main session's context clean for the parts that actually need to persist.
The tutorials that exist today, and what they assume
What's out there today, official docs, a course module, a Reddit thread, a curated list of subagent definitions on GitHub, covers the same ground: how to define a subagent, which tools to restrict it to, how to word a description so the main agent picks the right one automatically, how to chain a few of them for a bigger workflow. That's the right content for someone setting one up for the first time, and it assumes a specific thing without saying so: that once the subagent's job is done and its summary lands back in the main session, the underlying question of what it actually touched, and on whose authority, is settled. It isn't asked, because the tutorials are about getting delegation working, not about what delegation costs once it works.
What gets harder to trace when work is delegated
A single agent working alone already leaves a trace that's hard to reconstruct months later, as most coding agent roundups quietly skip over when they judge a tool only on what it produces in one sitting. Delegation compounds that same gap instead of closing it. A session with three subagents run in sequence means three separate contexts, each with its own view of what it was authorized to do, each returning a summary that the main session takes at face value. If the second subagent's edit conflicts with an assumption the first subagent made, nothing in the mechanism forces that conflict to surface, because neither subagent ever sees the other's reasoning, only the main session sees both summaries, after the fact.
That's a harder version of a question DETENT already asks about a single agent: who actually touched this file, on what authority, and can that be shown to someone who wasn't there. With one agent, the answer is at least findable in one log, however informal. With delegation, the actions are scattered across however many subagent runs the task needed, and reassembling "who did what, in what order, based on what" is a job nobody's tooling does by default: it's a manual reconstruction from summaries that were written to inform the next step, not to survive an audit.
A session with subagents versus a session with one agent
The difference isn't better or worse code, delegation is often the more disciplined way to run a complex task, keeping a research pass out of an editing pass has real value. The difference is what's left standing afterward. One agent working alone leaves one thread of reasoning, thin as it may be, that a person can at least follow start to end. A session that delegated across subagents leaves several threads that were never designed to be read together: each subagent's context existed to get that one subagent to a result, then it's gone, and what persists is only the compressed summary each one chose to hand back.
That compression is exactly where accountability gets lossy. A subagent that ran a destructive command as part of getting its job done, then summarized the outcome without every intermediate step, hands the main session a clean-looking result. Whether that result is actually clean, or just cleanly described, isn't something the summary alone can answer.
What should still be visible when the chain of delegation ends
None of this is an argument against subagents: splitting a task into isolated contexts is a reasonable way to keep a complex session coherent, and it's a step in the right direction compared with one enormous context trying to hold everything at once, the same instinct behind hooks intercepting raw events as they happen rather than reconstructing them later. What delegation doesn't provide on its own is a record that ties every subagent's actions back to the task that triggered it, in an order a reviewer can actually follow, with the authorization for each step visible rather than assumed from the fact that it happened inside an approved session.
Building that record isn't a Claude Code problem specifically, it's the same responsibility a team takes on the moment it starts composing agents itself, whether it's subagents inside one session or a custom pipeline built from scratch. A software house shipping work built this way needs an answer ready for the question that always comes later: when three agents touched a client's codebase in one session, who can show, after the fact, which one did what, and who signed off on the result. Delegation between agents doesn't remove that question. It just adds a layer between the work and the person who has to answer it.