AI Subagents: When One AI Employee Becomes a Team

AI subagents are specialist agents that an orchestrator agent spins up and delegates work to. Each gets its own context window, its own tools, and a narrow job, so one big task gets split across a coordinated team instead of one overloaded agent. You split into subagents only when the work has genuinely separate kinds of expertise, more context than a single agent can hold, or sub-tasks that need to run at the same time. Most jobs do not. A team adds coordination cost, more places to fail, and a much bigger token bill, so the honest default is one good agent, not five.

On a factory line, you don't add a second machine because the brochure has two on the cover. You add it when one machine is the bottleneck. Subagents are the same decision. This piece is the operating picture: what a subagent is, when a team earns its cost, the worked example I use, and when splitting makes things worse.

What is an AI subagent?

A subagent is a second agent that a first agent hands a sub-goal to. To see why that matters, picture a single agent first. It's a loop. A model gets a goal and some tools, proposes an action, something runs it, the result comes back, and it proposes the next step, on and on until the goal is met. If you haven't met the base unit yet, I wrote it up in what is an AI employee.

A multi-agent system is that same loop with one new move: delegation. An orchestrator agent runs its loop, but some of its "actions" aren't tool calls. They hand a whole sub-goal to a subagent, which runs its own loop, with its own tools and memory, and reports back up. One loop becomes a tree of loops. Anthropic calls the common shape the orchestrator-workers pattern: a lead agent breaks a task down and delegates to subagents that work in parallel (Anthropic, Building effective agents, 2024).

Every such system has the same four parts, and only the first two ever show up in a demo:

An orchestrator holds the overall goal, decides how to split it, and assembles what comes back. The general contractor; it doesn't do the specialist work itself.
Subagents are spun up for a focused job, each with its own context window (so one buried in source documents doesn't crowd out another's analysis) and its own tools.
A definition of done is the success criteria the work is measured against. Without it, a self-directed team produces something fast and confident, but not necessarily what you needed.
A trace is a replayable record of who did what, with what inputs and outputs. The only way anyone reconstructs what happened after the fact.

Why split one agent into subagents at all?

Two reasons, and both are about context. The first is isolation: a subagent gets a clean, separate context window for its slice of the job. When I send a research subagent off to read twenty filings, all that raw text lands in its window, not the orchestrator's, which only gets the three-paragraph summary back. The main thread stays clear-headed because the mess is quarantined in a worker that's thrown away when it's done.

The second is parallelism. Three subagents reading three sources at once finish in roughly the time one takes. If the sub-tasks are genuinely independent, that's real wall-clock speed.

That's the lens I'd want you to hold the rest of this through: subagents buy you context isolation and parallel speed. They do not buy you intelligence. A team of five mediocre agents is five mediocre agents with a coordination problem. Closely related is how you give any single agent a narrow, well-defined job in the first place. That's the skills layer, worth getting right before you reach for a second agent.

When do you actually need a team of AI agents?

Here's the part that runs against every demo: a multi-agent system is a cost, not an upgrade. More agents mean more coordination, more places to fail, more to observe, and more to maintain. Anthropic's own engineering team notes that multi-agent systems can burn many times more tokens than a single chat, which is why they reserve them for high-value work rather than everyday tasks (Anthropic, How we built our multi-agent research system, 2025).

So there are three honest answers, and only one is "build the team":

One agent is enough most of the time. If the work is a single line of reasoning over a manageable amount of context, one agent in a loop does it, and you have one thing to supervise instead of five. The standard advice is to find the simplest pattern that works and add complexity only when it demonstrably improves results (Anthropic, 2024).
A team pays when the work is genuinely parallel and specialised. A deep research job, for example, splits into distinct, independent investigations that each benefit from their own focus and context, and from running at once. That's a team earning its keep.
Sometimes it shouldn't be agents at all. If the steps are fixed and the inputs clean, deterministic code is cheaper and more reliable. If the call carries real consequence, it belongs with a person, perhaps with agents preparing the work, but not making the decision.

There's even a strong contrarian case for keeping systems single-threaded wherever you can, because splitting work across agents multiplies the ways context gets lost between them (Cognition, Don't Build Multi-Agents, 2025). The failure I see most: a team reaches for subagents because multi-agent is what everyone is demoing, and ends up with five agents and a coordination problem to do a job one agent or a scheduled script would have done quietly.

What does a subagent team look like in practice?

Take a job I actually fan out: produce a verified market brief on a competitor. The brief isn't "summarise this page." It's an outcome: find the facts across the web, draft the brief, check every claim against a source, and don't conclude until the claims hold up. Here's the flow across an orchestrator and three subagents.

The orchestrator reads the goal and splits it, spinning up a research subagent, a drafting subagent, and a verification subagent, each with its own clean context window.
The research subagent goes wide: reads sources, pulls quotes and figures, reports a structured findings packet back up. All the raw page text stays in its window, not the orchestrator's.
The drafting subagent takes only that packet, not the twenty raw pages, and writes the brief from a clean, compressed input, so it stays focused on prose rather than source clutter.
The verification subagent gets the draft plus the findings packet and does one adversarial job: check each claim against its cited source and flag anything unsupported. This is the step that catches an agent being confidently wrong. A fresh agent with a narrow remit spots a fabricated figure far better than the agent that wrote it.
Flagged claims go back to research. The orchestrator loops draft to verify until the brief meets the definition of done, then assembles the final answer.

Notice what each split bought. The research subagent's clutter never pollutes the draft. Verification works because it's a fresh pair of eyes, not the author marking its own homework. And the three could run their first passes in parallel. None of that requires a smarter model. It requires bounded, separated context, which is exactly what a single overloaded agent can't give you.

How does Brixon run its own agency on subagents?

We run our own agency on roughly nine AI agents, and the honest answer is that most of them are single agents, not teams. Lead triage is one agent. The newsletter drafter is one agent. We don't make something multi-agent because it sounds impressive; we do it when one agent hits a real wall, usually a context wall, or a "these two passes shouldn't share a brain" wall, like draft-and-verify above.

Same discipline I bring to client builds. I map the process first, deciding step by step what should be deterministic code, what should be one agent with a human gate, what warrants subagents, and what should stay human. Process before tools. It routinely means recommending against the team of agents a client came in excited about. The shorthand I keep coming back to is AI for judgment, code for action, and a team is judgment multiplied, with all the coordination cost that implies. If you can't yet observe what your agents do, fix that before you add more; I wrote about why in stop babysitting AI agents.

What goes wrong when you split too early?

A team that isn't bounded, isn't given a definition of done, and isn't observable doesn't fail loudly. It fails by being fast, confident, and wrong, and it leaves no trace of how. Errors compound across a team: a shaky figure from the research subagent becomes an input to the drafting subagent, which feeds a confident brief from the orchestrator, and the wrongness gets laundered into something that looks authoritative.

The coordination tax is real too. Every hand-off is a place where the orchestrator can misread a report, where a sub-task can be defined too loosely, where context gets lost between agents. Before you split, the test I apply is simple: can one agent hold all the context this job needs, and is the work actually sequential? If yes to either, one agent wins. Splitting is something you earn at a wall, not a default. The discipline that keeps any of this honest, single agent or team, is measurement, which is why I treat evals as non-negotiable.

Frequently asked questions

What is the difference between an AI agent and a subagent?

An AI agent is a model running a loop: it gets a goal and tools, proposes actions, and works until the goal is met. A subagent is simply an agent that another agent (an orchestrator) delegates a sub-goal to, with its own separate context window and tools. The subagent does its focused job and reports a result back up, so "subagent" describes a role in a team, not a different kind of thing.

When should I use a multi-agent system instead of one agent?

Use a team only when the work has genuinely separate kinds of expertise, more context than one agent can hold, or sub-tasks that must run in parallel to be worth it. If the steps are fixed with clean inputs, deterministic code is better; if the decision carries high consequence, keep a human in charge. A team is a cost you take on at a real wall, not a default.

What is an orchestrator agent?

An orchestrator agent holds the overall goal, decides how to split the work, delegates sub-goals to specialist subagents, and assembles what comes back into a final answer. It's the general contractor of the system: it coordinates the team but doesn't do the specialist work itself. Anthropic calls this the orchestrator-workers pattern.

Do subagents make an AI system smarter?

No. Subagents buy you context isolation and parallel speed, not intelligence. Each subagent gets a clean context window for its slice of the job, and independent sub-tasks can run at once, but a team of five mediocre agents is still five mediocre agents plus a coordination problem. Splitting solves context and throughput limits, not reasoning quality.

How many AI agents do you actually need?

Fewer than the demos suggest. We run our own agency on roughly nine agents, and most of them are single agents rather than teams. We only split into subagents when one agent hits a context wall or two passes genuinely shouldn't share a brain. Start with one good agent per task and add a team only when you can point to the specific limit forcing the split.

Sources and further reading

Anthropic, Building effective agents (2024): when to use agents versus workflows; the orchestrator-workers pattern; prefer the simplest solution. anthropic.com
Anthropic, How we built our multi-agent research system (2025): multi-agent orchestration, token cost, and observability in practice. anthropic.com
Cognition (Walden Yan), Don't Build Multi-Agents (2025): the case for single-threaded systems and the cost of lost context between agents. cognition.ai

I build agents the way an engineer adds machines to a line: only at the bottleneck, and only when the new part earns its coordination cost. Most of what I ship for clients is one well-scoped AI employee doing one real task in the tools they already use, with a team of subagents only where the work genuinely splits. If you want to see how that looks as a managed system, here's how we build managed AI employees, or you can just tell me what task is your bottleneck.