When does your agent actually need subagents?

← All field guides

What prompted this guide

In its 22 October guidance, Anthropic reports that some enterprise agents benefited from folding specialist subagents into a shared loop with skills. It also identifies useful roles for subagents, including parallel work and verification. These are deployment observations, not a guarantee about your application.

The decision framework below is our editorial recommendation. The scenarios are illustrative, not benchmark results.

Define the choice before comparing it

A tool performs an operation, such as fetching an issue. A skill supplies instructions for a procedure. A subagent adds another model-driven execution loop that can make decisions and call tools. Loading instructions does not, by itself, require starting another agent.

For the underlying mechanics, read how a turn works in an agent harness. A separate context can keep exploratory detail out of the main conversation, but the caller still needs enough evidence to use the result correctly.

A decision table for your next workflow

Use these as starting hypotheses, then test them against your workload. On small screens, scroll the table horizontally.

Two worked examples

Example 1: diagnosing a failed deployment

Imagine an assistant reading a release diff, deployment events, and error traces. A routing agent sends these to three specialists. Each returns a plausible explanation, but none sees that the same configuration key changed across all three sources.

Try one investigator that can inspect all three sources, loading release and observability procedures as needed. Grade whether it identifies the failing key and supports the explanation with evidence. If log exploration becomes too large, delegate that bounded search and require timestamps, query scope, and links to the relevant events.

Example 2: checking three independent SDK migrations

Suppose three repositories use unrelated SDKs. Give each investigator its repository, target version, allowed actions, and an output contract: affected calls, compatibility evidence, unresolved questions, and validation results. Have the coordinator check the combined rollout order.

Keep edits isolated so concurrent workers cannot overwrite each other. If one migration changes a shared interface, pause the dependent work until that interface is agreed. Parallel execution helps only while the tasks remain sufficiently independent.

Run a small architecture experiment

Our suggested experiment compares the existing workflow with one narrowly changed alternative. Choose acceptance criteria before looking at the results.

1. Build a representative task set. Include a routine success, missing information, a failed tool, conflicting evidence, and a forbidden action. Use replayable fixtures where live system changes would make comparison unfair.
2. Define success beyond the final message. Inspect the produced artifact or system state. For a deployment diagnosis, require the correct cause and supporting events; a confident explanation alone does not pass.
3. Hold the environment steady. Record model version, tool access, fixtures, and budgets. Repeat tasks to expose run-to-run variability.
4. Record the full cost. Count coordinator and worker usage, retries, elapsed time, and human corrections. Track failed attempts as well as successful ones.
5. Inspect changed outcomes. Review every task that switches from pass to fail. A faster average does not excuse a new permission violation or an incorrect artifact.
6. Make a reversible decision. Keep the candidate only if it meets your quality requirements and improves the constraint you care about. Retain the previous configuration for rollback.

For a fuller grading workflow, see building an evaluation loop. No performance improvement is claimed here; this is a plan for collecting your own evidence.

Write the delegation contract

Before starting a worker, specify its objective, available inputs, allowed tools, deadline or budget, and expected evidence. Make uncertainty a valid output. Require the caller to reconcile contradictory findings and own the final result.

For example: “Inspect repository A for calls incompatible with SDK version B. Return file locations, the relevant migration references, and checks performed. Do not edit files. Report any unresolved compatibility questions.” This is easier to assess than “be the SDK expert.”

Further reading: AI Agents in Action offers implementation context for agent workflows.