A transit planning coordinator needs corridor studies for three routes at once. How can it spawn that work efficiently in one model turn?
Select an answer to reveal the explanation.
Short Explanation
Three corridors, three Task tickets in the same dispatch. Send them together so the studies run in parallel instead of waiting in a single-file line.
Full Explanation
A transit planning coordinator that needs corridor studies for three routes at once should emit multiple Task calls in one response to spawn parallel corridor-study subagents. One model turn can request several Tasks; the runtime then runs those specialists concurrently, cutting wall-clock time versus serial delegation across the three corridors.
Multiple Task calls work when corridors are independent enough to research in parallel and the coordinator will aggregate afterward into a unified planning view. Parallelism is an orchestration feature expressed as multiple tool_use blocks, not a vague prompt wish that one subagent invents sibling work.
Issuing a single Task and hoping the subagent invents the other corridors under-specifies work and loses explicit ownership per route. Running three studies strictly sequentially across three separate human approvals first adds needless delay when parallel Tasks are available. Encoding all corridors as one Bash script instead of using Task bypasses the subagent pattern the architecture is testing and weakens role isolation.
Exam caveat: parallel Tasks still need distinct prompts and scopes to avoid duplicate work; parallelism is not identical queries. Operational check: on a single coordinator turn, assert three Task tool_use blocks are emitted and three subagent runs start without waiting for human approval between them.