OpenAI’s Agents API: What It Is and What Changes for Developers

I first read ‘Agents API’ as another agent-building SDK.

That assumption lasted until I reached the phrase managed Codex harness. OpenAI is not only giving developers another way to call a model or arrange a tool loop. It is offering to run much of the agent runtime itself.

That includes the machinery that becomes awkward once an agent has to do more than answer one request: preserving its session, managing a growing context, recovering interrupted work, coordinating tools, operating inside a sandbox and delegating tasks to subagents.

The launch matters because it changes the question a team has to answer. It is no longer only, ‘Which model should we call?’ It is also, ‘Who should operate the system around the model?’

The short version

The Agents API gives an application access to the Codex harness through an OpenAI-managed service. Your application sends work and receives events. OpenAI runs the agent loop and maintains the session. You still define what the agent is, connect the tools it can use and choose where any code or file operations happen.

OpenAI describes four core objects:

• Agent: the model, instructions, tools and MCP servers available to it.
• Environment: the optional place where it can work with files, run commands and execute code.
• Session: a durable instance of the agent that can continue across tasks and turns.
• Events and items: the inputs, progress and outputs produced during that session.

Those four nouns tell us what OpenAI is actually selling. The model is only one component. The product is the managed operating layer around it.

What is a managed harness?

A model can generate a tool call. A useful agent has to keep deciding what happens next.

It needs to pass a result back to the model, retain the relevant state, avoid overflowing the context window, wait for an external function, report progress, recover from an interruption and know when the task is complete. If it edits files or runs code, it also needs a controlled execution environment.

That surrounding machinery is the harness.

With the Agents API, OpenAI’s harness can:

• run commands and code in a sandbox;
• apply instructions and reusable skills;
• connect to external systems through tools or MCP;
• accept guidance while the agent is working;
• compact earlier work as the context grows;
• split work into subtasks for subagents; and
• resume a session where it stopped.

These features are not individually new ideas. What is new is the packaging. OpenAI is turning the agent runtime behind Codex into something another product can consume through an API.

How it differs from the Responses API and Agents SDK

The similar names make this easy to misunderstand. OpenAI’s own runtime comparison gives a useful way to separate the three options.

• Responses API: use it when you want to work directly with model responses and control the integration. It provides model output, hosted tools and function calling primitives, but your application owns more of the agent design.
• Agents SDK: use it when you want a library inside your application to manage an agent loop, reusable agents, tools and handoffs. Your application still owns the runtime, deployment and storage choices.
• Agents API: use it when you want OpenAI to run the Codex harness, maintain session progress and provide the managed agent infrastructure.

The difference is therefore not simply API versus SDK. It is where orchestration runs and who is responsible for keeping it alive.

With the Responses API, you are closest to the model. With the Agents SDK, you have a framework for running an agent in your own application. With the Agents API, you move more of that runtime behind an OpenAI service boundary.

The environment is a separate choice

A managed harness does not necessarily mean OpenAI must host the machine on which the agent works.

The Agents API architecture separates the harness from the execution environment. A session can use:

• no environment when the agent only needs remote tools or external services;
• an OpenAI-hosted sandbox when it needs to run scripts, edit files or create artifacts; or
• a self-hosted environment when it needs private infrastructure, a custom software stack or access to an internal network.

That separation is important. Your infrastructure can execute the commands while OpenAI still runs the harness that decides which command to request next. Self-hosting the environment gives you control over compute and files, but it does not make the entire agent self-hosted.

In the self-hosted option, your application also owns more operational work: provisioning the environment, connecting it to the session, handling reconnection, deciding what to preserve and shutting it down safely.

What changes for developers

The most immediate change is that some previously necessary engineering becomes a service configuration decision.

Imagine an incident-response agent. It receives an alert, checks recent deployments, searches logs, writes a diagnosis, asks a human to approve a recovery action and continues after that approval.

Building that workflow directly involves more than prompts. You need durable state, progress events, tool-call handlers, retry behaviour, context management, approval boundaries and an execution environment. You also need to reconnect the user to the same work if the process lasts longer than a web request.

The Agents API can take responsibility for the session and harness. That should let the product team spend less time assembling generic agent infrastructure.

It does not remove the difficult product decisions. The team still has to decide:

• which tools the agent is allowed to call;
• which credentials and data each tool can access;
• which actions require human approval;
• how the product communicates progress and uncertainty;
• how success and failure will be evaluated; and
• what evidence must be retained for debugging or audit.

The plumbing gets smaller. The responsibility does not.

What the API does not take over

The phrase ‘managed agent’ can sound more complete than it is.

Your application remains part of the runtime. It submits tasks, receives streaming events or webhooks and handles application-defined function calls. If one of those function handlers is unavailable, the agent may be left waiting. If you choose a self-hosted environment, your code also manages its lifecycle.

The Agents API also cannot decide what good performance means for your product. A document reviewer, coding agent and customer-support agent need different evaluations, permissions and escalation rules. Those are properties of the application, not features a generic harness can infer safely.

This is why I would treat the API as managed infrastructure, not outsourced product judgement.

The current constraints matter

There are practical constraints to consider before treating the API as the default for every agent.

OpenAI currently states that Agents API sessions retain state, although sessions and published artifacts can be deleted. The service currently supports data residency only in the United States and does not support Zero Data Retention. Using a self-hosted sandbox does not change that because the harness and session still run through the managed Agents API.

Pricing also has several parts. Model usage follows the selected model’s API rates, OpenAI tools use their standard rates and an OpenAI-hosted sandbox adds container charges. A useful cost model therefore needs to include the length of the work, tool usage and environment time, not just input and output tokens.

For many prototypes and production workloads, that trade may be reasonable. For a system with strict regional processing, retention or infrastructure requirements, it may rule the service out before technical fit is even discussed.

What it means for the agent platform market

I recently wrote about who might own the agentic stack. The conclusion was that there will probably be winners at several control points: models, runtime, cloud, data, governance and business workflow.

The Agents API is a concrete move by a model provider into the runtime control point.

OpenAI can now offer the model and the harness as one managed path. That is attractive because the default integration is often more powerful than an abstract platform argument. If a team can move from a model call to a durable, tool-using agent without operating the surrounding machinery, the model provider has become harder to replace.

Independent frameworks and cloud platforms still have reasons to exist. Teams may want provider neutrality, deeper control, a different deployment boundary or one operational layer across several models. The launch does not settle ownership of the agentic stack. It makes the competition clearer.

When I would consider using it

The Agents API looks most relevant when the work is long-running, stateful and tool-heavy, especially when it benefits from files, code execution, progress events or parallel investigation.

I would evaluate it for workflows such as incident investigation, repository maintenance, data analysis, document review and internal operations. In each case, the value is not that the model can produce text. It is that the work continues through several steps and may need to pause, resume or ask for input.

Before adopting it, I would ask five questions:

1. Are we removing real undifferentiated work? A managed harness is most valuable when sessions, recovery and environments would otherwise become a meaningful platform project.
2. Does the data boundary fit? Check residency, retention and the information that will pass through the session, not only where the sandbox runs.
3. Where will tools and credentials live? Map every action to the application, OpenAI-hosted environment or self-hosted environment that executes it.
4. How will we inspect and evaluate a run? A durable session is useful, but it is not automatically a useful quality measure.
5. What would make us leave? Know which parts are portable and which depend on the managed harness before the dependency becomes invisible.

The real launch is the runtime boundary

The easiest way to describe the Agents API is that OpenAI has launched a managed way to build long-running agents with the Codex harness.

The more useful interpretation is that the boundary of the model API is expanding.

Developers once called a model and built most of the surrounding system themselves. They can now ask the provider to preserve the session, operate the loop, manage context, coordinate subagents and supply a sandbox. That can remove a great deal of repeated infrastructure work.

It also makes the harness a strategic dependency rather than an internal implementation detail.

Use the Agents API when the harness is plumbing. Keep control of the tools, permissions, evaluations and product behaviour that make your agent worth building.