Introduction

Delegate to a subagent when a focused, independently bounded piece of work would otherwise overload the primary agent's context or mix responsibilities that need different tools and permissions. Do not delegate merely to make a design appear more agentic. A good orchestration design makes the task boundary, authority, expected handoff, and failure behavior explicit before work begins.

Claude Code documents subagents as specialized assistants that work in their own context window with a custom system prompt and specific tool access. The subagents guide emphasizes the corresponding context benefit: a subagent can perform high-volume side work and return a summary rather than flood the main conversation. That isolation is useful only when the parent can still evaluate the returned result.

Architecture Overview

Subagent orchestration has a coordinator and one or more workers. The coordinator owns the user outcome, shared constraints, dispatch decisions, integration, and final accountability. A worker owns a narrow deliverable within a defined capability boundary. The handoff is the contract between them: it should state what was requested, what evidence or artifact is returned, what remains uncertain, and whether a human decision is required.

This is a responsibility model, not a demand that every process use multiple agents. If one agent can complete the task within a clear context and permission boundary, adding workers may increase latency, cost, and integration risk without improving the result.

Core Components

Decomposition and responsibility boundaries

Decompose by independent outcomes, not by vague phases such as “think” and “implement.” Suitable boundaries include gathering evidence from a constrained source set, reviewing a bounded artifact, or producing an analysis that a coordinator can verify. Each worker should receive the minimum context needed to complete its assigned deliverable and should not be given responsibility for the final business decision unless that authority is explicitly intended.

The Agent SDK overview lists subagents as specialized agents for focused subtasks. Use that capability to isolate work with a distinct information or tool profile. Avoid dispatching multiple agents to edit the same mutable resource unless the coordinator also owns serialization, conflict detection, and rollback.

Context isolation and handoffs

Isolation protects the coordinator's context from logs, search results, and other high-volume intermediate material, but it also means a worker does not automatically share the coordinator's full reasoning state. A handoff should therefore contain the task, constraints, acceptance criteria, relevant inputs, permitted actions, and expected output shape.

Ask workers to return conclusions with evidence, assumptions, and unresolved risks. The coordinator should validate that return against the original constraints rather than treating a confident summary as proof. This is an architectural recommendation for reliable delegation; it is especially important when workers operate with different data access or tool permissions.

Permissions and authority

Give each worker a least-privilege tool surface that matches its responsibility. A research worker may be read-only; a remediation worker may propose a change but require the coordinator or a human to approve execution. In Claude Code, a subagent definition can establish its own tool and permission configuration. In an Agent SDK runtime, however, subagents inherit the parent session's permission mode by default. An AgentDefinition can override that mode except when the parent uses bypassPermissions, acceptEdits, or auto; those parent modes apply to every subagent and cannot be overridden per subagent. This runtime inheritance does not remove the need for authorization in the services a tool reaches.

The agent-loop documentation explains that tool permissions can be allowed, denied, or made subject to approval. Apply the same reasoning to a delegated system: the coordinator should not route a task to a worker solely to bypass a permission that it would otherwise need to respect.

How Components Work Together

A robust delegation flow is simple:

  1. The coordinator decides that a subtask is independent enough to isolate.
  2. It sends a bounded handoff with the worker's deliverable and authority.
  3. The worker performs only the permitted work in its own context.
  4. The worker returns a concise result, evidence, and uncertainty.
  5. The coordinator validates the result, integrates it with other evidence, and owns the final action or escalation.

Parallel workers are appropriate when their outputs do not depend on each other and their capabilities do not contend for the same mutable state. For example, separate read-only investigations can proceed in parallel. Writes and other side effects should be serialized or otherwise coordinated so that one worker's action does not invalidate another worker's assumptions.

Design Considerations

Failure containment

Contain a worker failure within its own deliverable. The coordinator should be able to mark one branch incomplete, retry only that bounded task when appropriate, substitute a safe fallback, or escalate without corrupting the rest of the result. Preserve the worker's evidence and error context so a reviewer can distinguish an unsupported conclusion from a system failure.

Cost and termination controls also apply to delegated work. In Claude Code v2.1.217 or later, the agent-loop documentation states that an Agent SDK budget cap covers subagent spend and that background subagents are stopped when the cap is reached. Set an overall budget and time expectation at the coordination level, then use smaller task boundaries to prevent a single worker from consuming the entire run without a useful handoff.

Best Practices

Use delegation for specialized, isolated, or parallelizable work with a measurable return value. Keep the coordinator accountable for shared policy, integration, and externally visible actions. Make handoffs structured enough for validation, and choose sequential execution whenever workers would otherwise race on the same state.

Treat a subagent result as input to a decision, not as an automatic authorization to take a high-impact action. When the result suggests an irreversible change, require the designated approval and apply the same service-level controls that would govern a non-agentic caller.

Common Mistakes

A common mistake is giving every worker the coordinator's full context and permissions. That removes the isolation benefit and broadens the impact of an incorrect delegation. Another is launching parallel workers with overlapping write access, which creates conflicts that the model cannot reliably resolve after the fact.

It is also a mistake to confuse worker specialization with project-level extension packaging. This article concerns runtime delegation and coordination. Persistent Claude Code extensions, distribution, and packaging are separate topics with their own configuration and lifecycle decisions.

Certification Relevance

For the public CCAR-F agentic architecture and orchestration scope, defensible delegation means explaining why a task is split, what each worker can access, how its output is checked, and how failures are contained. It does not require reconstructing assessment content or treating a multi-agent design as the default solution.

Conclusion

Subagents are most useful when they isolate a clear responsibility while leaving accountability with a coordinator. Define the handoff before dispatch, restrict each worker's context and permissions, parallelize only independent work, and make incomplete or unsafe results visible to the system that owns the final decision.

Authoritative Sources