A customer emails support: "Three issues — my last invoice is wrong, my shipment from Tuesday hasn't arrived, and the product I received is defective." Your coordinator agent currently spawns three subagents (billing_researcher, shipment_tracer, defect_handler) — but it spawns them across three separate turns, one per response. Total time: ~90 seconds.
How should the coordinator emit the calls so the three subagents run in parallel?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
The coordinator achieves parallelism by emitting multiple Task tool calls in a single response. The SDK executes them concurrently. Spawning across separate turns serializes the work — each turn waits for the previous subagent to return before the next is spawned. For independent subtasks (different concerns in the same email), this is pure latency loss with no compensating benefit.
This is the genuinely tempting wrong answer because sequential ordering is right for some workflows — the synthesis subagent can't run before the searcher returns, the categorizer needs the metadata first. But the three concerns in this email (billing, shipping, defect) are independent — none depends on the others' output. Treating independent subtasks sequentially is a category error: the right rule is "sequence when there are dependencies; parallelize when there aren't." Defaulting to sequential is the safe-feeling but wrong choice.
There's no parallel: true flag because parallelism isn't a property of the coordinator — it's a property of how tool calls are emitted. Reaching for fabricated configuration options is a common pattern when the actual mechanism is misunderstood.
Routing subagents to different endpoints adds operational complexity (rate limits, observability, billing) without solving the actual problem. The SDK handles concurrency natively when you emit multiple Task calls together.