When a Tool Call Takes Ten Minutes, What Does Your Agent Do

With the GPT-6 Astra release on September 3, 2026, OpenAI shipped asynchronous tool calling in its Responses API: set async: true on a function or custom tool and the model can keep working after it issues the call, before your application returns the output. That is the first standard, non-realtime frontier API to let a model proceed while a client-side tool is still running; Google already documents the behaviour, but only in its realtime Live API. This page records what each of three vendors documents for the same situation, and what each one leaves out.

It is a different question from the one in our post on synchronous versus asynchronous agent workflows. That post is about working modes: whether a whole agent run happens in the foreground or in the background. This one is about a single tool call inside a turn, and whether the API lets the model do anything else while it waits.

Each row is one API surface. A client tool is a function your application runs; the vendor’s hosted tools, which run on the vendor’s side, are excluded because you never wait on them. The three columns answer the question three ways: can the model keep generating while your tool runs, how does a late result get back into the conversation, and what does the documentation say about time limits.

The headline is the first column. In the standard, non-realtime API, one vendor lets the model proceed while your tool runs, one forbids it by message-ordering rule, and one does not say. The second column matters just as much for anyone writing the loop: all three reattach by an identifier, but only OpenAI’s identifier is allowed to arrive several turns later.

OpenAI’s async tool calling guide is short and specific. A normal function call pauses the model’s turn until the tool responds. Mark the tool async and the model can issue the call and carry on. The guide’s three use cases are kicking off a slow lookup before it is needed, answering whatever part of the request does not depend on it, and feeding the result in once the application has it. The response can contain both the async call and an answer.

The sentence that stops the feature being misread is OpenAI’s own: “Async tools don’t move execution to OpenAI or manage your background jobs.” Your application still runs the tool, still holds the job, and still has to send the output back in a later request under the original call ID. If other turns happen first, you continue from the latest response ID and keep the original call ID.

The compatibility notes are the fences. Async applies to function and custom tools the application runs, not to hosted built-in tools. It is not to be configured for programmatic tool calling, and in multi-agent mode it is not to be combined with parallel tool calls. It requires GPT-6 Astra or a later model, which we covered in our Astra launch guide.

Anthropic’s Messages API has no equivalent flag, and its handle-tool-calls documentation makes the ordering explicit: “Tool result blocks must immediately follow their corresponding tool use blocks in the message history.” Nothing may sit between the two messages, and within the user message the results come first and any text after. A response that calls tools ends with a tool_use stop reason. The model is not running while you wait.

That design has a consequence people miss. Because the turn has ended, there is no API clock on your tool. You can take ten minutes or ten days before sending the next message, as long as that message begins with a result for every call. The parallel tool use page says execution order is your choice, that all results return together in one user message, and that a call you decline to run should get an error result rather than be omitted. An agent that wants to do other work meanwhile does it outside the model, then resumes.

Google’s function calling page for the standard Gemini API documents parallel calls within a turn and compositional calls across turns, and in stateless mode requires the full history, including thought and function_call steps, to be resent exactly as received. It says nothing about the model proceeding before a function result arrives. That cell is marked not documented, which is the only honest reading.

The Live API tools page is a different story. It says that by default a Live session stops and waits for each function’s result before continuing, then offers an escape: declare a function with a NON_BLOCKING behaviour and the conversation continues while it runs. The function response then carries a scheduling value. INTERRUPT makes the model report the result at once, WHEN_IDLE waits until it has finished what it is doing, and SILENT stores the result for later use without comment.

That is the richest deferral contract of the three, because it lets the application say not just that a result is late but how the model should treat it when it lands. The catch is the support table on the same page. As read on September 4, 2026, it lists Gemini 2.5 Flash Live Preview as supporting synchronous and asynchronous function calling, and Gemini 3.1 Flash Live Preview as synchronous only. The newer model, on that page, has less of the feature.

Three adjacent features get called asynchronous and answer a different question. Background mode, in OpenAI’s Responses API, generates the whole response asynchronously so a client can poll or resume a stream; the guide says it was built for tasks that take several minutes, and it stores response data for roughly ten minutes to support polling. The tool calls inside a background response behave exactly as they would in the foreground.

Deferred tool loading, which both OpenAI and Anthropic offer under names like tool search and defer_loading, delays putting a tool’s schema into the context until the model needs it. It saves input tokens. It has no effect on how long a call may take. And programmatic tool calling, on both platforms, moves the loop into code the model writes, which changes how many round trips you pay for but, on Anthropic’s documentation, adds a four-minute limit rather than removing one.

Our function calling guide across the three vendors covers the ordinary round trip. This page is only about the case where that round trip cannot close in time.

The routes below follow from the documentation and nothing else. None of them depends on a provider managing your job, because on every one of these APIs the job is yours.

The pattern that survives all three vendors is the ticket: a fast result that says the work has started, plus a tool to check on it. It is less elegant than OpenAI’s async flag and it works on Gemini’s standard endpoint, where nothing else is documented. Our AI transformation practice builds agent loops that way first and adopts a vendor’s deferral feature only where the documentation supports it.