AnthropicClaude Certified Architect – Foundations2026-101.4 Implement multi-step workflows with enforcement and handoff patterns
Investigate each concern before resolving the case
Completed by the knowledge check
Learning objective
Split multi-concern requests into independent parallel investigations that share necessary case facts and lead to one resolution.
Core idea
A support request can contain several concerns: a duplicate charge, a missing delivery, and a request to cancel renewal. As the architect, you need a workflow that covers all three without forcing unrelated investigations into a serial chain. Split the request by the evidence each concern needs, run independent reads in parallel, and keep one coordinator responsible for the final resolution.
Parallelism applies to investigations whose inputs are already available. It does not remove prerequisites or authorize multiple workers to issue competing refunds. Share the case facts needed to investigate consistently, then combine the results before selecting actions. A faster answer that drops one concern or counts the same refund twice is an incorrect resolution.
See 1.2.1 for coordinator routing and 1.2.4 for synthesis refinement. This Bite applies that pattern to one multi-concern customer case, including the difference between parallel client-tool calls and delegated investigations.
How it works
Partition by evidence and dependencies
Start with a concern list derived from the customer’s request. For the example case, billing needs charge records, delivery needs shipment events, and renewal needs subscription state. Assign each concern an explicit outcome: establish whether the charge is duplicated, establish the delivery status, and establish whether renewal remains active.
Prepare common inputs before fan-out. In this example, the trusted case record supplies the customer ID, order ID, subscription ID, and the customer’s requested outcomes. Each investigation receives the relevant subset plus enough case identity to attach its result to the same request. These identifiers are application data, not a built-in Anthropic case object.
If the delivery investigation needs the order ID returned by a customer lookup, it cannot begin before that lookup completes. Once the identifiers are available, reading charge records and shipment events can proceed together. A proposed refund depends on the resulting findings and the gates in 1.4.1–1.4.2, so it belongs after investigation and synthesis.
Choose the execution mechanism
For a Messages API integration, expose read tools such as the illustrative get_charge_history, get_shipment_status, and get_subscription_state. Claude can return multiple tool_use blocks in one response with stop_reason: "tool_use". Your dispatcher decides whether to execute those calls concurrently, for example with Promise.all in TypeScript or asyncio.gather in Python.
The API does not prescribe execution order. Independent read-only calls usually suit parallel execution; tools with side effects, shared state, or ordering requirements can require sequential execution. Check the actual proposed inputs before dispatching rather than interpreting a batch as evidence that the calls are independent.
Return one tool_result per proposed call, correlated by tool_use_id, together in the next user message. Place the result blocks before any text. If one investigation fails or is skipped, provide its result with is_error: true; do not erase that concern from the case. See 1.1.2 for the complete history rules.
Use Agent SDK subagents when an investigation needs its own multi-step reasoning and tool work. Configure named agents through options.agents, with AgentDefinition.description describing when to delegate and AgentDefinition.prompt defining the role. Its tools field sets the tools available to that specialist. The parent invokes the Agent tool with the investigation prompt and the selected subagent_type. Several subagents can run concurrently, so independent investigations finish in the time of the slowest one. The CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS environment variable, set through the env option, caps them at 20 by default on SDK releases that bundle Claude Code v2.1.219 or later; beyond that, a spawn returns Concurrent subagent limit reached until one finishes.
Following the context-passing rule in 1.2.1, include the necessary case facts in each Agent tool prompt, because that prompt string is the only content the parent passes to a non-fork subagent: customer, order, and subscription IDs, the concern the worker owns, the requested outcome, known findings, and evidence locations. Give each specialist the relevant subset so its investigation remains attached to the same case.
Make results fit one synthesis
Give every investigation a return contract in its delegated prompt: concern, finding, evidence, uncertainty, and recommended next action. This is an application-designed contract, not an SDK result type. For example, the billing specialist should distinguish two settled charges from one settled charge and one temporary authorization. The delivery specialist should distinguish a confirmed failure from unavailable tracking evidence.
The coordinator then maps the findings back to the concern list. A successful billing result does not compensate for a missing subscription result. If results disagree about the order or overlap in the proposed remedy, reconcile those differences before choosing actions. A worker’s recommendation is evidence for the coordinator’s decision, not authority to execute a payment.
Synthesize one case response that addresses every concern, states what can be resolved, and identifies what remains blocked. Keep sensitive writes behind the same deterministic gates even when every investigator recommends them. For unresolved concerns, request focused follow-up or produce a human handoff rather than silently treating unavailable evidence as a negative finding.
Key distinctions and trade-offs
Parallel tool calls and subagents provide different levels of separation. Multiple read calls in a Messages response gather facts for one conversation. A subagent can perform a deeper investigation in an isolated conversation and return a summary. Choose the smaller mechanism when each concern needs only a lookup; choose specialists when concerns require distinct analysis.
Shared case facts are also different from shared conversation history. Explicit identifiers and known findings let workers investigate the same case without duplicating every message. Isolation reduces the parent’s accumulation of intermediate material, but makes the delegated prompt and final result more important.
Finally, independent investigation does not imply independent resolution. Billing and delivery might each recommend compensation for the same order. Their evidence can be gathered independently, but the coordinator must combine the proposed remedies and check policy before committing any financial operation.
Architecture / decision scenario
A verified customer reports being charged twice, receiving no parcel, and wanting renewal canceled. The coordinator records three concerns and obtains the trusted order and subscription identifiers. It launches charge-history, shipment-status, and subscription-state reads in parallel because none requires another investigation’s result.
Billing finds one settled charge and one pending authorization, so a duplicate settled payment is not established. Delivery finds a confirmed carrier exception and recommends a policy-eligible remedy. Subscription lookup fails. The dispatcher returns all three results in one user message, including is_error: true for the failed lookup, so the unresolved concern remains visible.
If billing and delivery require deeper analysis, named SDK subagents receive the same case ID and relevant order facts in separate Agent prompts. Neither receives payment-execution responsibility. Their findings return to the coordinator, which addresses the pending authorization, evaluates the delivery remedy through the sensitive-operation gate, and pursues subscription follow-up. If it escalates, the human receives the unresolved renewal request alongside the established billing and delivery findings, not three disconnected worker replies.
Common exam traps
- Serializing unrelated reads merely because the customer mentioned them in sequence.
- Starting an investigation before its required identifier exists.
- Delegating “investigate this customer” without the case identifiers the worker needs.
- Treating several proposed tool calls as proof that concurrent execution is safe.
- Returning a separate user message for each result in a parallel batch.
- Dropping a concern because its tool failed, or letting specialists execute overlapping remedies.
Where the exam guide differs
“Investigating each in parallel using shared context.” Task Statement 1.4 does not say how the context is shared. In the Agent SDK, a subagent that is not a fork starts with a fresh context and no parent conversation; the only content the parent passes is the Agent tool’s prompt string. Read “shared context” in an exam item as case facts written into each delegated prompt, never as history the workers see by default.
“The Task tool.” The guide’s neighboring task statements name the subagent-spawning tool Task. The SDK names it Agent in tool_use blocks; "Task" still appears in the system:init tools list, and tool_use blocks used it before Claude Code v2.1.63. Read an option that spawns investigators through Task as this Bite’s Agent tool call.
What to remember
Partition concerns, satisfy shared prerequisites, and pass necessary case facts explicitly. Run independent investigations in parallel through client tools or subagents. One coordinator combines their evidence, preserves unresolved concerns, and selects a single resolution subject to the operation gates.
Knowledge check
An Agent SDK coordinator splits a verified customer’s request — a duplicate charge, a missing parcel and a renewal cancellation — across three non-fork named subagents, giving each the sentence of the message about its concern. The message contains no case identifiers, but the coordinator already has them. The billing subagent reports that it cannot tell which order is meant. Which change fixes this?
Agent promptAgent tool’s prompt string is the only content the parent passes. Shared case facts must therefore be written into each delegated prompt. The customer’s message names the concerns, not the trusted case identifiers; re-identifying the customer repeats verification and can attach findings to a different record, and running the workers serially changes timing, not what each one receives.To investigate a duplicate charge and a missing parcel, the agent needs get_charge_history and get_shipment_status. Both take the order ID, which only get_customer returns, and neither depends on the other’s result. Which execution plan satisfies the prerequisite with the least read latency?
get_customer first, then the other two reads in parallelget_customer to confirm their targetClaude returns three read calls in one response. Charge history and shipment status succeed; the subscription lookup times out. How should your Messages API dispatcher return the results?
tool_result blocksis_error: truetool_use needs its tool_result , and all results of a parallel batch go back together in one user message, before any text. Marking the failure with is_error: true keeps the renewal concern visible as unresolved. Leaving the call out breaks the history contract, separate messages teach Claude to avoid parallel calls, and reporting “no subscription” turns unavailable evidence into a false negative finding.A billing subagent and a delivery subagent each recommend a $40 credit on the same order for the same late delivery. Neither has payment responsibility. What should the coordinator do?
References
- Anthropic, Parallel tool use
- Anthropic, Subagents in the SDK
- Anthropic, Claude Certified Architect – Foundations Exam Guide