Ten at a Time

An orchestrator receives 200 independent subtasks and launches a subagent for every one immediately. Most return 429 rate-limit errors, database connections are exhausted, and end-to-end latency is worse than the old sequential version. What is the right fix?

Split the 200 subtasks into 400 finer subtasks so each individual call is cheaper and faster

Run the fan-out through a bounded worker pool that keeps a fixed number of subagents in flight

Keep launching all 200 at once but retry each rate-limited subagent immediately until it finally succeeds

Give each subagent a smaller token budget so 200 concurrent calls fit under the account limit