OpenAI's Agents API mainly changes who operates the agent loop. Instead of the application maintaining the sequence of model calls, session state, context compaction, recovery after interruptions, and subagent coordination on its own, that work moves to a Codex harness run and maintained by OpenAI. The application, however, remains responsible for defining what the agent can do, which tools and data it receives, how the experience is presented to users, and, depending on the chosen environment, the execution infrastructure itself.
That division is the key to evaluating the new API. The Agents API does not turn an entire product architecture into a managed service: it outsources a specific layer — the agent runtime — while leaving the rest under application control. OpenAI launched it in public beta on September 10, 2026. The official documentation summarizes the boundary by saying that OpenAI manages sessions, orchestration, context compaction, and recovery, while the application provides tools and chooses its execution environment. See the official announcement and the Agents API overview.
Short answer: the harness is managed; the product is not
The clearest way to think about the Agents API is to separate three pieces: the harness, the environment, and the application server. The harness is the OpenAI-hosted Codex instance that runs the model, coordinates the tool loop, and maintains the session. The environment is where commands, code, and files are handled. The application server is your code: it starts tasks, receives events, connects data and tools, and enforces product rules.
In practice, the Agents API can remove a large amount of orchestration glue, but it does not remove product, security, authorization, integration, or infrastructure decisions. That distinction is explicit in the official architecture documentation.
What moves into the managed harness
The agent loop and session continuity
The harness calls the model, processes tool use, maintains the session, and lets work continue across turns. Sessions are durable: the application can return to the same context without manually rebuilding the full history. The documentation also describes recovery and resuming work as part of the managed service.
Context compaction
As a session approaches its context limit, the Agents API can compact earlier work to preserve what is needed to continue. This reduces the need to build a custom layer for summaries, history trimming, and context reconstruction in long-running tasks. The quality of instructions, the data supplied, and the application's memory policy still remain product responsibilities.
Subagent coordination
Multi-agent support can split work into independent pieces and delegate them to subagents, each with its own context, while the root agent combines the results. This replaces much of the code that previously created workers, controlled concurrency, and reconciled responses. The benefit is strongest in research, analysis, and coding tasks where subtasks can genuinely progress in parallel.
Tool selection and use inside the loop
The harness decides when to invoke already configured tools and can use mechanisms such as tool search and programmatic tool calling. It supports built-in tools, MCP, and custom functions. The important nuance is that the harness manages usage; the application still defines capabilities. A remote MCP server can be called directly by the harness, but application functions still need your handler to execute the action and return the result.
Sandbox execution when you choose the hosted environment
With environment.type: "openai_hosted", OpenAI provisions and manages the sandbox where the agent can run code, edit files, and produce artifacts. The application still configures the files, packages, and network access it needs. If the environment is self-hosted, the boundary changes: the harness remains managed, but the infrastructure does not.
Comparison: who owns each layer
| Layer | Agents API / harness | Application |
|---|---|---|
| Agent loop | Runs the model/tool cycle, continuity, and resumption. | Defines goals, instructions, limits, and when work starts or stops. |
| Context | Maintains the session and performs automatic compaction when needed. | Decides which data enters, product retention policy, and business context. |
| Execution | Runs commands directly in an OpenAI-hosted sandbox. | Chooses the environment; in self-hosted mode, provisions, reconnects, and shuts down compute. |
| Files | Works with files available in the environment and can produce artifacts. | Provides files and decides persistence; in self-hosted mode, preservation is yours. |
| Tools | Selects and invokes configured tools inside the loop. | Chooses MCPs, functions, and integrations; function handlers remain in the app. |
| Subagents | Creates, coordinates, and tracks delegated work when multi-agent is enabled. | Decides whether to use multi-agent, concurrency limits, tasks, and policies. |
| Observability | Emits events, keeps history, records usage, and provides traces in the dashboard. | Consumes events/webhooks, integrates alerts, and turns telemetry into product operations. |
| Infrastructure | Can manage the OpenAI-hosted sandbox. | Still owns private infrastructure, private networking, UX, backend, and external systems. |
What remains the application's responsibility
Product logic and user experience
The Agents API does not decide when a task should exist, what promise the product makes, how results appear, which confirmations are required, or what happens when the agent fails. Queues, screens, notifications, UI states, per-user session limits, and business decisions remain in the application.
Permissions, security, and business rules
Giving the agent access to a tool does not delegate authorization policy. The application still needs to decide which users may trigger which actions, validate parameters, enforce access controls, require approvals, and limit side effects. For sensitive operations, the tool handler should remain a security boundary rather than a blind proxy.
Tools, data, and integrations
OpenAI operates the harness, but it does not automatically know your databases, CRMs, internal systems, or domain rules. You need to expose those capabilities through MCP, functions, or other integrations and choose what the agent can see. In other words, the Agents API replaces orchestration of tool use, not the work of building and governing the tools themselves.
Your own infrastructure, when you use it
The Agents API supports OpenAI-hosted, partner, and self-hosted environments. In self-hosted mode, your application still owns provisioning, reconnection, shutdown, and preservation of files that need to survive. The documentation recommends this path when the agent needs private infrastructure, a private network, or specialized software.
Product operations around the agent
Events and webhooks help track work, but the application still needs to handle unavailable handlers, waiting UX, idempotent actions, retries in external systems, and cancellation policy. If a custom function does not respond, for example, the session may remain waiting for its result. A managed runtime does not remove the need for distributed-systems engineering at the edge of your product.
Observability gets better, but it is not a complete operations platform
The Agents API exposes real-time session events, saved history, and recorded usage by turn, including subagent work. The tracing dashboard shows model responses, tool calls, step duration, and status. This reduces the work required to understand what happened inside the loop and makes complex agents easier to debug. See the documentation for observability and usage and tracing.
There are important public-beta limits: detailed traces live in the dashboard, the public API does not expose tracing configuration or external trace exporters, and agent telemetry still needs to be correlated with logs, metrics, and traces from your own backend. So “managed observability” means strong visibility into the agent runtime, not automatic replacement of Datadog, Grafana, OpenTelemetry, or a SIEM.
When the Agents API can replace custom orchestration
- Long, iterative tasks: when an agent needs many steps, continuity across turns, and growing-context management.
- Heavy tool use: when manually maintaining the call/result/resume loop has become repetitive infrastructure.
- Parallelizable subtasks: when subagents can split research, analysis, debugging, or artifact generation.
- Need for a sandbox: when running code and working with files is a natural part of the task.
- A team that wants less harness maintenance: when tracking model changes, compaction, and agent patterns is not a product differentiator.
In these cases, the trade is straightforward: you give up some runtime control in exchange for less orchestration code and a harness that OpenAI says it will evolve alongside its models.
When it does not replace your architecture
- Deterministic workflows: if the process is a strict state machine, traditional queue, or tightly auditable sequence, an agent may be a component rather than a replacement.
- Provider portability: if avoiding dependence on one harness is a core requirement, keeping your own abstraction layer may be intentional.
- Fine-grained compute control: workloads with specialized hardware, private networks, compliance, or isolation requirements may stay self-hosted — and a meaningful share of operations remains yours.
- Complex authorization policies: the runtime does not replace the product's identity, policy, and approval systems.
- Mandatory trace export: because the public beta does not offer external trace exporters, teams with strict observability requirements may need additional instrumentation.
Practical adoption criteria
- List the code that exists only to keep the agent running. If you have substantial loop, state, compaction, session recovery, and subagent plumbing, it strongly overlaps with the managed harness.
- Separate “agent orchestration” from “business orchestration.” The former is a migration candidate; the latter usually should remain explicit in your application.
- Choose the environment before estimating operational savings. With a hosted sandbox, you also outsource session compute. With self-hosted, you still operate the infrastructure.
- Map functions and MCP servers. Remote tools can fit cleanly; local functions and side-effecting actions still require robust handlers and your own authorization.
- Measure cost per task, not just cost per model call. An agent can make multiple model calls, use subagents, tools, and sandbox compute. The Agents API itself carried no additional service fee in the launch beta, but tokens, tools, and containers follow their standard pricing.
- Check data requirements before production. As of September 13, 2026, the documentation says the Agents API supports data residency only in the United States and does not support Zero Data Retention, including when the sandbox is self-hosted.
Conclusion: the new boundary is between runtime and product
The Agents API is best at replacing the part of the stack that exists to keep the agent working: loop, session, context, recovery, delegation, and operational integration with an execution environment. It does not replace the part that exists to make the product correct: business logic, UX, identity, permissions, governance, integrations, handler reliability, and infrastructure decisions.
For teams that already built a custom harness, the useful question is not “can we delete our orchestration?” but “how much of our orchestration is generic runtime, and how much is product-specific behavior?”. The larger the first share, the more likely the Agents API is to simplify the architecture. The larger the second, the more it will behave as a managed layer inside an application that remains explicitly in control.
