OpenAI Agents API: US-only residency, your Azure options

OpenAI's Agents API went into public beta on 10 September, and its documentation carries one sentence that settles the question for most Swedish enterprises before the first session starts: "The Agents API currently supports data residency only in the United States and does not support Zero Data Retention (ZDR)." The next sentence closes the obvious escape hatch: "Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible." The product itself is the most complete thing OpenAI has shipped for long-running agents. It is the Codex harness as a managed service, with sessions that run for hours, automatic context compaction, subagents and MCP built in, and no fee beyond tokens and compute. Whether you can use it from Stockholm depends on where the session state lives, and today that is a US region. What runs in Sweden Central instead, and what it costs, is the more useful comparison.

What OpenAI shipped

The Agents API is a managed agent runtime, not a new model endpoint. You describe an agent, OpenAI provisions an environment, and a durable session works through a task while you watch events stream back or arrive by webhook. The documentation organises it around four objects.

The harness inside the session is the one Codex uses, and OpenAI lists what it does for you: it runs commands and code in the sandbox, applies skills, connects to data through tools or MCP servers over HTTP, accepts steering mid-task, summarises earlier work when the context fills up, delegates subtasks to subagents with a configurable concurrency cap, and resumes a session where it stopped. Tool search loads tool definitions on demand rather than putting the whole catalogue in every prompt, and programmatic tool calling lets the model chain and parallelise calls.

from openai import OpenAI

# Header "OpenAI-Beta: agents=v1" is added by the SDK
with OpenAI() as client:
    with client.beta.agents.sessions.create(
        agent={
            "model": "gpt-6-astra",
            "instructions": "Write clean code, run it, and report the actual output.",
        },
        environment={"type": "openai_hosted"},   # or self_hosted / a partner sandbox
        input="Reproduce the failing test in /workspace and propose a fix.",
        stream=True,
    ) as events:
        for event in events:
            if event.type == "agent.session.turn.completed":
                break

Environments come in three shapes: an OpenAI-hosted sandbox, a sandbox on infrastructure you run yourself, or one from a partner. OpenAI's launch post names Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel. Pricing is the simplest part: "Model usage is billed at the selected model's API rates. OpenAI tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates." There is no platform fee for the harness.

The residency clause, read the way a DPO reads it

OpenAI's data controls page lists the Agents API endpoint with three properties: abuse-monitoring logs are kept for 30 days by default, application state is retained "until deleted," and Zero Data Retention eligibility is "No." The endpoint does not appear in the regional tables at all, not for the EU, and not for the UK, Japan or any other region OpenAI serves through its residency programme. The overview page then adds the sentence about self-hosted sandboxes. Running the container in your own Azure subscription changes where commands execute; it does not change where the session, its event history and its artifacts are stored.

The shape of OpenAI's existing EU offering explains why this is not a quick fix. European projects reach regional processing and storage through eu.api.openai.com, but only after approval for modified abuse monitoring or ZDR and a signed Modified Retention amendment, and even then the data controls page states that Chat Completions and Responses "cannot set store=true in non-US regions." OpenAI's EU residency has always been a stateless arrangement. A product whose entire value is server-side state does not fit that shape without new engineering. OpenAI does not give a reason for the US-only limit, but Anthropic is explicit about the same constraint on its equivalent product: Claude Managed Agents "is stateful by design" and "is not currently eligible for Zero Data Retention (ZDR) or HIPAA Business Associate Agreement (BAA) coverage."

In practice this means every file the agent reads, every command output, every message in the session and every published artifact sits in US storage until you delete it. An EU-resident OpenAI project can keep calling the Responses API through the EU endpoint; the moment that same project opens an agents session, the data for that workload leaves the arrangement your processing records describe. Personal data in the repository, the ticket queue or the documents the agent works on becomes a transfer, with everything a transfer entails under GDPR. That is a governance decision, not a technical one, and it should be made before the first pilot rather than discovered in an audit.

Three managed harnesses side by side

The Agents API joins two products that already do the long-running-agent job for enterprises on Azure and on Anthropic's platform. The differences that matter for a Swedish deployment are ownership of the harness, where state lives and who the agent is when it calls your systems.

Two rows carry the decision. On residency, Foundry is the only one of the three where session state can be placed in a Swedish region and, with the Standard setup, in storage accounts you own. On the harness, Foundry is the only one where you have to bring it. OpenAI and Anthropic sell the harness as the product; Microsoft sells the runtime around your harness. That trade is the whole choice.

Runtime cost is not what decides this

Because all three bill tokens at the model's normal rate, the only price difference is the runtime line, and it is small. Take a one-hour agent session on GPT-6 Astra that consumes 150,000 input tokens, of which 100,000 are cache reads, plus 20,000 output tokens. At the list prices we tabulated in the Sol-to-Astra checklist, the tokens cost $1.60 on either OpenAI or Azure Global Standard. The runtime on top of that:

The Foundry figures come from the Azure retail prices API for the Sweden Central meters, since the public pricing page still shows placeholders for hosted agents. The spread between the cheapest and dearest option is under thirty cents an hour, and the token bill dwarfs all of them. Two behaviours matter more than the rate. Foundry bills compute only while a session is active, releases it after an idle timeout you set between 2 and 60 minutes, and restores the session's home directory when the next request arrives; a session that sits unused is deleted after 30 days. Anthropic likewise meters only the running state. OpenAI's container pricing is per 20-minute block, so a session that fires one command every 19 minutes pays for the full block each time. Model the idle pattern of your real workload before comparing rates, and then stop, because the decision is being made elsewhere.

What actually runs in Sweden Central

Foundry Agent Service is regional, and Microsoft's quota page states that "data is stored in the same region as the endpoint." Sweden Central is on the hosted-agent list and is one of the better-provisioned regions: the default cap on concurrent hosted-agent sessions is 2,000 per subscription there, against 1,000 in most other regions, and the tool matrix shows every tool available, including Computer Use, which only nine regions support. The Standard setup replaces Microsoft-managed storage with your own resources: threads and agent definitions in Azure Cosmos DB, files in Blob Storage, vector stores in Azure AI Search. Hosted agents add a per-session VM-isolated sandbox with a persistent home directory, up to 20 GiB of disk at 1 vCPU or above, and the option to attach each sandbox to your own virtual network.

Identity is the part neither OpenAI nor Anthropic can match from outside the tenant. Every hosted agent gets its own Microsoft Entra ID at deploy time, so the agent that reads a SharePoint site or calls an internal API does so as a named principal with its own RBAC assignments and audit trail, not as whoever owns the API key. When a user invokes the agent from Teams, the platform supports On-Behalf-Of, so the agent inherits that user's permissions and nothing more. Publishing to Teams and Microsoft 365 Copilot is a switch rather than a project, because the platform bridges the Responses protocol to the Activity protocol for you.

One caveat keeps the residency story honest. Agent Service residency governs the state: conversations, files, sandbox disk. Inference residency is a separate switch on the model deployment. As the region table stood on 4 September, GPT-6 Astra is offered in Sweden Central only as Global Standard, which routes inference across Microsoft's global capacity, while GPT-5.6 Sol also has EU Data Zone deployments at the 20% premium. A hosted agent in Sweden Central calling an Astra deployment therefore has Swedish state and globally routed inference. Claude on Foundry has the same split: the hosted-on-Azure option offers a US Data Zone, not an EU one. Write both facts into the same paragraph of your processing record, because auditors will ask about both.

What you give up: the harness

Compaction, tool search, programmatic tool calling and subagent orchestration are where OpenAI has put a year of Codex engineering, and the Agents API hands them over as a versioned service that improves with each model launch. On Foundry hosted agents you supply that layer. The five supported frameworks all have context management and multi-agent patterns of some kind, and the Foundry Toolbox gives you MCP-fronted tools with centralised authentication, but nobody at Microsoft is tuning your compaction thresholds for GPT-6 Astra. Budget engineering time for it, and measure token use per completed task the way Spotify did, because a mediocre harness spends its savings on tokens.

OpenAI's launch post describes the harness as open source with a public codebase on GitHub. That opens a path worth a spike rather than an assumption: run the published harness inside a Foundry hosted-agent container, pointed at an Azure Responses endpoint in Sweden Central. Whether it works against Azure's endpoint without modification, and whether the version you pin keeps pace with the managed one, are questions to answer on day one of the spike, not in the architecture deck.

Whichever harness you run, write the task scope into the prompt and keep it close to the action. Anthropic's 9 September assessment of its own cybersecurity evaluation incidents measured the effect directly: when a scope reminder sat in recent context, the model stopped out-of-scope activity 90% of the time; when the same reminder was three turns back, that fell to 40%. A managed harness that compacts context can move your scope statement out of the recent window without telling you. Put it in the agent's standing instructions, not only in the first user message, and re-send it when a session resumes.

Decision guide

• Use the Agents API now if the workload holds no EU personal data and no data your contracts confine to the EU: public-repository maintenance, synthetic test generation, research over public sources, or a US-market product with US customers.
• Prototype on it, ship elsewhere if you want to learn what a good harness does before building one. Point it at scrubbed data, measure tokens per completed task, and use that as the bar your Foundry hosted agent has to meet.
• Build on Foundry hosted agents for anything that touches employee, customer or patient data, anything that must act as an Entra identity, and anything that has to appear in Teams. Pick Standard setup and Sweden Central, and keep residency-bound inference on a Data Zone model until Astra gets an EU zone.
• Do not wait for a fix without a date. OpenAI's documentation gives no timeline for non-US residency on the Agents API, and the stateless design of its EU offering suggests the change is not trivial. Plan on Foundry and treat an EU announcement as an option to re-evaluate, in the same way we framed the model exit plan earlier this month.

The checklist

1. Classify the data the agent will read, write and produce. If any of it is EU personal data or contractually EU-bound, the Agents API is out until OpenAI adds a region.
2. Record the two residencies separately: where session state lives and where inference runs. On Foundry they are set by different resources.
3. Choose Standard setup in Foundry so threads, files and vectors sit in your own Cosmos DB, Storage and AI Search in Sweden Central.
4. Size the sandbox from a measured run, not a guess. Billing is per active session, so oversizing multiplies by concurrency. Start at 1 vCPU and 2 GiB and check Application Insights.
5. Set the idle timeout deliberately. Fifteen minutes is the default; a batch agent that polls hourly should be closer to 2, an interactive one closer to 60.
6. Pick the harness and put a token-per-task number on it before the first sprint ends. Try the open-source Codex harness against an Azure endpoint as a time-boxed spike.
7. Assign RBAC to the agent identity, not to a shared service principal, and turn on On-Behalf-Of where users invoke it from Teams.
8. Put scope limits in standing instructions and re-send them on resume, so compaction cannot age them out of the recent window.
9. Watch the OpenAI data controls page for the Agents API row moving into a regional table, and re-run this comparison when it does.

The Agents API is the best-packaged agent runtime on the market this week, and for a Swedish enterprise it is still the wrong place to put session state. Foundry hosted agents cost about the same to run, keep the state in Sweden Central, and give the agent a name in your directory. The harness is your problem there, and it is a solvable one.