Tool-call concurrency: decide execution order before batching actions

A batch is not an execution schedule

An agent requests a stock lookup and a reservation for the same part in one response. If the reservation needs information from the lookup, the application must wait for that result before constructing or validating the reservation request. A separate pair of supplier-directory lookups may be ready to run together. The useful distinction is whether the calls depend on each other or can change the same state, not how many the model requested.

Claude's Parallel tool use documentation makes the scheduling boundary explicit: multiple tool_use blocks can appear in one assistant turn, and the API does not prescribe their execution order. The application can run them concurrently, sequentially or in a combination suited to its tools. Independent read-only operations are usually candidates for parallel execution; side effects, shared state and ordering requirements can favor sequencing. This is guidance, not a safety certification for every read or a rule to serialize every write.[1]

OpenAI's function-calling guide likewise tells applications to handle zero, one or multiple calls and return their results. Its illustrated execution loop runs calls serially; that example does not establish how every integration runs them. Inspect the executor, the application code that starts tools and collects their results, to learn whether it runs calls together or in sequence.[2]

What the zero-or-one controls actually constrain

The exactly-one setting has support limits. Claude's captured Define tools page says manual extended thinking rejects tool_choice types any and tool. Adaptive thinking permits forced use on supporting models, but a forced call skips thinking. Other models listed in that page reject forcing regardless of thinking settings. Check the deployed model and settings before relying on exactly-one behavior; this is not a model-ranking recommendation.[4]

OpenAI's captured guide says that, on supported models beginning with GPT-5, functions can be called in parallel even when built-in tools are also available. Built-in tools cannot themselves join a parallel function-call batch. When a fine-tuned model calls multiple functions in one turn, strict mode is disabled for those calls. Strict mode concerns conformance to the declared input schema; it does not prevent competing changes to a record. These limits matter when deciding which tools and models can use a batch.[2]

These controls limit selections in one response. They can simplify the orchestration loop, but another turn, agent or client can still change the same record. Our analysis treats permission and protection against competing writes as separate requirements. A zero-or-one flag supplies neither.

Choose the schedule from the dependency, not the call count

• Establish the inputs and effects. Identify what each call reads or writes, whether its arguments are already known, and whether access and workload limits permit execution.
• Group only genuinely independent calls. Two permitted lookups of separate supplier records can run together if neither supplies the other's arguments. Their results may still come from different observation times rather than one coherent snapshot.
• Defer unresolved dependent calls. If reserve_stock needs a stock result or version that has not arrived, read first. After success, construct or validate the reservation against that result. Simply waiting to execute an already-generated request does not repair guessed or stale arguments.
• Define order for conflicting actions. For two writes to the same order, decide which business transition is allowed first and check its outcome before the next. A batch containing amend_order and cancel_order is not an instruction to execute both blindly; after cancellation, the amendment may no longer be valid.
• Check interference outside the agent. Determine whether other writers can change the relevant condition between steps, and what provider-enforced condition or conflict check governs acceptance.
• Return truthful outcomes. Keep skipped, failed, rejected, accepted and attempted-but-uncertain states distinct, using the applicable tool-result format. Reconcile an uncertain write through the existing authoritative system before considering a repeat.

This is an application decision procedure, not a new vendor execution rule. Two writes to truly separate records might be concurrent if their contracts permit it. Conversely, two reads may need sequencing or a common snapshot if the decision requires a consistent combined view. The relevant unit is the dependency and conflict scope—not the labels read and write alone.

Completed hypothetical: supplier lookups versus stock reservation

This example is fictional and unexecuted. An authorized purchasing assistant needs two independent supplier-directory records. Neither lookup writes state, and both requests' arguments are known. The assistant starts them together and matches each result to its original call: Supplier North offers collection; Supplier South offers delivery. It reports those observations without claiming a simultaneous snapshot or knowing which supplier has reservable stock. Concurrent reads meet this task's stated requirements.

Now assume the same assistant is authorized to reserve DEMO-PART-A only if stock is available. A proposed reserve_stock request relies on the result of read_stock for that part. The assistant does not launch them together: it first reads stock, receives an available result and then constructs the dependent reservation. If the read had failed, the reservation would remain unexecuted and be reported as skipped, not as a successful attempt.

Before the reservation reaches the provider, another buyer takes the last available unit. The assistant ran its steps in order, but stock changed between them. Assume this fictional provider checks current availability and creates the reservation as one indivisible operation: another buyer cannot intervene between that check and reservation. This is the assumed atomic check-and-reserve contract. The provider rejects the assistant's request because no stock remains. The assistant reports that rejection and no accepted reservation. Local sequencing alone could not have enforced the availability condition.

If the provider's atomic contract or equivalent control cannot be verified, the assistant cannot establish that the reservation enforces current availability. It defers that write while checking the existing contract, or uses an already authorized alternative with an adequate acceptance rule. An available read is not a reservation. The unresolved contract leads to a concrete decision to defer, not an invented success.

Local ordering is not global isolation

The stock example exposes a general distinction. Sequencing prevents this agent from starting its dependent write too early. It does not prevent another writer from changing the stock between the read and the write. A local mutex—a lock used by the application—helps only if its scope covers the relevant records and every relevant writer obeys it. A lock used by one agent cannot constrain a separate purchasing client that never participates.

For stock, look for an actual contract that checks the current condition and reserves atomically, or equivalent documented concurrency control. For order changes, a provider may instead expose a conditional version check that rejects an amendment against a changed order. These are possible mechanisms to verify, not capabilities established for any provider by the Claude or OpenAI documentation. A rejected condition must lead to a fresh decision, not a blind retry with the same stale assumptions.

Concurrency can shorten independent waiting, but may increase rate-limit pressure and complicate consistent reads and failure handling. Sequencing makes dependencies and error propagation clearer, but adds waiting and does not prevent other clients from intervening. No latency saving, cost reduction or correctness improvement was measured here. Choose a schedule that meets the task's requirements without unnecessary sequencing.

Match results to requests, then check the actual outcome

Result correlation means matching each tool's result to the request it answers. For ordinary Claude client calls, return one tool_result per tool_use, all together in the next user message, with tool_use_id matching the original call's id. That user message must immediately follow the assistant's tool-use message, and result blocks must precede text. If an unresolved server tool is also present, the user message must contain only tool_result blocks. An intentionally skipped call still receives a result with is_error: true and an explanation.[1][3]

Claude's computer/browser member batches are a specific exception to general scheduling freedom: execute them sequentially in response order and stop at the first failure. Use each tool's specified skipped-result text; member results also echo toolset_name and have narrower content rules. A generic independent-read argument does not override that toolset contract.[1][3]

In OpenAI Responses, associate a function_call_output with the original function_call using call_id. The response item's id is a different field. Do not transplant another API's field path or pair results merely by completion order: a faster supplier response must not be attributed to the wrong supplier.[2]

Correlation answers which request a result belongs to. It does not supply a business-operation identity or a documented duplicate-handling guarantee. Likewise, is_error: true can describe a deliberately unexecuted call or an execution error.[1][3] Our proposed outcome policy distinguishes them: an error after an attempted remote write may leave its effect uncertain. Use authoritative reconciliation before retry; formatting an error does not undo or disprove the effect.

What would change the scheduling decision?

• A documented toolset restriction can require sequencing even where calls otherwise appear independent. Verify the exact API, model, settings and result format in use.
• A real dependency or a required coherent snapshot changes two parallel-read candidates into a staged or consistency-controlled operation.
• A verified atomic condition-and-reserve or order-conflict contract can establish an acceptance rule that local sequencing alone cannot provide.
• Evidence that a shared lock covers all relevant writers changes its value; a lock limited to one session does not supply that evidence.
• Authoritative acceptance and duplicate-handling rules determine whether an uncertain write can be reconciled or safely repeated. Call identifiers alone do not answer that question.

Start independent, permitted work together. Obtain missing prerequisites before constructing dependent requests. For conflicting actions, define their order and check whether the provider can enforce the required condition despite other writers. Then report what the authoritative outcome establishes. Setting a smaller model batch does not replace any of those decisions.