Teams leaving Agent Builder must decide whether OpenAI or their own code runs the agent loop

A comparison of the four options published on dev.to reduces the choice to one question: who runs the agent loop ^[1]. Its author says to weigh loop, compute, state, cost and data requirements, not product names ^[20].

On the Responses API the loop is application code ^[2]. Hosted tools such as web search, file search, code interpreter and remote MCP can take several steps inside a single request ^[7]. Once a function tool is involved, the comparison documents this cycle ^[8]:

1. Send `POST /v1/responses`. 2. Find the returned `function_call` item. 3. Run the function in the application. 4. Send `function_call_output` with the same `call_id`. 5. Repeat until the model returns final output.

Long conversations add state work. The team stores history, can switch off default response storage with `store: false`, chains turns with `previous_response_id`, and compacts context through `context_management` and `compact_threshold` ^[9]. Timeouts, retries and approval flows for tool calls are also its job ^[9].

For the Agents SDK, the comparison adds that Sandbox Agents can run commands in a local Unix environment, in Docker or in a hosted provider's workspace while the harness stays on the team's own infrastructure ^[12].

On the Agents API, OpenAI also handles orchestration, context compaction and recovery, and its managed harness supports subagents, tool search and programmatic tool calls ^[13]. A persistent session starts with a POST to `/v1/agents/sessions` and the header `OpenAI-Beta: agents=v1` ^[15]. The example session sets `"environment": {"type": "none"}`. Switching the type to `"openai_hosted"` gives the whole session a sandbox ^[15][18]. OpenAI calls remote MCP servers directly ^[14].

Function tools still run in the application. When a session returns a `function_call` in `required_actions`, the application executes it and sends an `agent.session.input.tool_result` event carrying the `turn_id` and `call_id` ^[16]. That handshake is step 4 of the Responses loop with a turn ID added ^[8][16]. OpenAI takes over the history and compaction work from the Responses list, plus recovery ^[9][13].

On November 30 the Agents API will have been in public beta for 81 days, and computer use will have been part of it for 62 ^[1][2]. Teams moving from Agent Builder to the Agents API swap a shutdown date for a beta header ^[5][15].

Model choice is narrower too. The Agents API documentation examples use `gpt-6-astra`, and the comparison advises confirming that another model is accepted before switching ^[17]. The comparison's Responses API example runs `gpt-6.1-sol` at low reasoning effort ^[19].

I think the Agents API removes the most code for agents that lean on hosted tools and call few functions of their own, as long as the team will run production work on a beta ^[3][13][16].