When Claude emits several tool_use blocks in a single turn, you can run them concurrently — but the results must come back as one user message containing all the tool_result blocks, each matched by tool_use_id. Get this wrong and the API rejects the turn or the model silently mis-attributes answers.
What to build
- Define three independent tools (say: inventory lookup, shipping estimate, tax rate).
- Prompt so that all three are needed to answer one question.
- Collect every tool_use block from the response before executing anything.
- Execute them concurrently — threads, asyncio, whatever your stack offers.
- Assemble a single user message whose content array holds all tool_result blocks.
- Deliberately break one pairing (swap two tool_use_ids) and record what happens.
- Set tool_choice disable_parallel_tool_use to true and observe the behaviour change.
Done when
- All results return in one user turn, never as several sequential user messages.
- Result order in the array does not affect correctness — the id does the matching.
- One slow tool does not serialise the others; wall-clock is roughly the slowest tool.
- You have seen and can describe the failure mode from a mismatched tool_use_id.
If you want to go further
- Add a per-tool timeout that returns an error tool_result rather than hanging the turn.
The trap this exercise teaches
Sending one user message per tool_result. The turn structure is one assistant turn of tool_use blocks answered by one user turn of tool_result blocks.
Before you start
The theory behind this build is covered in Parallel tool use and result pairing. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Docs — Tool use.
Check yourself against the exam
This exercise sits in Domain 1, which is 27% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.