OpenAI’s new Agents API lets you run the agent’s execution environment on your own infrastructure. It does not move the managed agent harness into your data centre. The current documentation says the API supports data residency only in the United States and is not eligible for Zero Data Retention—even with a self-hosted sandbox. For a German enterprise, this is the first adoption gate: approve the session-data boundary before connecting a private repository, warehouse or operational tool.
The useful change is managed orchestration, not an exemption from your data policy. A restricted pilot may reduce harness maintenance; a workload requiring EU-only session storage or ZDR should not enter this beta on the assumption that local compute satisfies those requirements.
What changed: the Codex harness becomes a managed API
On 10 September 2026, OpenAI introduced the Agents API in public beta. The announcement says it is available to all developers and lets applications use the harness and infrastructure behind Codex. Developers choose tools and execution environments; OpenAI operates the harness. This article reviews the announcement and technical documentation retrieved on 12 September, not a hands-on performance benchmark.
The managed capabilities include context compaction, tool search, programmatic tool calling and parallel subagents. These can remove implementation work from the application, but OpenAI’s descriptions of improved performance and efficiency are vendor claims, not independent evidence of lower cost or fewer production incidents.
The architecture documentation separates three components: the hosted harness that runs the model-and-tool loop and maintains the session; an optional environment for commands and files; and your application server, which submits work, receives events and handles function tools. An agent can also run without an environment when its configured remote tools and functions are sufficient.
This differs from merely choosing a stronger model in an existing orchestration stack. The application is delegating part of the runtime itself. Keep that decision separate from the model-level access and evaluation issues covered in GPT-6 Astra for enterprise.
Availability is not the same as a permitted data location
The Agents API overview is explicit: session state is retained so work can continue, sessions and published artifacts can be deleted, data residency is currently supported only in the United States, and ZDR is not supported. Selecting a self-hosted sandbox does not change ZDR eligibility.
OpenAI’s endpoint-specific data controls list application-state retention for /v1/agents as “until deleted” and mark the endpoint as not ZDR-eligible. They list no training use for that endpoint. These are different controls: “not used for training” does not mean “not stored,” and deleting a session is not a promise that every separate logging or downstream copy disappears at the same moment.
Do not import the residency properties of another OpenAI endpoint into this one. Likewise, a European sandbox partner or a Frankfurt-hosted virtual machine is not evidence that the managed session qualifies for European residency. Procurement needs the specific endpoint, data classes, retention behaviour and contracted processing arrangement.
This is not a finding that every German organisation is prohibited from using the API. It is a mismatch for workloads whose approved requirements demand EU-only session residency or ZDR. Counsel and the data-protection team must assess the actual transfer arrangements and legal obligations; this article provides engineering guidance, not legal advice. No date for European Agents API residency or ZDR availability is established by the sources reviewed here.
What actually runs inside a self-hosted environment
The self-hosted sandbox guide describes an executor, codex exec-server, running inside your environment. OpenAI’s harness requests commands; the executor runs shell commands, reads and writes files, and uses local MCP servers. It registers with an environment ID and restricted key, then receives commands and returns results over a WebSocket connection.
Connections are outbound. The documented required destinations include api.openai.com for registration and codex-cloud-environments.chatgpt.com for commands and results. Outbound initiation avoids opening an inbound listener, but it does not make the workflow offline or prevent data from leaving. Tool results returned to the managed harness are part of the boundary review.
The docs distinguish executor MCP connections, which originate inside your environment, from remote MCP connections, which originate from OpenAI’s service. That distinction changes firewall rules and the location where credentials and tool responses are handled. “Our MCP server is private” is insufficient unless you can describe which connection mode reaches it and what content is returned.
Your application owns provisioning, reconnection, shutdown and files that must survive for self-hosted execution. Managed session recovery does not remove those responsibilities. A connected environment is also not proof that the task succeeded: the architecture requires following the turn outcome, and warns that unavailable function handlers can leave an agent waiting for a result.
Pricing: no API surcharge does not mean free execution
OpenAI says there is no additional fee for using the Agents API itself. The overview says model usage is billed at the selected model’s API rates, OpenAI tools at their standard rates, and OpenAI-hosted sandboxes at standard container rates. Self-hosting leaves your own compute and operating costs with you.
For a concrete reference, the pricing documentation lists GPT-6 Astra Standard short-context prices of US$10 per million input tokens and US$50 per million output tokens, with separate cached-input and cache-write rates. Long-context prices differ. These are model prices, not a fixed price per completed agent task. Check the applicable tier, context category and tool charges before budgeting.
Evaluate a workload by accepted deliverable, including model calls, subagent work, sandbox time, external services and human review. Context compaction can make a long session manageable without making it cheap; parallel subagents can shorten elapsed time while increasing total work. The launch does not establish which trade-off wins on your tasks.
A deployment choice, not a blanket migration recommendation
Choose an OpenAI-hosted environment when approved data can enter the service and reducing sandbox operations matters more than custom local dependencies. Choose a self-hosted environment when you need controlled packages, private-network tools or a particular compute location—and separately accept the managed session boundary.
If the requirement is local orchestration with explicit control over persisted state, evaluate an application-managed runtime instead. That shifts context, retries, tool execution and recovery back to your team; it does not automatically make a cloud model call compliant with your data policy. The foundational n8n, LangGraph and custom-backend comparison explains this ownership trade-off. There is no reason to replace a stable bounded workflow solely because a managed harness is newly available.
For this beta, a useful first experiment is a read-only analysis of synthetic operational records. Keep real credentials and customer content out. Ask whether the session boundary, tool path and cleanup can be evidenced, then compare accepted outputs and operating effort against your existing runtime. That is a proposed test, not a claim that this integration has already been deployed for a client.
Procurement and pilot decision checklist
1. Approve the session boundary before the sandbox location
Record the endpoint, project, model, execution region, data classifications and retention owner. Mark prompts, command output, tool results and published artifacts separately. Pass only when the actual managed-service arrangement is approved; reject the pilot if “self-hosted” is the only residency evidence. Use the AI supplier control-plane pattern to make the approval an enforceable configuration rather than a procurement note.
2. Prove isolation and credential separation
OpenAI’s sandbox security guide warns that agent-generated code can access available files, credentials and network resources. Use isolated workloads and a restricted executor key; keep the broader application key outside the environment. Where possible, broker third-party credentials into approved requests rather than injecting secrets into the sandbox. Test denial of an unrelated workload’s files and an unapproved destination using synthetic fixtures.
3. Trace one tool result across the actual route
Identify whether each MCP runs through the executor or the hosted service. Capture a redacted example of what leaves the environment and what enters session state. Pass only when the integration owner can explain the complete path. A local source file is not a sufficient boundary if its contents are printed into a tool response.
4. Exercise connection loss and cleanup ownership
During a harmless task, interrupt the executor connection and record the observed pending, connected or failed environment state together with the eventual turn outcome. Check how your handler reconciles unfinished work before allowing new work or stopping compute. Then test session deletion, artifact removal and your own environment cleanup separately. Do not use live financial or operational writes to discover these behaviours.
5. Set a measured expansion gate
Define an accepted-result rubric, review-time budget and total task-cost ceiling before comparing the managed harness with your baseline. Start without production write privileges. Expand only when approved data handling, denied-access tests, connection recovery and cleanup evidence pass—not merely because the model produced a convincing answer. Maintain a rollback route to the existing workflow while the API remains in beta.
Make the first deliverable a boundary review
The Agents API may reduce the work needed to maintain a capable harness. Its self-hosted option is useful precisely because compute placement and harness ownership are separate choices. That separation must remain visible in the buying decision.
For a scoped AI automation engagement, the practical starting point is an endpoint-specific data-flow review and a read-only pilot acceptance plan: approved session data, tool connection modes, credential boundaries, cost measurement and cleanup evidence. Decide what may cross the managed-service boundary before deciding how much work to delegate.
