When should an AI agent use async tool calling instead of synchronous tool calls in 2026?

Use async tool calling only when useful model work can continue independently while your application owns the slow job. OpenAI's Responses API lets the model keep generating after it calls a function or custom tool marked async: true, instead of blocking on that tool's result. That is the entire benefit — it is not a general performance switch. Correlate the eventual result back to its call by call_id, keep cancellation, compensation, and relevance decisions in your application rather than the model, and treat mid-turn steering as queued input that never rolls back tool work already started. This is scoped to documented GPT-6 Astra Responses API behavior.

Async tool calling: continue the turn, not the job

OpenAI documents async tool calling as letting “the model continue working after it calls a tool, without waiting for that tool's result,” so an application can “start slow lookup requests early, answer independent parts of a request, and provide results when your application has them.” A tool definition opts in with async: true, and the corresponding call item in response.output carries that same flag. When the job finishes, you send the output back in a later Responses request, matched to its call by the original call_id — function_call items pair with function_call_output, and custom_tool_call items pair with custom_tool_call_output.

Your application still executes the tool. OpenAI is explicit that “async tools don't move execution to OpenAI or manage your background jobs” — starting the job, tracking it, and delivering the result at the right time all remain your application's responsibility. This is the same posture as keeping a realtime voice agent responsive when tools are slow: the slow work runs on its own track, and the caller decides how and when a result rejoins the conversation.

What async tool calling does not do

Async execution applies to function and custom tools your application runs — the guide states it does not apply to hosted built-in tools. It also warns not to combine async tools with parallel tool calls in Multi-agent mode. Neither restriction is an implementation detail you can design around; both bound where the feature applies at all. A documented wait_for_tasks-style custom tool pattern lets the model explicitly choose when it needs a pending result, backed by a task_handle registry your application maintains for the life of the conversation — including handles for tasks that have already completed.

Mid-turn steering is queued input, not a rollback

Mid-turn steering solves a different problem: letting a caller “add requirements or change direction without waiting for a response to finish.” A caller sends a response.steer event over the same WebSocket connection after response.created, carrying previous_response_id and an input string or message array. The API acknowledges with response.steer.accepted— but OpenAI is explicit that “acceptance means the input is queued, not that the model has acted on it.” The server finishes the current output item and any hosted tool work already running, then automatically creates a new response that incorporates the update.

When to actually reach for async tool calling

This is Bonfire implementation guidance, not a documented OpenAI policy: reach for async tool calling when you can name the independent model work that fills the wait — answering another part of the request, calling a second tool, or drafting text that doesn't depend on the pending result. If there is no such work, a synchronous call is simpler and gives up nothing. Either way, build the same three things your application already owns for any tool result that can arrive late or get superseded: a stable call_id-keyed record of what was asked for, an explicit relevance check before that result is delivered back to the model, and a cancellation or compensation path for a job whose result you decide not to use. The same intent, side-effect, and acknowledgement separation that makes a tool call idempotent is what keeps a late or superseded async result from causing a second side effect instead of just a wasted one.

None of this is a substitute for the retry, cost, and observability discipline the rest of an agent harness needs — it is the boundary decision that determines whether a slow tool call should even be asynchronous in the first place, consistent with the AgentOps posture of keeping consequential decisions outside the model.