OpenAI Can Run the Agent Loop—But It Cannot Own Your Business Controls

Status verified September 13, 2026.

An agent reports that remediation succeeded, but the underlying service timed out after accepting the request. The session resumes and considers retrying. Did the first operation fail, commit once, or commit without returning a response?

OpenAI’s Agents API can restore the coordination process. It cannot, by itself, establish the authoritative outcome of a transaction in an external system. That boundary defines the API’s production value—and its limits.

Key Takeaways

OpenAI introduced the Agents API in public beta on September 10, 2026, available to all developers. OpenAI says it will iterate quickly during the beta, so current interfaces should not be treated as stable general-availability contracts. (OpenAI launch announcement)

The managed Codex harness handles sessions, orchestration, context compaction, subagents, and recovery. Applications still provide tools and select the execution environment. (Agents API overview)

Self-hosting moves command, file, and local MCP execution into developer-controlled compute. It does not self-host the OpenAI-managed harness or Agents API session state. (Self-hosted sandboxes)

The public beta supports Agents API data residency only in the United States and is not eligible for Zero Data Retention, including with a self-hosted sandbox. (Agents API data controls)

The meaningful economic measure is engineering-plus-runtime cost per accepted and reconciled task, not cost per API call.

What OpenAI Released

OpenAI’s September 10 announcement describes the Agents API as the Codex harness and supporting infrastructure exposed through a managed API. It is designed for durable, long-running tasks rather than as a new model family or a renamed Responses API.

The official documentation organizes the product around four concepts:

Agent: the model, instructions, tools, and MCP servers available to the agent.
Environment: an optional sandbox or computer where files can be accessed and commands can run.
Session: a durable agent instance that works on tasks and accepts additional input.
Events and items: the inputs, progress, tool activity, and outputs associated with a session.

OpenAI runs the managed harness. It can summarize earlier work to manage context pressure, delegate work to subagents, connect to configured tools or MCP servers, accept steering, and resume a session. OpenAI does not publish a general compaction-fidelity rate or a guarantee that every critical constraint will survive summarization unchanged; production teams should test that behavior against their own evidence and policy requirements.

The current quickstart uses the beta.agents SDK namespace. Direct HTTP requests use /v1/agents/sessions and require the OpenAI-Beta: agents=v1 header; the official SDKs add that header automatically. These are current beta interfaces, not durable compatibility promises. (Agents API quickstart)

Agents API architecture: application, managed Codex harness, and execution environment — Figure 1: Official Agents API overview showing the application, managed Codex harness, and execution environment. Image: OpenAI Developers, Agents API overview.

Managed Orchestration and Execution Are Separate Boundaries

With an OpenAI-hosted sandbox, OpenAI runs the harness and provisions the sandbox. The application sends input, receives events, and configures the tools and capabilities available to the agent.

With a self-hosted sandbox, OpenAI still runs the agent harness. The developer runs codex exec-server inside a laptop, container, remote sandbox, or supported partner environment. The executor performs shell commands, file operations, and local MCP activity at the harness’s request.

OpenAI documents that the executor:

registers using an environment ID and a restricted API key;
connects over WebSocket to receive commands and return results;
uses outbound connections;
reconnects if its connection drops; and
requires a separate executor for each session environment.

OpenAI recommends a dedicated restricted executor key, with all unrelated permissions disabled, while the broader application key remains outside the sandbox. Agent-generated code can read that executor key, but OpenAI states that the key can only connect environments and cannot authorize other OpenAI API actions.

That safeguard is specific to the OpenAI executor credential. It does not automatically limit credentials for databases, ticketing systems, cloud accounts, payment services, or other business tools placed in the execution environment. Downstream credential scope, expiration, revocation, and resource-level authorization remain application and infrastructure responsibilities.

Session Recovery Is Not Transaction Recovery

The Agents API can preserve and retrieve session progress after a process restart or disconnected stream. That is recovery of agent coordination state.

OpenAI’s own quickstart makes the limit explicit: a completed turn does not guarantee that every tool succeeded. If a stream disconnects, the documented recovery step is to retrieve the session and its saved items before retrying. That still does not prove whether an external system committed a side effect after receiving a request but before returning its response.

This is a standard distributed-systems ambiguity. RFC 9110 permits automatic repetition when request semantics are known to be idempotent or when the client can establish that the original request was not applied. It advises against automatically retrying non-idempotent methods without such knowledge.

The Amazon Builders’ Library guidance on idempotent APIs describes the same failure mode: after a timeout, a caller may need reconciliation to determine whether a resource was created. AWS recommends caller-provided request identities and an atomic relationship between the idempotency record and the mutation.

Authorization has an equally important boundary. NIST SP 800-207 rejects implicit trust based on network location, while the OWASP Transaction Authorization Cheat Sheet recommends server-side enforcement, transaction-specific authorization data, controlled state transitions, and a final authorization gate tied directly to execution.

For a consequential tool call, the application should therefore retain control over:

the authenticated actor and tenant;
the exact resource and requested operation;
the arguments and current policy version;
approval evidence bound to that operation;
narrowly scoped credentials;
an application-generated operation identity;
the attempted and observed side effects;
independent validation, compensation, and reconciliation.

Structured output can establish that a model response matches a schema. It cannot prove that a payment happened once, a deployment reached the requested revision, or an account change was authorized by the correct actor.

Self-hosted sandbox connection to the Agents API — Figure 2: Official self-hosted sandbox diagram showing the executor connection and command/result exchange. Image: OpenAI Developers, Self-hosted sandboxes.

Which Runtime Should Own the Loop?

OpenAI’s runtime comparison distinguishes the Agents API, Agents SDK, and Responses API by where orchestration runs and where state is managed. A deterministic workflow is not an OpenAI product, but it remains the appropriate control baseline when business transitions are known in advance.

Runtime choice	Documented orchestration and state behavior	Execution and data boundary	Controls the application must retain	Best fit and principal trade-off
Agents API + OpenAI-hosted sandbox	OpenAI runs the Codex harness, saves session configuration, turns, and items, compacts context, coordinates subagents, and supports recovery.	OpenAI provisions the sandbox. Agents API beta residency is U.S.-only and the endpoint is not ZDR-eligible.	Business authorization, approvals, downstream credentials, validators, idempotency, transaction records, and reconciliation.	Long-running adaptive tasks when managed session infrastructure removes meaningful work; highest dependence on managed session behavior.
Agents API + self-hosted or partner sandbox	The harness and session remain OpenAI-managed.	The developer or partner owns compute, isolation, patching, persistence, network policy, startup, and cleanup. Self-hosting does not change Agents API residency or ZDR eligibility.	All business controls above, plus executor lifecycle, local secrets, file isolation, and compute teardown.	Private-network access or specialized compute without operating the agent loop; not a route to self-hosted orchestration state.
Agents SDK + application-hosted loop	The SDK runner handles the loop and handoffs inside the application. Storage may use application-managed sessions or supported OpenAI conversation state.	Deployment, tools, sandbox integrations, and storage strategy are selected by the application.	The application directly owns approvals, tool implementations, business state, recovery design, and telemetry.	Custom workflows requiring greater control; the team must operate its own durable runtime and recovery infrastructure.
Responses API + application-owned loop	The application works directly with model responses and designs history, chaining, retries, and orchestration. Optional OpenAI state features have separate retention behavior.	Application-owned runtime, with separate controls for any hosted tools used.	Full routing, authorization, tool dispatch, validation, side-effect safety, and recovery logic.	Direct calls, short trajectories, or bespoke/provider-neutral orchestration; greatest implementation burden.
Deterministic workflow or job orchestrator	Explicit states, retries, timers, approvals, and compensation are controlled by the workflow engine or application.	Runs within the organization’s chosen infrastructure and governance boundary.	Business rules and consequential transitions remain deterministic; models can be limited to advisory, classification, or extraction steps.	Repeatable or high-consequence processes whose transitions are known; less suitable when the task genuinely requires open-ended reasoning.

Editorial interpretation: a self-hosted sandbox is an execution-location decision. It is not a transfer of Agents API session ownership, business authorization, or transaction-recovery responsibility.

Data Governance Can Be a Deployment Blocker

The Agents API overview states that the beta retains session state, supports data residency only in the United States, and does not support Zero Data Retention. It also explicitly states that using a self-hosted sandbox does not make the Agents API ZDR-eligible.

OpenAI’s broader platform data-controls documentation supports additional regions and ZDR for eligible endpoints, but those platform-wide capabilities must not be assumed to apply to /v1/agents.

The endpoint table lists:

abuse-monitoring retention for /v1/agents: 30 days, subject to the documented legal and safety exceptions;
application-state retention: until deleted;
ZDR eligibility: No.

A separate session-deletion API reference says deletion removes a managed session from the public API and returns confirmation, while physical cleanup may continue asynchronously. It does not publish a completion interval for that cleanup.

Consequently, mandatory non-U.S. residency, endpoint-level ZDR, or a requirement for time-bounded physical deletion evidence can rule out this beta before functional testing begins.

Price the Accepted, Reconciled Task

OpenAI says there is no additional Agents API fee during the public beta. Selected-model usage, OpenAI tools, and OpenAI-hosted sandboxes are billed at their standard rates. External APIs, partner sandboxes, developer-operated compute, storage, networking, and human review remain separate costs. (Launch announcement, Agents API overview)

The OpenAI API pricing page lists hosted container rates of:

1 GB: $0.03 per 20-minute session per container
4 GB: $0.12
16 GB: $0.48
64 GB: $1.92

OpenAI defines these as binary gigabytes, where 1 GB equals 2³⁰ bytes. It also states that eligible container sessions are billed by the minute with a five-minute minimum. Because the Agents API overview points OpenAI-hosted sandboxes to standard container rates, these figures are the relevant published baseline; teams should still validate metered lifecycle behavior with representative sessions before forecasting.

The procurement metric should be:

Total engineering, model, tool, compute, external-service, and review cost ÷ accepted tasks with fully reconciled side effects

That denominator penalizes retries, duplicate work, unreconciled mutations, and outputs rejected by validators—costs that per-call pricing hides.

Treat Launch Metrics as Testimonials

OpenAI’s launch page reports several customer-supplied outcomes:

Ciridae reported an evaluation score increase from 0.71 to 0.85 and described a “4x latency reduction” relative to its previous subagent setup.
SafetyKit reported a 60% reduction in cost per case, lower latency, and improved token efficiency while maintaining its existing performance.
A separate testimonial reported 86% fewer failed agent responses after separating the harness from the sandbox.

The announcement does not publish sample sizes, traffic mix, model versions, hardware, review labor, statistical uncertainty, evaluation definitions, or reproducible test procedures. The available official page text identifies Ciridae and SafetyKit, but does not expose a name alongside the 86% testimonial. These figures are evidence of reported customer experience—not transferable performance benchmarks.

A Migration Pattern That Preserves Control

Keep tool contracts application-owned. Version business operations independently of the agent runtime.
Authorize every consequential call at execution time. Bind actor, tenant, resource, arguments, policy, and approval evidence.
Issue narrow credentials. Prefer task- or resource-scoped credentials with expiration and revocation.
Assign a durable operation identity. Reuse it for every attempt of the same logical mutation.
Make mutation handling idempotent where possible. Atomically associate the operation identity with the resulting business state.
Validate outcomes outside the model. Use system-of-record queries, schemas, acceptance tests, and risk-based human review.
Record business state separately. Track requested, authorized, attempted, completed, failed, and compensated states.
Reconcile before retry. After interruption, inspect the ledger and external system before allowing the session to repeat a mutation.
Preserve portable evidence. Retain normalized tool requests, results, approvals, validator outcomes, and acceptance decisions outside the managed session.

OpenAI-hosted Agents API environment illustration — Figure 3: Official Agents API environment illustration from the OpenAI developer announcement. Image: OpenAI Developer Community announcement.

Proposed Validation: Test Recovery at the Business Boundary

This experiment is proposed and has not been executed. None of the sample sizes, metrics, or thresholds below are empirical results.

Compare four implementations:

Agents API with an OpenAI-hosted sandbox;
Agents API with a self-hosted sandbox;
an application-hosted Agents SDK loop; and
a deterministic workflow baseline.

Use 30 synthetic incident cases split across normal, ambiguous, and injected-failure conditions. Running each case three times across four implementations produces 360 planned runs.

Hold constant the model version where supported, source corpus, tool schemas, timeout policy, approval rules, spend ceiling, and completion rubric. Restrict remediation to a local test ledger rather than a live production system.

Inject failures including dropped streams, executor restarts, tool timeouts, malformed results, duplicate callbacks, delayed approvals, revoked credentials, context pressure, and interruption after a mock mutation commits but before its result reaches the agent.

Measure:

accepted-task rate;
unsupported claims;
p50 and p95 completion latency;
model, tool, and container cost;
human-review minutes;
duplicate or unauthorized mutations;
successful session continuation;
fully reconciled operations; and
trace and evidence completeness.

Use paired case comparisons and report uncertainty rather than relying only on aggregate averages. Treat zero unauthorized mutations, zero duplicate business effects, and complete reconciliation as engineering safety gates. Any 95% trace-capture target should be considered a provisional observability threshold, not a substitute for complete records of consequential actions.

Tech Trend Insight Editorial Verdict

The Agents API is a credible candidate when work spans many tool calls or context windows, managed session recovery removes substantial undifferentiated infrastructure, or subagent coordination is valuable—and when the organization accepts beta interfaces, U.S.-only Agents API residency, and ZDR ineligibility.

Prefer the Agents SDK, Responses API, or deterministic orchestration when provider-neutral replay, non-U.S. residency, ZDR, exact state-transition semantics, or independently controlled recovery is mandatory.

This judgment would change if OpenAI adds supported non-U.S. Agents API residency or ZDR, publishes stable general-availability compatibility commitments, provides portable session export and replay guarantees, or independent like-for-like testing demonstrates a materially lower cost per accepted and reconciled task.

Conclusion

The Agents API can remove meaningful runtime plumbing: session persistence, context management, subagent coordination, environment connectivity, progress events, and recovery of managed work.

It should not become the system of record for business truth. Safe delegation requires authorization, credential scope, transaction identity, side-effect records, validation, compensation, and reconciliation to remain enforceable outside the agent session.

FAQ

Does the Agents API replace the Agents SDK or Responses API?

No. OpenAI positions the Agents API for long-running work where OpenAI runs the managed Codex harness and saves progress. The Agents SDK runs the loop inside the application, while the Responses API is the lower-level option for direct model work or a custom loop. (Runtime comparison)

Does a self-hosted sandbox provide ZDR or non-U.S. residency for Agents API sessions?

No, according to documentation verified September 13, 2026. Self-hosting changes where commands, files, and local MCP operations execute; OpenAI still manages the harness and Agents API session state. The beta remains U.S.-residency-only and ZDR-ineligible. (Agents API overview)

What controls should remain outside the managed session?

Keep resource-level authorization, approval enforcement, credential scope and rotation, business rules, idempotency, transaction records, independent validation, audit evidence, compensation, and reconciliation in application-controlled services. The agent may request or coordinate an action; the application should decide whether it is permitted and establish whether it actually succeeded.

Tech Trend Insight