Subagents and Orchestration, Explained
A subagent is an agent spawned by another agent for a scoped task with its own fresh context. Multi-agent design serves two distinct goals that teams routinely conflate: parallelism (independent tasks run simultaneously) and context separation (fresh eyes review, focused contexts execute). Context separation is usually the more valuable, and it works at any scale, including one subagent.
Key takeaways
- Fresh context is the mechanism behind effective review: a reviewer sharing the producer's reasoning inherits its blind spots.
- The independence test gates parallelism: no subtask may read what another writes.
- Handoff quality is brief quality: a subagent with a self-contained brief performs; one inheriting vague intent improvises.
- The integrator is a reviewer, not a stapler: unchecked parallel work is parallel risk.
- Orchestration frameworks differ mainly in control-flow rigor: graphs with checkpoints at one end, role metaphors at the other.
Two reasons to go multi-agent
Teams reach for subagents saying "parallelism" and mostly needing something else. The two genuine reasons:
Context separation. A fresh subagent has not seen the producing session's reasoning, which means it cannot inherit the misunderstandings that produced the errors. This is the entire mechanism of fresh-context review, and it works at N=1: a single review subagent reading only the diff and requirements catches what self-review structurally cannot.
Parallelism. Independent tasks genuinely run faster fanned out. The operative word is independent, and it has a mechanical test: no subtask reads what another writes. Coupled work parallelized produces conflicting edits and integration archaeology.
Context separation is the more valuable of the two for most teams, and the less discussed.
Handoffs are briefs
Every dispatch is a handoff, and handoff quality is brief quality. A complete brief contains the task, the relevant paths or data, and an explicit success criterion, and it must stand alone: the subagent does not have your conversation history, your assumptions, or your mental model. Write briefs for a competent stranger, because that is literally the recipient.
The symmetric rule on return: the integrator is a reviewer, not a stapler. Each result gets verified against its criterion before assembly. Unchecked parallel work is parallel risk; the fan-out pattern makes this a required step, not a virtue.
When you need a framework, and which
A single session with subagent dispatch covers more than most teams assume: review passes, parallel searches, scoped implementation tasks. Reach for an orchestration framework when control flow itself needs to be an artifact: persistent state, resumable checkpoints, human gates between stages, replayable runs.
Then choose by verification rigor, which is the substance behind the brand names:
| Need | Reach for |
|---|---|
| Explicit state, checkpoints, human-in-the-loop gates | LangGraph |
| Typed, validated outputs at every boundary | Pydantic AI |
| Fastest prototype, role-based decomposition | CrewAI |
| First-party vendor alignment | OpenAI Agents or Google ADK |
The full trade-offs are in Choosing an Orchestration Framework; every entry above has a scorecard in the index.
The failure modes to design against
- Parallelizing coupled work. Run the independence test before every fan-out; when in doubt, sequence.
- Vague briefs. If the brief needs your context to make sense, it is not a brief yet.
- Rubber-stamp integration. Budget integration as review time, not collection time.
- Subagent sprawl. Every agent in flight is context you are not watching; prefer the smallest topology that solves the problem, which is often one orchestrator and one worker.
The dispatching-parallel-agents skill packages the independence and scoping discipline; the workflow spec template captures the whole design on one page.
Frequently asked questions
When should I use subagents?
For context separation (fresh-context review, focused execution) and for genuine parallelism across independent tasks. Not for tasks with shared mutable state or heavy shared context.
What makes a good subagent brief?
Self-containment: the task, the relevant paths or data, and an explicit success criterion, sufficient without the orchestrator's conversation history.
Do I need an orchestration framework?
Not until control flow outgrows what a single session with subagent dispatch handles cleanly. When you do, choose by verification rigor, not by demo appeal.
Summary
- Topic
- Subagents and multi-agent orchestration
- Definition
- Scoped agents with fresh context, coordinated by an orchestrator, for parallelism and context separation
- Best used for
- Fan-out work and independent review passes
- Related concepts
- subagent, handoff, fresh-context review, fan-out/integrate
- Common mistakes
- Parallelizing coupled work, vague briefs, integrators that rubber-stamp
- Recommendation
- Adopt fresh-context review first; add parallelism when the independence test genuinely passes