On September 10, OpenAI did something quieter than a model launch: it handed every developer the same managed infrastructure that runs Codex and ChatGPT for Work, wrapped behind a single API call. No orchestration library to maintain. No custom context-compaction logic. No state persistence wiring. Just a POST to https://api.openai.com/v1/agents/sessions and the harness is someone else's problem.
That is genuinely different from where things stood six months ago. But it comes with a constraint buried in the docs that most coverage skipped - and if your team is outside the US or in a regulated industry, it is probably the first thing you need to read.
What the managed Agents API actually changes
The architectural significance here is not a new model. It is a shift in where execution infrastructure lives. Teams building long-running agentic workflows previously had to maintain their own context compaction, tool orchestration, subagent coordination, and state persistence - complexity this API absorbs.
The API organizes around four primitives: an agent (model, instructions, tools, MCP servers), an environment (optional sandbox for file access and command execution), a session (a durable instance that persists state across turns), and events and items (inputs sent to the agent and outputs it returns).
OpenAI runs the agent loop on its own infrastructure - coordinating model calls, tool use, and context - while you supply the tools, pick the execution environment, and pay only for the tokens and tools your agents consume, with no additional fee for the API itself.
On execution environments, you get three choices. Developers run the agent's compute in an OpenAI-managed sandbox, their own infrastructure, or a partner sandbox. The OpenAI-managed path is the obvious starting point. It is the same sandboxing behind Codex.
The data residency problem most teams are about to hit
This is the sentence in the docs that matters most for enterprise adoption: data stays US-only, and Zero Data Retention is unsupported.
The US-only data residency restriction is a hard blocker for regulated industries and non-US enterprises. Running a self-hosted sandbox does not change the API's residency classification - the control plane stays in the US regardless of where compute executes.
That is a meaningful gap. You can point the agent's compute at your own infrastructure, but the session state and orchestration still route through OpenAI's US control plane. For teams under GDPR, Australian Privacy Act, or sector-specific rules like HIPAA and FedRAMP, this is not a configuration problem - it requires a different architecture entirely.
The workaround most teams will land on: keep the agent loop self-hosted, treat the Agents API as a reference implementation to learn from, and wait for regional expansion. That is a reasonable bet. OpenAI expanded Azure data residency options in 2025; the same pressure will push the Agents API toward EU and APAC regions eventually.
| Capability | Agents API (public beta) | Self-hosted harness |
|---|---|---|
| Context compaction | Managed by OpenAI | You build and tune |
| Durable sessions | Built-in | Requires state store |
| MCP server support | Native | Depends on framework |
| Subagent coordination | Built-in | Custom logic |
| Data residency | US-only | Your choice |
| Zero Data Retention | Not supported | Possible |
| Extra API fee | None | Infrastructure cost |
Why Docusign going MCP-native this month matters here
Docusign announced it will open its Model Context Protocol Server to every AI agent on September 30. That might read like a separate news item, but it illustrates exactly what the Agents API is designed to consume.
The official MCP server lets AI agents send envelopes, check signing status, query agreements through Navigator, and trigger Maestro workflows using the Model Context Protocol.
The server is built for the enterprise, with account-level admin controls, global multi-region infrastructure, and multilingual support. Agents draw on the full context of past negotiations, accepted terms, clauses, and company policy through Iris, Docusign's AI engine, across Intelligent Agreement Management and CLM workflows.
Docusign processes over one billion agreements annually. Most developers who integrate with Docusign still write custom REST API code to handle envelope creation, recipient routing, and status polling. An MCP server flips that: instead of hand-rolled REST integration, any MCP-compatible agent - including one running on the OpenAI Agents API - can call those capabilities with no custom adapter code.
This is the pattern solidifying in September 2026. Vendors expose their data through MCP. Agents connect via a managed harness. The integration tax starts to look more like a standard connection than a six-week project. Since Anthropic released MCP in November 2024, the ecosystem has grown to over 17,000 publicly listed servers. OpenAI and Google DeepMind adopted it in early 2025, and it was donated to the Linux Foundation's Agentic AI Foundation in December 2025, cementing its status as the universal interface between AI and the tools developers actually use.
A teammate like Beagle, living in Slack, is already on the receiving end of this pattern - when a connected MCP server can answer a contract question, the agent can surface it in-thread without anyone switching tabs.
Beagle in action#deals, 11:02amWhat teams should do right now
The Agents API is genuinely worth experimenting with - especially for internal tooling where US data residency is not a problem. Start with read-only agents: give it a few MCP servers, a durable session, and a task that takes more than one turn to complete. Watch where the observability gaps appear before you commit to it in production.
If you are outside the US or under data sovereignty requirements: document the gap now, track the roadmap, and design your architecture so the harness can be swapped. The managed-harness pattern is where this is going; the residency constraint is a timing problem, not a direction problem.
And for anyone building workflows that touch contracts: the Docusign MCP going GA on September 30 is worth a one-afternoon integration test. A billion agreements a year running through manual REST calls is exactly the kind of friction that a standard protocol eliminates.
OpenAI Agents API public beta: common questions
What is the OpenAI Agents API?
The OpenAI Agents API is a managed service, in public beta since September 10, 2026, that gives developers access to the same Codex harness behind ChatGPT for Work. It handles session state, context compaction, tool orchestration, and subagent coordination. You pay for tokens and tools only - no additional API fee.
How does the Agents API handle long-running agents?
Durable sessions persist agent state across turns. OpenAI manages compaction and recovery, so agents can run reliably for days without custom state-persistence logic on your end. Progress streams back to your application as the agent works.
Can the Agents API connect to MCP servers?
Yes. MCP server connections are a native primitive of the API. You define an agent with a list of MCP servers and tools; the harness calls them during execution. This means any MCP-compatible server - Docusign, Notion, Linear, GitHub, and thousands more - is directly accessible to agents built on the API.
Is the OpenAI Agents API available outside the United States?
Not yet, as of public beta. Data residency is US-only, and Zero Data Retention is not supported. The control plane stays in the US even if you run agent compute on your own infrastructure. This is a hard blocker for GDPR-regulated teams and non-US enterprises under data sovereignty requirements.
What is the difference between the Agents API and building your own agent loop?
The Agents API replaces the scaffolding teams typically build themselves: context compaction, durable sessions, tool scheduling, and subagent coordination are all handled by OpenAI. The tradeoff is that execution observability shifts inside OpenAI's infrastructure, and you lose control over data residency. For teams where those constraints are acceptable, it eliminates a significant category of engineering overhead.