What happened
On September 10, 2026, OpenAI introduced the Agents API in public beta. The product exposes the same "harness", OpenAI's term for the underlying orchestration system, that powers Codex, its coding agent, and the longer-running agent features inside ChatGPT for Work. Before this launch, a business that wanted a custom AI agent had to build and maintain that harness itself: the code that keeps a session running over time, decides when to call which tool, manages context as a task runs for minutes or hours, and recovers if something fails partway through. With the Agents API, a developer can create a working agent in a single API call, specifying the model, the tools it can use, and where it runs. OpenAI manages the session, the orchestration between steps, the summarizing of older context so a long task does not run out of room, and the delegation of subtasks to other agents when useful. The business still decides what the agent is allowed to do and chooses where it executes: an OpenAI-hosted sandbox, the business's own infrastructure, or a partner environment from providers including Cloudflare, DigitalOcean, Oracle, and Vercel. There is no separate charge for the harness itself. A business pays for the model tokens used, the tools the agent calls, and, if it picks an OpenAI-hosted sandbox, standard container rates for that compute. Alongside the launch, OpenAI published quotes from several named customers already using the API, including a logistics company running large numbers of long-running agents in production and a compliance software company reporting a 60 percent reduction in cost per case after adopting it. Those figures come from OpenAI's own launch announcement, not an independent audit, and this post treats them as vendor testimony rather than verified results.
Why it matters for business owners
Most small and medium businesses are not going to write a custom AI agent harness from scratch, and this launch does not change that. What it changes is the calculation for businesses already building, or paying a developer or agency to build, an AI agent workflow: a support agent that can look things up and take action, an internal agent that monitors a process and flags problems, or a research agent that pulls together information from several sources. Until now, that meant either using a narrower off-the-shelf tool or building the underlying session and orchestration logic yourself, which is real, ongoing engineering work. The Agents API removes a meaningful share of that work and hands it to OpenAI instead. That is a legitimate reason some businesses will choose it. The part worth pausing on is where the data goes while that harness is doing its job. Even if a business runs the agent's actual sandbox, the code execution and file environment, on its own infrastructure, the session, orchestration, and everything the managed layer touches is still processed and stored on OpenAI's side, and currently only inside the United States. For a business with customers or regulatory obligations outside the US, or one that has decided sensitive data should never be retained by a vendor for any reason, that is worth knowing before a workflow gets built around it.
What owners should not misunderstand
This is not a security flaw or a hidden problem. OpenAI states the limitation plainly in its own documentation rather than burying it, and the Agents API is a legitimate, well-built option for many businesses. Most companies do not handle data that requires strict residency or zero retention, and for them this limitation will not come up in practice. This also does not mean OpenAI has no path to stronger data controls. Just two days before the Agents API launched, OpenAI announced it is rolling out Zero Data Retention more broadly across its frontier models, alongside a new system called Private Safety Processing designed to let it monitor for abuse without giving its own staff access to customer content. That effort, covered on this blog when it was announced, is real and moving. It has simply not reached the Agents API yet, and OpenAI's documentation is explicit that a self-hosted sandbox does not work around the gap. And this is not unique to OpenAI. Any vendor's managed AI agent layer, whichever company builds it, carries its own data residency and retention terms, and those terms change over time as the market matures. The lesson here is to check data handling before building on any managed AI infrastructure layer, not that OpenAI specifically is behind its competitors.
The operational lesson
The standard build-versus-buy question for software has always weighed engineering time against control. AI agent infrastructure adds a second axis that is easy to skip past in the excitement of a fast demo: what happens to the data flowing through the vendor's managed layer, and whether that matches what your business, your customers, or your regulators actually require. A managed harness like the Agents API is a genuine shortcut, and it is reasonable for many businesses to use it for workflows that do not touch sensitive data: internal research tasks, code review, general questions that do not involve personal or financial detail. It is a different decision for a workflow that touches customer financial records, health information, legal matters, or any data your business has committed, contractually or by policy, to keep in a specific place or out of a vendor's retention logs. The practical shift is to make data handling part of the same decision as the engineering tradeoff, evaluated before a workflow is built, not a compliance question raised after the business already depends on it.
What a serious business should do next
Before building any workflow on the Agents API, or a similar managed AI agent layer from another vendor, read the vendor's own data handling documentation directly, not just the launch announcement. Look specifically for data residency and retention terms, and whether those terms hold regardless of where you choose to run the agent's sandbox. Sort your planned AI agent use cases into two groups: work that never touches sensitive, regulated, or contractually restricted data, and work that does. Build the first group on whatever infrastructure is fastest and most cost effective, including a managed API like this one, without much hesitation. For the second group, hold off until the vendor's data controls actually match your requirement, or build that specific workflow on infrastructure you control. Do not assume that self-hosting the sandbox, the code execution environment, is the same thing as controlling where the rest of the agent's data goes. As this launch shows, it often is not. Revisit the decision periodically rather than once. Vendor data controls in this market are changing quickly in both directions, and a limitation that rules out a vendor today may be resolved within months, the way OpenAI is actively working on broader Zero Data Retention support right now.
The Atlacis view
Atlacis takes no position on whether OpenAI's Agents API is the right choice for any given business. It is a well-built product solving a real engineering problem, and its current data handling limits are disclosed plainly rather than hidden. What Atlacis does is help business owners separate the two questions a launch like this bundles together: is this the fastest way to build what we need, and is this where our data is allowed to live. Both are real questions, and a good answer to the first does not automatically answer the second. Atlacis helps map which of a business's planned AI agent workflows actually touch sensitive or regulated data, and helps decide, workflow by workflow, when a managed vendor layer is the right fit and when it is worth the extra effort to keep infrastructure under the business's own control.
The short version
- On September 10, 2026, OpenAI launched the Agents API in public beta, giving any developer the managed session, orchestration, and context-management harness that powers Codex, removing a large share of the engineering work required to build a production AI agent.
- There is no separate fee for the harness. Usage is billed through model tokens, tool calls, and, for OpenAI-hosted sandboxes, standard container rates.
- Per OpenAI's own documentation, the Agents API currently supports data residency only in the United States and does not support Zero Data Retention, and choosing a self-hosted sandbox for the agent's code execution does not change either limitation.
- Two days earlier, OpenAI announced it is expanding Zero Data Retention more broadly across its models through a new system called Private Safety Processing, showing the company is actively working on this gap, just not yet for the Agents API specifically.
- Before building any workflow on a managed AI agent layer, from OpenAI or any other vendor, separate which use cases touch sensitive or regulated data and check the vendor's actual data residency and retention terms for that specific product, not just its general privacy policy.
Where ATLACIS can help
- Read: what business owners should know about OpenAI and Anthropic's data retention policy shift
- Read: IBM's AI vendor dependency study and what it means for your business
- Read the AI workflow audit checklist
- Review Private AI Implementation
- Book a call to map which AI agent workflows should stay off a managed vendor layer