When should a ReAct agent dispatch several tool calls in one action step?

## What fanning out actually buys A ReAct turn is expensive in two currencies. There is the model call — latency to first token plus generation, on every step — and there is the tool call itself. Sequential dispatch pays both, per tool, in series: five lookups means five model round-trips and five tool latencies stacked end to end. Issuing all five in one action step collapses that to one model round-trip and, if the runtime executes them concurrently, roughly the wall-clock of the slowest call. On a fan-out of five reads against a service with a 200 ms tail, this is the difference between a few seconds and a few hundred milliseconds, and it removes four rounds of generated reasoning tokens. On an agent doing dozens of independent lookups per task, it is the difference between usable and abandoned. ## The dependency test Calls can go together when none of them needs another's result to be *formed*. Five `get_stock_level` calls, one per SKU, qualify: the arguments were all knowable before any call ran. Reading three unrelated config files qualifies. Querying two independent services for a status qualifies. The opposite is a chain: look up a customer to get their account id, then read that account's balance. The second call's arguments literally do not exist until the first returns. This is not a limitation of parallel dispatch — it is inherent to the ReAct shape, where the next thought is conditioned on the observation. Trying to fake it (guessing the id and issuing both) is how agents produce confidently wrong work. A subtler dependency is *order sensitivity without argument dependency*. Two calls may both be formable up front and still be wrong to interleave, because one changes what the other observes. That is really the write case. ## Why writes are different Parallel writes fail in ways parallel reads do not. **No ordering.** Concurrent calls complete in whatever order the network and the service decide. If the outcome depends on order — two updates to the same record, a create and its dependent update — you have a race with no arbiter. **Partial failure with no rollback.** Five writes, three succeed, one times out, one is rejected. There is no transaction spanning them, so you are left in a state no one designed, and the agent must now reason about a mixed outcome. Sequential dispatch does not eliminate partial failure, but it makes the failure point unambiguous and lets the loop stop at the first one. **Retry hazard.** Recovery from a timeout means resending, and a timeout does not tell you whether the write landed. Without idempotency keys, a retried parallel write can double-apply. **Shared-resource contention.** Simultaneous writes are exactly what triggers lock contention, deadlocks and per-key rate limits — the failures that only appear under concurrency, and only in production. The practical rule: parallelise reads freely, serialise writes by default, and allow parallel writes only when each one is idempotent and touches a disjoint key — five per-SKU cache entries, say, rather than five ledger entries. ## Fan-out is a runtime concern, not a prompt one You can ask the model to be restrained about how many calls it issues, and it will mostly comply, and then one day it will not. Bound it in code: a maximum number of calls accepted per action step, a semaphore capping in-flight concurrency, and per-tool limits for anything backed by a rate-limited dependency. An agent that fans out forty calls against an internal API is a self-inflicted load test, and the blast radius grows with every user running the agent at once. The same reasoning applies to cost. Fan-out multiplies tool-side spend within a single step, where a per-step review would have caught it. ## Reporting a batch honestly When several calls go out together, each result must come back attributable to the call that produced it — a stable identifier per dispatched call — so that "three succeeded, one timed out, one was rejected" is representable rather than collapsing into one blurred blob. Losing that attribution is the most common implementation bug in fan-out, and it turns a recoverable partial failure into an agent that cannot tell which SKU it failed to price. ## Judgement, honestly stated There is no universal fan-out policy. It depends on how expensive your tools are, how tolerant your downstreams are, and how much a wrong-order side effect costs in your domain. The defensible position in an interview is a *rule* with a *reason*: reads fan out, writes serialise unless proven idempotent, concurrency is capped in the runtime, and results stay individually attributable. Candidates who answer "parallelise everything, it's faster" have not operated an agent against a system that can be damaged.