What does OpenAI's Agents API actually manage?
AI Architect
Key takeaways
- OpenAI's 10 September 2026 changelog says the Agents API public beta handles session orchestration, context compaction, recovery, and durable sessions.
- OpenAI's Agents guide says the hosted Agents API runs the Codex harness, while your application connects tools and chooses where execution happens.
- OpenAI's architecture page says your application server still handles function tools and manages environment lifecycle when you provide the environment.
- OpenAI's own comparison table separates the Agents API, Codex SDK, and Responses API by who operates the harness and session state.
- Anthropic's permission policy docs describe per-call server evaluation explicitly, which is a different claim from OpenAI's hosted-runtime boundary.
OpenAI’s 10 September 2026 changelog announces the Agents API in public beta with a specific claim: OpenAI handles “session orchestration, context compaction, and recovery” and gives you “durable sessions” plus the option to connect your own tools and MCP servers. The Agents guide and architecture page make the other half explicit. OpenAI runs the hosted Codex harness, but your application still owns tool integrations and the choice of execution environment. That is a useful boundary. It is also narrower than “managed agent runtime” tends to sound in launch discourse.
What does OpenAI’s Agents API say it manages?
OpenAI’s wording is unusually concrete once you read the three pages together. The changelog says the Agents API public beta handles session orchestration, context compaction, recovery, and durable sessions. The overview page sharpens that into product language: “OpenAI runs the Codex harness and manages orchestration, context compaction, and durable sessions.” The architecture page then defines the harness as the OpenAI-hosted Codex instance that “runs the model and tool loop and maintains the agent’s session.”
That combination matters because it separates hosted runtime work from model access alone. This is more than a thin wrapper over a responses endpoint. It is a statement that OpenAI owns the control plane for an agent session after you submit work, including session continuity across turns and the loop that keeps calling tools until the job resolves. If your main pain today is operating that loop reliably, the hosted Agents API is aimed directly at that burden.
OpenAI's hosted boundary for the Agents API
Show as text
| # | Layer | Note |
|---|---|---|
| 1 | Hosted Codex harness | OpenAI runs the model and tool loop. |
| 2 | Orchestration and context compaction | Session control-plane work stays hosted. |
| 3 | Durable session state and recovery | Sessions continue across turns. |
| · | OpenAI responsibility ends here (breakpoint) | |
| 4 | Tool integrations | Your handlers still return results. |
| 5 | Execution environment choice | Hosted or self-hosted is your call. |
| 6 | Sandbox lifecycle when you provide it | Provision, reconnect, stop, preserve files. |
What does your application still own under OpenAI’s Agents API?
The same docs are clear that hosting the harness does not mean hosting your whole application. The overview page says “You build the surrounding application, connect tools, and choose where execution happens.” OpenAI’s own comparison table puts the line even more starkly: under the hosted Agents API, your side still includes “your application, tool integrations, and choice of execution environment.”
The architecture guide names three pieces: harness, environment, and application server. The application server submits tasks, receives events, and handles function tools. When you provide the environment, your code also owns its lifecycle, including provisioning, reconnection, shutdown, and file preservation. That means the hosted runtime removes orchestration work without removing side effects. A tool that spends money, changes production state, or sends a message still crosses back into systems you operate, which is where the risk and the review path still belong.
A function tool call in the hosted Agents API
Show as text
| # | From | To | Message |
|---|---|---|---|
| 1 | Your application | OpenAI harness | Submit task or continue session. Session state stays on OpenAI. |
| 2 | OpenAI harness | Your application | Stream event requesting a function tool. Your handler receives the call. |
| 3 | Your application | OpenAI harness | Return tool result or environment output. Your infrastructure did the work. |
| 4 | OpenAI harness | Your application | Continue orchestration and update session. Harness keeps the loop moving. |
How does OpenAI’s boundary compare with Codex SDK and Responses API?
OpenAI’s own table is the cleanest way to read the product split. The hosted Agents API is for “a new agent application with a managed runtime.” The Codex SDK is for running the Codex harness “in infrastructure you operate.” The Responses API is for direct model integrations where you own the agent loop yourself. Same family, three different answers to who operates the runtime.
That distinction is more durable than the launch branding. If you want session state, orchestration, and recovery hosted, the Agents API is the fit. If you want the Codex harness behavior but need it inside your own estate, the SDK is the closer match. If you mainly need model calls plus hosted capabilities, the Responses API keeps the fewest moving parts but asks you to assemble the loop yourself. This site’s earlier comparison of prompt-cache economics makes the same larger point in a different layer: cost and control move together more often than product names suggest.
Does OpenAI’s hosted Agents API decide tool permissions for you?
In the cited OpenAI Agents API pages, no. The OpenAI language is about harness
ownership, session state, environments, tools, streaming, and webhooks. It is
describing an operational boundary. Anthropic’s
permission policy page,
by contrast, says auto makes the server “evaluate each call and run it,
deny it, or pause for your approval,” and the
release notes
say that evaluation lands on each agent.tool_use and agent.mcp_tool_use
event.
That difference is the new comparison worth carrying into architecture work. Managed orchestration and managed permissioning are not the same claim, even when both products sit under an “agents” label. Anthropic is explicit about server-side call evaluation. OpenAI, in these pages, is explicit about hosted harness operation. If your design depends on the permission boundary, read the vendor text as narrowly as it is written. The earlier Anthropic article on the intent channel is a good example of why that precision matters.
Should you choose OpenAI’s Agents API for a new agent?
My view is yes, when the part you want to stop owning is the runtime loop rather than the tool risk. OpenAI’s hosted boundary is honest enough that you can reason about it. The product is saying, in plain terms, that OpenAI will operate the harness while you keep the surrounding application and the systems that tools touch. That is a strong trade if your team has been spending time on session continuity, orchestration glue, and recovery code.
The mistake would be to hear “managed runtime” and assume the security ceiling moved with it. It did not, at least not in the three primary pages cited here. Keep high-consequence tools behind handlers you control, keep your execution environment choice intentional, and treat the hosted harness as an operational acceleration layer. If you need a refresher on the protocol trust boundary below that, the MCP mechanics piece is still the right companion read before you wire more tools into any hosted runtime.
Do this
Choose the right OpenAI agent runtime
Start with the ownership boundary, because every later integration problem is just that first decision resurfacing in a more expensive form.
Decide whether you want to operate the harness at all
Pick the Agents API when you want OpenAI to run the Codex harness and keep durable session state. Pick the Codex SDK when you want the same harness pattern inside infrastructure you operate.
List every tool that will cross back into your systems
Function tools, MCP connections, plugins, and any sandbox your product provides all sit on your side of the boundary. If that list is long, your application still owns a meaningful part of the runtime.
Choose the execution environment before you write tool code
OpenAI's docs separate the hosted harness from the environment on purpose. Decide early whether tool work runs in OpenAI-hosted sandboxes, your own compute, or a provider connection, because the lifecycle and file model change with that choice.
Keep approval and policy logic close to the tools that can cause damage
The hosted Agents API removes orchestration work. It does not remove the need to gate side effects. Put spending, messaging, and production-change tools behind handlers or review paths you control.
Use streaming or webhooks as operational interfaces
The architecture guide says your handlers can retrieve results, run function tools, and manage self-hosted environments. Treat those channels as runtime interfaces that keep the system healthy. They also power the progress feed users see.
Compare the managed boundary with another vendor before assuming equivalence
Anthropic's permission policy docs make a per-call evaluation claim that OpenAI's cited Agents API pages do not. If a requirement depends on that distinction, verify it in the primary docs before you build around the label managed.
Frequently asked questions
- Does the Agents API run the model and tool loop for me?
- Yes. OpenAI's architecture guide defines the harness as the OpenAI-hosted Codex instance that runs the model and tool loop and maintains the agent's session. That is the main thing you stop operating yourself when you choose the hosted Agents API.
- Do I still have to host my own tools with the Agents API?
- Usually, yes. OpenAI's architecture page says your application server handles function tools, and the overview page says your application still owns tool integrations and the choice of execution environment.
- Does OpenAI's Agents API pick the execution environment for every tool call?
- No. The documentation says you can use OpenAI-hosted sandboxes or connect a sandbox from your own infrastructure or a supported provider. The environment choice stays with the integrator even when the harness is hosted.
- Is the Agents API the same thing as the Codex SDK?
- No. OpenAI's comparison table says the Agents API hosts the Codex harness and durable session state, while the Codex SDK runs the harness in your own environment. The SDK keeps more control and more operational burden.
- Does a managed harness mean OpenAI is deciding which tool calls are safe?
- The cited OpenAI Agents API pages do not make that claim. They talk about orchestration, session state, tools, and environments. Anthropic's permission policy page does make an explicit per-call evaluation claim, which is why the difference matters.