AnthropicClaude Certified Architect – Foundations2026-101.3 Configure subagent invocation, context passing, and spawning
Launch independent investigations before awaiting synthesis
Completed by the knowledge check
Learning objective
Spawn independent subagents in parallel with multiple delegation calls in one coordinator response; execute dependent stages sequentially.
Core idea
For an architect designing multi-agent research, the useful unit of parallelism is an independent assignment. Launch investigations together when each agent already has the inputs it needs. Launch synthesis after those investigations return, because synthesis consumes their findings. A faster schedule cannot compensate for missing inputs.
Claude Code and the Agent SDK document invocation through the Agent tool; see 1.3.2 for tool-access configuration. The objective’s multiple delegation calls mean several calls in one coordinator response, rather than a separate response-and-result cycle for each investigation. They do not mean that every stage belongs in that response.
How it works
Separate fan-out from dependencies
Before prompting the coordinator, identify which outputs become another assignment’s inputs. Two researchers examining different aspects of the same supplied question can start together. A synthesis agent that must compare their evidence cannot start with complete input until both reports exist.
Anthropic’s multi-agent research account distinguishes parallel subagent work from parallel tool calls inside each subagent. Its lead agent starts three to five subagents in parallel rather than serially, and each subagent uses three or more tools in parallel; together, the account reports, the two changes cut research time by up to 90% for complex queries. These are separate opportunities. Launching two researchers together does not require either researcher to parallelize every search. A search whose query depends on a discovered document belongs after that discovery.
Put this distinction in the coordinator’s query() prompt, or the system prompt option (systemPrompt in TypeScript, system_prompt in Python): launch independent investigations together; wait for the required reports; then delegate synthesis with those reports included. The SDK’s agents option defines available specialists, but merely listing several definitions does not schedule them. Claude decides when to invoke them based on the task and their description fields.
Recognize the delegation calls
The Agent SDK documents detecting delegation by inspecting assistant tool_use blocks whose name is "Agent". Its compatibility note says the system:init tools list still names the tool "Task", and pre-v2.1.63 tool-use blocks also used "Task". If your instrumentation spans those versions, match both names rather than concluding that delegation stopped working.
For the objective’s fan-out pattern, look for multiple delegation blocks in the same coordinator response. This proves that the coordinator requested the work together. It does not, by itself, prove that the tasks ran simultaneously or that synthesis waited for complete reports. Inspect the subsequent execution and the synthesis assignment as well.
The SDK supports concurrent subagents and describes run_in_background on the Agent call: omitting it launches a background subagent under the documented background default, while run_in_background: false requests foreground execution when the result is needed before proceeding. That default applies from Claude Code v2.1.198; before that version it was rolling out and an omitted value could run synchronously. With fork mode on, Claude Code removes run_in_background from the Agent tool and runs spawned subagents in the background, apart from its documented foreground exceptions. See 1.3.7 for the fork-mode boundary. Avoid designing a schedule around an unverified harness version.
Keep runtime ownership explicit
With the Agent SDK, the harness owns built-in Agent execution. Messages API tool_use blocks for application-defined delegation tools are requests to your dispatcher, not the SDK’s Agent scheduler; see 1.4.3 for dispatch ordering and the result contract.
The API’s tool_choice.disable_parallel_tool_use controls whether multiple calls can appear. With tool_choice: {"type": "auto", "disable_parallel_tool_use": true}, Claude makes at most one tool call per response. This is a Messages API field, not the way to configure the Agent SDK’s subagent concurrency. Keep the two execution layers distinct when evaluating an exam option.
Apply a concurrency bound without changing the graph
The Agent SDK documents CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, supplied through its env option, to cap simultaneous subagents. The documented default is 20. At the limit, an additional spawn returns Concurrent subagent limit reached until the running count falls; sessions with ultracode active are exempt from that refusal.
The documented limits and defaults apply to TypeScript SDK v0.3.219 and Python SDK v0.2.127 and later, bundling Claude Code v2.1.219 or later; on earlier releases some limits are missing or default differently. In TypeScript, env replaces the subprocess environment, so retain inherited variables by spreading process.env; Python merges env into its inherited environment. A cap limits admitted work. It does not turn dependent synthesis into an independent investigation or guarantee that every requested agent starts.
Key distinctions and trade-offs
The scheduling choices divide by input dependency:
| Assignment | Launch decision | Reason |
|---|---|---|
| Research two independent criteria | Multiple delegation calls in one response | Each task has complete initial inputs |
| Compare the resulting reports | Delegate after both reports arrive | Findings are required inputs |
| Resolve a contradiction found during comparison | Delegate a targeted follow-up afterward | The contradiction defines the next investigation |
Parallelism can reduce elapsed investigation time, but it also increases simultaneous requests and can duplicate work if scopes overlap. Use the scoped assignments from 1.2.2. Sequential execution is appropriate when one result determines another task’s scope; it is unnecessary when all researchers already have complete assignments.
Background execution lets the coordinator continue while work runs. Completion ordering remains an architectural decision: a coordinator that proceeds directly to a final answer can omit unfinished evidence even though the fan-out itself succeeded.
Architecture / decision scenario
A research coordinator must evaluate a proposed developer platform for deployment compatibility and access-control requirements. You define two specialists through agents, give each the shared proposal and a separate criterion, and ask the coordinator to issue both Agent calls in one response. Neither investigation needs the other’s findings.
The deployment uses a supported SDK version, and the default concurrency cap of 20 admits the pair when no other subagents occupy those slots. The coordinator checks the Agent tool_result blocks for Concurrent subagent limit reached before accepting investigation coverage. If a spawn is refused, that investigation remains outstanding; the coordinator cannot treat a missing report as evidence that its criterion passed. The coordinator waits for both required reports, then supplies their complete findings to the synthesis agent, as described in 1.3.3 and 1.3.4.
The synthesizer discovers that an access-control requirement excludes one proposed deployment mode. That follow-up depends on the contradiction, so the coordinator delegates it after synthesis identifies the gap. It does not launch a guessed follow-up alongside the first two researchers. The final recommendation follows the repaired synthesis, preserving concurrency where inputs permit it and sequence where evidence requires it.
Common exam traps
- Calling each independent specialist in a separate turn and describing the schedule as parallel fan-out.
- Launching synthesis beside researchers even though their reports are its required inputs.
- Assuming multiple Messages API
tool_useblocks enforce concurrent execution. - Treating
agentsdefinitions as a fixed pipeline that runs automatically. - Applying
disable_parallel_tool_useas an Agent SDK concurrency setting. - Ignoring a refused spawn and accepting an answer with missing investigation coverage.
Where the exam guide differs
The exam guide calls the mechanism the Task tool and frames parallelism as “emitting multiple Task tool calls in a single coordinator response rather than across separate turns.” The product names the tool Agent, keeping Task in the system:init tools list and in tool_use blocks before v2.1.63. It also runs subagents in the background by default: an Agent call that omits run_in_background launches a background subagent, which keeps running while the conversation continues, so the product does not tie concurrency to one response alone. In an exam item, apply the guide’s test: emit independent investigations together in one response, and spawn a dependent stage only after the results it needs are back.
What to remember
Batch independent delegation requests in one coordinator response, verify their execution, and wait for required findings before dependent stages. The SDK harness and an application-owned Messages API dispatcher have different execution responsibilities. Concurrency settings bound the work; they do not replace the dependency decision.
Knowledge check
A research run is slow. Logs show the coordinator spawns a web researcher, waits for its result, spawns a document analyst in the next turn, waits again, and then spawns synthesis. The two research tasks do not depend on each other. Which change shortens the run while keeping synthesis complete?
Agent calls, synthesis included, in one responseCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS above its defaultAgent calls in one response, then synthesisA coordinator’s plan has two independent researchers, a synthesizer, and a follow-up investigation of any contradiction the synthesizer finds. Resolving a contradiction requires new research with tools the synthesizer does not have. When should the coordinator delegate the follow-up?
A coordinator issues two research Agent calls in one response. One tool_result reads Concurrent subagent limit reached; the other investigation returns a full report. Both criteria need supporting reports before synthesis. What should the coordinator do?
maxTurns before retrying the refused investigationdisable_parallel_tool_use before retrying the investigationmaxTurns limits turns rather than simultaneous agents, and disable_parallel_tool_use is a Messages API field, not the Agent SDK’s concurrency control.An application uses a supported Agent SDK release with ultracode inactive and must keep no more than five subagents running at once to limit load. Which setting expresses that bound?
disable_parallel_tool_use in the coordinator’s tool_choiceCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS to 5 through envagents optionmaxTurns to 5 in each specialist’s definitionCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS , supplied through env , and refuses further spawns at the limit. disable_parallel_tool_use limits tool calls per response on the Messages API, the number of definitions does not bound how many instances run, and maxTurns limits each agent’s turns rather than concurrency.References
- Anthropic, Subagents in the SDK
- Anthropic, Create custom subagents
- Anthropic, Python SDK reference
- Anthropic, Parallel tool use
- Anthropic, How we built our multi-agent research system
- Anthropic, Claude Certified Architect – Foundations Exam Guide