OpenAI’s Agents API moves the harness into the platform

OpenAI has released the Agents API in public beta, moving the orchestration layer behind Codex into a managed service for developers. A team can create a durable session, attach tools, choose an execution environment and let the service coordinate context, recovery and subagents. Part of the application’s operating loop now sits behind a platform API, which makes this a more substantial change than another agent SDK.

The OpenAI News RSS feed timestamps the release at 00:00 UTC on 10 September 2026. OpenAI’s launch announcement says the beta is available to all developers and adds no separate Agents API fee. Model tokens, OpenAI tools and hosted sandbox compute are still charged at their applicable rates. Any adoption case turns on whether the managed harness improves completed work enough to justify a new dependency, data boundary and control surface.

The service manages continuity, not the whole product

The Agents API overview assigns sessions, orchestration, context compaction and recovery to OpenAI. The application supplies tools and selects the execution environment. A session can receive new input, stream events, pause for a required action, resume a session where it left off and delegate work to subagents. Skills, MCP servers, web search and programmatic tool calls can be configured around the model.

The platform takes on a real engineering burden. Long-running agent applications otherwise need to persist task state, trim or summarise growing context, reconnect workers, identify delegated work and decide when to retry. Standardising those mechanics can make prototypes easier to operate and give production teams a clearer lifecycle than a collection of background jobs.

The application retains the business decisions: what data enters a session, which tools are available, which actions require approval and how an output is checked against external state. If an agent claims it updated a ticket, reconciled a file or fixed a service, the resulting system remains the authority. A durable conversation records what the agent attempted. Task success must be confirmed in the system it was meant to change.

Stopping work also remains an application responsibility. The session-management documentation separates cancelling an active turn from deleting its saved session. The hosted-sandbox guide says closing an event stream does not cancel the task. Applications need an explicit control path from a user’s stop request to the active turn and then to any external action already started.

Hosted and self-hosted environments create different boundaries

OpenAI’s launch material lists three compute routes: its hosted Linux sandbox, the builder’s own infrastructure and supported sandbox partners. This analysis compares the OpenAI-hosted and self-hosted options documented in detail. The hosted-sandbox documentation describes a workspace with Python, Node.js, command-line tools, supplied files, packages, skills and plugins. Outbound network access is enabled by default unless a template applies another policy. It can be disabled or restricted to a list of exact hosts.

That default deserves attention because retrieved pages, package metadata, repository files and tool output can all influence an agent. A first trial should begin with network access disabled or narrowly allowlisted, then add destinations only when the task requires them. Apply the same constraint to input files and packages: assemble the smallest environment that can complete the test rather than copying a production workspace into a general-purpose sandbox.

With a self-hosted environment, OpenAI runs the harness while an executor runs inside the builder’s laptop, container or remote sandbox. The connection is outbound. OpenAI recommends a restricted executor key that can connect environments but cannot authorise other API actions, while the broader application key remains outside the environment.

Self-hosting provides more control over the image, compute and private network. Session state remains subject to a different boundary. The Agents API overview states that Agents API session state currently has United States data residency and does not support Zero Data Retention, including when the sandbox is self-hosted. That can rule out the API for regulated, contractual or highly sensitive workloads before model quality is considered.

Permissions also remain separate from compute placement. OpenAI’s sandbox security guidance says agent-generated code can access the files, credentials and network available to its environment. It recommends isolating workloads, keeping third-party credentials outside the sandbox and brokering approved requests where possible. Teams still need separate environments, narrow identities and revocable authority when the executor is self-hosted.

A durable run does not prove dependable work

The launch page presents reliability and long-running operation as benefits of the managed harness. Those are platform claims, and Index Us has not tested the beta. Independent agent research helps define what a useful pilot should measure, although none of it evaluates the Agents API.

Two preprints identify different risks. WildClawBench tested 60 human-authored tasks in containerised CLI environments using 19 frontier models, with tasks averaging more than 20 tool calls. Its authors report a best overall score of 62.2 per cent and a change of up to 18 percentage points for one model when the harness changed. A separate long-horizon degradation study analysed 10,664 trajectories across nine models and four task families. Its author reports that success on the agentic task fell from near-perfect to near zero within 16 dependent steps for every tested model. Taken together, the reported results indicate that orchestration choices can materially affect outcomes and that preserving context does not remove accumulated decision risk. Both are preprints, and the long-horizon paper is a controlled study rather than a production audit.

METR’s time-horizon work clarifies a separate measurement issue. A reported time horizon refers to task difficulty measured by the time a human expert would need, not how long an agent can remain connected. METR also says its current measurements above 16 hours are unreliable and that its suite is concentrated in clean, well-specified software, machine-learning and cybersecurity tasks. Infrastructure that runs for days has demonstrated endurance, not success on every day-long business process.

Compare completed workflows under failure

A useful pilot should run the same representative work through the current harness and the Agents API. Keep the model, tools, instructions, data and success criteria as stable as practical. If the trial changes the model, environment and orchestration together, it will be difficult to tell which change caused a different result.

Measure at least seven things:

1. Outcome accuracy. Check the final database, repository, document or service state with deterministic tests or a separate review. Do not score the agent’s completion message as the outcome.
2. Step reliability. Retain the complete sequence of tool calls, retries, hand-offs and approvals. Group results by task length so a strong short run does not hide deterioration on longer work.
3. Recovery. Inject an executor disconnect, tool timeout, malformed response and expired sandbox. Confirm that the application can identify the state, resume safely and avoid repeating a side effect.
4. Authority. Give tools read-only access first. Add writes behind narrow scopes, idempotency keys and explicit approvals. Test what happens when a retrieved page or file asks the agent to exceed the task.
5. Cancellation. Verify that cancelling a turn stops new work, that external operations have their own cancellation or compensation path, and that a closed client connection is never treated as a stop signal.
6. Data handling. Map what crosses into session state, the hosted or self-hosted environment, tool providers and retained artifacts. Confirm that residency and retention match the actual data class.
7. Total cost and latency. OpenAI’s observability guide says an agent may make several model calls and that usage can be incomplete or change as accounting arrives. Count root and subagent tokens, retries, tools, container time, third-party services and review effort per accepted result.

The public beta also has observability limits. OpenAI’s observability documentation says session events and history expose progress, turn outcomes and delegated work, while detailed trace retrieval and external trace exporters are not part of the beta customer API. Teams with established audit pipelines should confirm that dashboard-only detail and best-effort usage records meet their operational needs.

The Agents API is a credible option when maintaining the harness is undifferentiated work and the application can operate within the current data and platform constraints. A small, reversible pilot can establish whether managed compaction, recovery and delegation improve the tasks that matter. Keep tools, permissions, cancellation, external-state checks and cost measurement outside the model’s own judgement. Those controls remain part of the product, even when the loop around them is managed.

This analysis is based on OpenAI’s launch material and current public-beta documentation plus independent agent-evaluation research. Index Us did not call the Agents API, inspect its infrastructure, reproduce the cited studies or verify OpenAI’s customer examples.

Sources

1. OpenAI — News RSS
2. OpenAI — Introducing the Agents API
3. OpenAI Developers — Agents API overview
4. OpenAI Developers — OpenAI-hosted sandboxes
5. OpenAI Developers — Self-hosted sandboxes
6. OpenAI Developers — Sandbox security
7. OpenAI Developers — Manage sessions
8. OpenAI Developers — Observability and usage
9. Ding and colleagues — WildClawBench preprint
10. Mittal — long-horizon agent degradation preprint
11. METR — Task-completion time horizons

Last reviewed: 11 Sept 2026. See our editorial policy for how we test, source and correct our work.