Skip to content
Home › Agentic Architecture & Orchestration

Subagent decision criteria

Agentic Architecture & Orchestration

Definition

The rules for when to spawn subagents instead of handling work in a single agent — driven by parallelism, context isolation, and workstream independence.

Key points

  • Use subagents for: parallel work, isolated context, and independent workstreams.
  • Do NOT use subagents for: simple, sequential, single-file, or shared-state tasks.
  • Isolated context prevents Context rot and enables parallelism — each subagent gets a clean window.
  • Subagents inherit their own system prompt + the Agent tool prompt string + project CLAUDE.md (via settingSources) + tool definitions. They do NOT get the parent's conversation history, tool results, or system prompt.
  • Opus 4.6 can over-spawn subagents → give explicit guidance on when to delegate.
  • Realized through Hub-and-spoke orchestration (one orchestrator + specialist subagents) via the Task and Agent tool.

Why it matters for the exam

  • Multi-Agent Research System and Developer Productivity scenarios test choosing single- vs multi-agent. Complexity alone is not a reason; independence/parallelism/isolation is.

Common gotchas

  • Sequential or shared-state work is a wrong fit for subagents — the isolated context that helps parallel work hurts when state must be shared.
  • Over-spawning is a real failure mode (esp. Opus 4.6); the fix is explicit orchestration guidance, not more agents.

See also

Sources

Referenced by