A large task almost always splits into parts unrelated to each other: figure out auth, find where the tests live, check an external API contract. It is natural to hand all of it to one agent and go through them in turn in a single conversation - it is already in context, why multiply entities. The problem is that independent pieces of work, poured into one feed, interfere with each other more than it seems.

The naive move is to keep everything in the parent agent's single context and go through the items sequentially. While there are two or three short parts, this is tolerable. But every step of exploration settles in the window: files read, dead-end branches, long search outputs. The context swells, and less and less attention is left for the main task.

It breaks on the fact that the context window is a resource, not an endless feed. The noisy exploration of one subtask crowds out what is needed for another; the agent starts re-reading what it already read, confusing threads and spending tokens to restore what it itself displaced. A sequential pass over independent parts pays for its apparent simplicity with a growing context and lost focus.

The professional mechanism is a subagent: a separate role with its own context and its own spend, to which the parent delegates part of the work. It launches in one of two modes. Foreground pauses the parent and runs inside the session - you can approve and deny tool calls in real time. Background runs in parallel while the parent continues, but tools not pre-approved in advance are automatically denied. At the date of this snapshot it sits behind the Subagents (Preview) toggle, whose state is worth checking against the current version.

Why exactly two modes rather than one universal one. Foreground is needed where human control over permissions matters: the agent may reach a write or an exec, and you want to see the request before it runs. Background is needed where parallelism matters and you are ready to decide in advance which tools the subagent may use on its own; anything not allowed it will not wait for - it is simply denied. The split directly reflects the trade: real-time control versus a parallel run without stops.

The subagent's role is chosen to match the nature of the work. The built-in subagent_explore is best for read-only research: it runs on a cheaper default model and cannot edit files, so it is safe for reconnaissance. subagent_general inherits the parent's model and has full capabilities, up to changes - it fits when the subagent is asked to finish a whole part of the task, not just to look around. Choosing the role here is the same decision about permissions as the permission model, only made in advance and for the whole subagent.