OpenAI's Agents API Beta Is US-Only and Not ZDR-Eligible

OpenAI's Agents API entered public beta on 2026-09-10 supporting United States data residency only, and it is not eligible for Zero Data Retention.

That single line decides adoption for a lot of teams before any feature comparison starts. Here is what the managed runtime actually takes over, and what it leaves on your desk.

What the runtime now owns

Where the Responses API hands you model calls with tools, the Agents API operates the harness around them. Four capabilities matter:

• Sandboxes, managed or self-hosted. OpenAI-managed execution, your own infrastructure, or partner sandboxes — the writeup lists Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel.
• Automatic context compaction. The runtime summarizes earlier context as a session approaches its context limit, so long workflows continue across context windows without you writing compaction logic.
• Multi-agent delegation. Tasks split into independent pieces handed to parallel subagents, each with its own context, coordinated by a main agent.
• Long-running sessions. The runtime owns the lifecycle instead of your orchestration code.

What did not move

Nothing in your stack was deprecated. The Responses API, the Agents SDK and the managed Agents API are separate layers, and OpenAI frames the launch as additive. AgentKit is the exception people conflate with it: it received a wind-down update in June 2026, a separate product decision.

Reliability engineering is also untouched. A managed harness does not make a probabilistic model deterministic — retries, idempotent actions, schema-validated tool results, iteration caps and approval gates on irreversible steps all stay yours. The API removes infrastructure work, not control design. Evaluation stays yours too: no runtime can tell you whether the output is correct for your task.

The constraint that disqualifies teams

Per the developer docs cited in the writeup, beta support covers US residency only and excludes ZDR. The trap is assuming a self-hosted sandbox routes around it — it changes where your code executes, not where the platform's data obligations sit. If you carry EU residency or ZDR requirements, treat this as a blocker rather than something to engineer past. The second constraint is softer: beta interfaces move, so a workload that cannot absorb breaking changes should pilot rather than commit.

Adopt or wait

Adopt or pilot if	Wait if
Workload is long-running and tool-heavy	You need EU data residency or ZDR
You accept beta-grade interface stability	You need interface stability guarantees
US data residency is acceptable	Workloads are short enough that a managed harness solves a problem you never had

The cleanest pilot shape, per the source: one long-running workflow with a measurable success criterion and an eval set you already have. A week of that tells you whether the managed harness earns its abstraction.

What to instrument before you migrate

Adopting a managed harness is a good moment to check the controls it does not provide. Validate the content of every tool result against an expected schema rather than the transport status — an error payload wrapped in HTTP 200 is the classic silent failure. Put hard iteration caps alongside an exit condition the workflow can evaluate, plus time, token and cost budgets. Track the count of irreversible actions executed without approval; that number should be zero.

Compaction deserves its own metric. Chroma's July 2025 report evaluated 18 models and found performance degrades as input length grows, even on simple tasks, with topically related distractors making it worse. A runtime that summarizes for you is still accumulating noise on your behalf — plot task success rate against input-token length and watch whether the curve bends once the harness, rather than your code, decides what to keep.