An autonomous AI agent that a parent agent spawns to handle one bounded task, usually in parallel with sibling subagents, then return a structured result for the parent to synthesize.

Subagent | The Wise Operator

What It Is

A subagent is a child AI agent that a parent agent spawns to do one bounded piece of a larger task. The parent holds the goal and the context. The subagent gets one job, runs it in parallel with its sibling subagents, and returns a structured result. The parent then synthesizes the returns into the next step.

The pattern arrived in mainstream tooling through Claude Code’s Task tool in mid-2025, was adopted by OpenAI Codex and Cursor through the year, and landed in Google’s Antigravity 2.0 on May 19, 2026, where Google calls them dynamic subagents and promotes parallel orchestration as a first-class workflow primitive. By spring 2026, every serious coding agent and most production ai-agent frameworks ship a subagent abstraction.

The simplest mental model is a project manager and her specialists. The parent is the manager. The subagents are the specialists she emails. Each specialist gets a sealed brief, runs in parallel with the others, and turns in a written deliverable. The manager assembles the deliverables into the final answer. Nobody on the specialist side ever sees the rest of the project, which is the point.

How It Actually Works

In code, the parent agent calls a tool whose contract looks roughly like spawn_subagent(prompt, tools_allowed, return_schema). The runtime opens a fresh context window for the child, populates it with the prompt and a restricted toolset, and lets the child run its own loop until it either calls return or hits a step cap. The child’s full transcript is discarded. Only the structured return value is passed back to the parent.

The architectural point of the pattern is that subagents save tokens. A parent that does ten things sequentially carries the transcript of all ten through its context. A parent that spawns ten subagents in parallel pays only for the parent’s planning context plus the ten short child contexts, none of which see each other. The agent loop cost math gets dramatically better, sometimes by an order of magnitude on long tasks.

Why It Matters Right Now

The shift this week is that subagents are no longer a power-user trick inside one CLI. They are the recommended workflow shape in mainstream agentic-coding tools. Cursor’s Composer 2.5 plans across multi-step tasks by decomposing into subagent calls. Antigravity 2.0 ships dynamic subagent orchestration as a checkbox in its scheduled tasks UI. Claude Code’s subagent pattern is now the default architecture for any non-trivial routine.

If you are an operator who delegates work to AI, the next question is not “which model do I use” but “how do I decompose the job into subagent briefs.” That decomposition is the new operator-decision moment, and it is the one most teams skip when they migrate from a single chat tab to an agentic workflow.

The Cost Tradeoff

Subagents make the cost curve better in one dimension and worse in another. They cut redundant context, which compresses the token bill. They also produce many small, fast tool calls in parallel, which can compound usage limits faster than a single deep loop. A team that switches from sequential to parallel subagents and does not adjust its rate-limit budget will sometimes hit the platform ceiling faster than before.

The second cost is debugging. When ten subagents run in parallel and one returns a wrong answer, the parent often synthesizes the wrong answer into the final output without flagging it. The transcript that would let you diagnose the failure was discarded at child-return time by design. Most agent frameworks now ship optional transcript persistence, which adds storage cost but recovers auditability. The honest operator turns it on for any workflow that touches production data.

How TWO Uses It

TWO frames subagents the same way it frames any delegation. The question is not whether to delegate, but where the operator’s judgment still has to sit in the loop. Scott’s editorial rule is that the parent agent’s plan is the only place a human reviewer should bother to read closely. The subagent transcripts are noise unless one of them errored. The synthesis the parent produces is the surface where human judgment actually changes the outcome.

The concrete operator-decision moment lands when you are designing a new agentic workflow. Write the parent prompt by hand. Allow yourself to generate the subagent prompts from the parent’s plan automatically. If you find yourself hand-tuning subagent prompts, the parent prompt was probably too vague to start with. Fix the parent. Stop micromanaging the children. That one habit is the difference between an agentic workflow that scales to fifty steps and one that quietly stops working at fifteen.

A Concrete Operator Scenario

You ask Cursor Composer 2.5 to refactor fifteen API routes to use a new error-handling helper. Composer plans the refactor as fifteen subagent calls, one per route, executes them in parallel, and returns a single diff for your review. Twelve diffs look right. Three look wrong in the same way: the subagent missed a wrapping try/catch that the helper now handles internally. The interesting question is not how to fix the three. It is whether your parent prompt named the wrapping pattern, or whether you assumed each subagent would notice it.

If you named it and three children still missed it, your runtime has a real bug worth filing. If you did not name it, the parent prompt was the bug and the children were doing exactly what they were asked. The fifteen-second triage saves an hour of debugging the wrong layer.

A subagent is one specific instance of a broader agent-control-surface pattern: the parent agent is the surface where a human approves, the children are the work that happens out of sight. The pattern only earns its keep when the parent’s plan is clear enough to make the children’s transcripts safe to discard.