OpenAI Multi-Agent Calls: Drawing the Execution Line

A beta multi-agent response can contain two similar-looking call types with different execution owners:

• OpenAI executes hosted multi_agent_call collaboration actions.
• Your application executes developer-defined function_call items and returns matching outputs.

Those rules apply regardless of which agent produced the item. The item type determines the handling path: applications must not execute multi_agent_call items, but must execute developer-defined function_call items (multi-agent guide).

This article maps that documented boundary across HTTP and WebSocket. It is based on documentation retrieved October 20, 2026; no requests or latency tests were performed.

Enablement and participants

Enable the capability with multi_agent.enabled. Raw HTTP requests and WebSocket connections must also include the beta opt-in header below. For HTTP through the beta SDK, the guide documents passing responses_multi_agent=v1 through the betas argument instead. Item schemas may change while the capability remains in beta (multi-agent guide).

OpenAI-Beta: responses_multi_agent=v1

The documented participants are:

• Root agent: Named /root. It may create subagents and is responsible for synthesizing their results into the final response.
• Subagents: Share the request’s model and available tools.
• Responses API: Runs the agent workflow and executes hosted collaboration actions.
• Application: Executes developer-defined functions and returns their outputs.
• HTTP or WebSocket client: Carries those function outputs back to the API.

Setting multi_agent.enabled makes the root eligible to spawn a tree of subagents. It does not guarantee that subagents will be created or that work will run concurrently (multi-agent guide).

Execution ownership

A multi_agent_call records a hosted collaboration action, such as spawn_agent. The application must not execute the item or send back a result. The Responses API performs the action and returns the corresponding multi_agent_call_output (multi-agent guide).

A function_call crosses the opposite boundary. Any agent in the tree may emit one, but the application must perform the operation and submit a matching function_call_output (multi-agent guide). Responses represents calls and outputs as distinct items correlated through call_id (migration guide).

The response may also contain an agent_message, which the guide defines as an encrypted message carried from one agent to another. It is not a developer-function request. The word “encrypted” should not be extended into security guarantees that the documentation does not make (multi-agent guide).

The bounded sequence

The documented flow can be represented without inferring internal planning or extra lifecycle states:

Application             Responses API             Root and subagents
    |                         |                           |
    |-- create response ----->|                           |
    |   multi_agent.enabled   |-- run root ------------->|
    |                         |<-- multi_agent_call ------|
    |                         |-- execute hosted action ->|
    |                         |-- run subagent(s) ------->|
    |                         |<-- results/messages ------|
    |                         |                           |
    |                         |<-- function_call ---------|
    |<-- function_call -------|                           |
    |-- execute function -----|   outside OpenAI          |
    |-- return output ------->|                           |
    |                         |-- resume waiting agent -->|
    |                         |-- root synthesizes ------>|
    |<-- final response ------|                           |

For example, imagine a subagent requests a developer-defined function that reads a homelab inventory. The API can emit the function_call, but it does not thereby gain or run that application implementation. Your service performs the permitted lookup and returns the result. By contrast, if the response contains a hosted collaboration action used to coordinate agents, your service observes rather than executes it.

HTTP: continue with a new request

Over HTTP, the response completes once every active agent has either finished or paused while waiting for a client-executed function. The application then executes all outstanding function calls and submits their outputs in a new Responses API request, allowing paused agents to resume (multi-agent guide).

The application-side sequence is:

1. Collect outstanding function_call items.
2. Validate the function names and arguments.
3. Execute the permitted application functions.
4. Create matching function_call_output items using the correct call_id.
5. Submit those outputs in a continuation request.

A single multi-agent run may therefore span multiple Responses API requests, although the documentation does not say that every run will do so (multi-agent guide).

WebSocket: inject into the active response

WebSocket preserves the same ownership boundary but changes the return path:

Agent -> function_call
Responses API -> WebSocket client
Application -> execute function
Application -> response.inject(function_call_output)
Responses API -> resume waiting agent
Root agent -> final response

The application sends each result to the active response with a response.inject event. The waiting agent can resume without waiting for the complete multi-agent response to finish (multi-agent guide).

HTTP and WebSocket expose the same documented multi-agent capabilities. OpenAI recommends WebSocket for tool-heavy or long-running workflows because its persistent connection can reduce continuation overhead. That is documentation guidance, not a measured or guaranteed advantage for a particular workload (multi-agent guide).

Separate API concerns

Authentication and request IDs

Responses requests use HTTP Bearer authentication with an API key or short-lived workload-identity token. API keys should not be exposed in browser or application client-side code (API overview).

The API returns an x-request-id for troubleshooting. Callers may also explicitly supply a unique X-Client-Request-Id; it is not added automatically (API overview). These identifiers trace API requests, not individual agents, and do not change function ownership.

Background mode

Setting background: true starts asynchronous response processing that an application can poll (background mode guide). Multi-agent mode has its own enablement field, multi_agent.enabled. The supplied documentation treats these as separate options and does not identify background mode as a multi-agent prerequisite.

Current beta constraints

With multi-agent mode enabled, /responses/compact, reasoning.summary, and max_tool_calls are unsupported. Automatic server-side compaction is implicitly enabled, even without an explicit context_management configuration. These constraints—and the item schemas—may change during the beta (multi-agent guide).

The integration decision ultimately follows the item: observe hosted collaboration items, but dispatch developer-defined function calls to application code. Return those results through an HTTP continuation request or, for an active WebSocket response, through response.inject.

Sources and further reading

• https://developers.openai.com/api/docs/guides/responses-multi-agent
• https://developers.openai.com/api/docs/guides/migrate-to-responses
• https://developers.openai.com/api/reference/overview
• https://developers.openai.com/api/docs/guides/background