AnthropicClaude Certified Architect – Foundations2026-101.2 Orchestrate multi-agent systems with coordinator-subagent patterns
Select specialists for the work required
Completed by the knowledge check
Learning objective
Choose specialist subagents selectively based on task complexity rather than always running a fixed pipeline.
Core idea
For an architect operating a research application, the delegation decision is whether a specialist adds useful work that the request actually needs. A configured catalog of agents is not a checklist to execute. Start with the simplest path capable of meeting the answer contract, then add specialists when expertise, independent investigation, or context isolation justifies them.
Anthropic distinguishes dynamic orchestrator-workers from predefined parallel subtasks. The orchestrator determines the needed work from the input rather than always running the same stages. This flexibility helps broad investigations, but it introduces routing decisions you must evaluate. More activity does not by itself demonstrate better task performance.
How it works
Classify complexity from the required work
Assess the request’s ambiguity, number of decision dimensions, source diversity, and dependencies. A long question can still require one documented fact. A short request such as “Which deployment should we choose?” can require several independent investigations if the criteria involve resilience, data handling, and cost.
Use the scope obligations described in 1.2.2 to identify the work, then choose the workers. If the coordinator can verify the answer with a focused retrieval and no separate expertise, direct handling may suffice. If the request needs one specialized analysis, route to that specialist. If it needs complementary investigations that can proceed independently, delegate those investigations and synthesize their results.
Anthropic’s research system embeds effort-scaling rules in its lead agent’s prompts: simple fact-finding uses one agent with 3–10 tool calls, direct comparisons might use 2–4 subagents with 10–15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities. The rules exist to prevent overinvestment in simple queries, a common failure mode in early versions of that system. Treat the figures as evidence for scaling effort, not universal SDK quotas or a requirement to use a particular number of workers. Build your own routing criteria around representative queries and the quality they require.
Complexity is also not the same as consequence. A narrow question with a material decision can warrant an independent verification pass. Explain what that pass checks. An indiscriminate second agent that repeats the whole task costs more without necessarily exposing the critical error.
Make specialist selection legible
In the Agent SDK, define specialists in the agents option to query(). An agent’s description tells Claude when to invoke it; its prompt defines its behavior after invocation. A description such as “Helpful research expert” supplies little routing information. Describe the task category, the useful specialization, and when that specialization applies.
For example, an application-defined data-reviewer might specialize in comparing documented data-handling controls against supplied requirements. Its description should say that, rather than claim it handles every difficult question. Its prompt can define the evidence rubric and report format without loading all that detail into the routing description.
Claude uses the task and each description for automatic selection. When your application requires a particular specialist, name it in the query() prompt; the SDK page documents this as the way to guarantee that Claude uses that subagent, bypassing automatic matching. SDK documentation demonstrates instructions such as “Use the code-reviewer agent to check the authentication module.” Defining an agent does not require it to run on every request; explicit invocation supplies a concrete selection instruction.
For request-specific needs, create agent definitions at query time. The SDK documents dynamically constructing AgentDefinition values with different prompts and tools. The application can offer the specialists relevant to the classified request instead of exposing an undifferentiated catalog. Keep mandatory business checks in an application-controlled route when their execution must not depend on discretionary model selection.
Separate routing from permission and capability
Selection decides which specialist is useful. Capability decides what that specialist can do. The tools field in its definition restricts available tool names. allowedTools in TypeScript and allowed_tools in Python pre-approve tool use; do not describe them as the specialist’s restrictive tool inventory. A pre-approval list is not the same mechanism as an explicit specialist tools list.
For a local repository reviewer, tools: ["Read", "Grep", "Glob"] gives read-only investigation without editing or command execution. This is an example of capability matching, not a recommended inventory for every research agent. A worker assigned a live-source investigation needs the tools that can actually retrieve those sources.
The runtime also has a built-in general-purpose subagent even if you define no custom agents. Do not assume that a small agents catalog forbids all other delegation. In non-interactive Claude Code and the Agent SDK, CLAUDE_AGENT_SDK_DISABLE_BUILTIN_AGENTS=1 removes built-in types when you require a custom-only catalog. Use that boundary for an actual catalog requirement, rather than as a substitute for good routing descriptions.
Measure whether selection improved the result
Observe the Agent tool invocations described in 1.2.1, identify specialists by subagent_type, and compare them with the expected route. Evaluate both over-delegation and missed delegation. A successful final answer may still have invoked unnecessary specialists; a fast answer may have omitted the one investigation needed to support a recommendation.
Use paired cases that differ in a meaningful requirement. One asks for a single documented setting; another asks how that setting affects a deployment decision across multiple criteria. The desired routes should differ because the work differs. Include ambiguous requests and explicit mandatory checks so your evaluation detects accidental bypasses.
Measure final coverage, factual support, and tool efficiency alongside time and spend. Anthropic’s research account uses these types of rubric criteria to evaluate outcomes. Adopt an application-specific rubric rather than rewarding agent count, transcript length, or a fixed sequence of stages. Revise descriptions or classification rules when observed routing fails that rubric.
Key distinctions and trade-offs
Routing versus orchestration: Routing selects a specialized path for a category of request. Orchestration determines subtasks, selects workers, and combines their outcomes. A request may need routing without a multi-worker investigation.
Fixed workflow versus selective delegation: A fixed workflow fits work whose required stages are known and consistent. Selective delegation fits requests whose necessary investigations vary. Neither pattern is universally superior.
Configured versus invoked: An agent definition makes a specialist available. A task-matched description or explicit invocation determines use. Availability alone does not demonstrate execution.
Specialists give focused prompts and isolated contexts, but add coordination and inference work. Skipping an irrelevant specialist saves resources; skipping a required criterion weakens the answer. The target is sufficient coverage with justified delegation.
Architecture / decision scenario
A developer-productivity research assistant has application-defined documentation, repository, and deployment specialists. A developer asks where a documented configuration option belongs. The coordinator retrieves the authoritative passage and answers directly because no repository or deployment comparison is needed.
Another developer asks whether that configuration fits a particular service migration. The coordinator identifies code behavior and deployment constraints as separate obligations. It constructs relevant specialist definitions, delegates those two investigations, and reserves synthesis for itself. It does not run the documentation specialist merely because that agent was part of yesterday’s route.
A third request explicitly requires a data-handling review before a recommendation. The application routes through that check and names the specialist in the prompt. Tool restrictions match its task, while pre-approval settings govern permission prompts separately. Evaluation compares all three routes for coverage and unnecessary work. The resulting policy adapts to complexity without treating every request as the same pipeline.
Common exam traps
- Invoking every configured agent regardless of the request.
- Using question length or urgency as the sole complexity signal.
- Assuming an agent definition proves the specialist was invoked.
- Putting all specialist behavior into a vague routing description.
- Treating
allowedToolsorallowed_toolsas restrictive specialist tool lists. - Relying on optional model selection for a mandatory application check.
Where the exam guide differs
The exam guide names the delegation mechanism the Task tool and says a coordinator’s allowedTools “must include “Task””. Claude Code renamed the tool Agent in v2.1.63 and keeps Task as an alias. allowedTools pre-approves tools rather than listing the only ones available, and Claude can invoke the built-in general-purpose subagent through the Agent tool without any custom definition. In an exam item, read the guide’s Task as Agent, and judge selection by the descriptions, explicit invocation and catalog this lesson teaches rather than by whether a tool appears in allowedTools; see 1.3.2.
What to remember
Select specialists from the work needed to satisfy the request. Use descriptions for task matching, explicit invocation for a chosen specialist, and application routing for required stages. Judge delegation by supported coverage and resource use, not by how many agents ran.
Knowledge check
A research coordinator runs its search, analysis, synthesis and report specialists on every request. A developer asks which configuration file a documented option belongs in and waits two minutes for a formatted report. What is the best change?
An Agent SDK coordinator defines a data-reviewer specialist. Policy requires every deployment recommendation to pass that review, but logs show Claude sometimes skips it when the request does not obviously match the description. What reliably makes it run?
data-reviewer description to say it must be used for every requestdata-reviewer agent explicitly in the prompt of each recommendation requestAgent tool to the coordinator’s allowedTools list for every requestallowedTools governs permission prompts, not which specialist is chosen, and overlapping definitions make selection less predictable.A coordinator’s specialists all have descriptions like “Helpful research expert”, and Claude routes requests among them almost at random. What change improves automatic selection?
allowedTools settingdescription , so it should say what category of work the specialist handles and when. Behaviour detail belongs in the prompt , a tool list governs what a specialist can do once selected, and pre-approval has no effect on routing.A deployment recommendation must include a completed data-handling review. The coordinator prompt explicitly names data-reviewer, but this run is interrupted before that review finishes. What delivery rule preserves the requirement?
data-reviewer was calledReferences
- Anthropic, Building effective agents
- Anthropic, How we built our multi-agent research system
- Anthropic, Subagents in the SDK
- Anthropic, Create custom subagents
- Anthropic, Configure permissions
- Anthropic, Claude Certified Architect – Foundations Exam Guide