OpenAI Agents API Turns the Harness Into Infrastructure
OpenAI's new Agents API exposes the Codex harness as a managed API for durable sessions, sandboxed execution, MCP tools, compaction, and subagent orchestration.
OpenAI introduced the Agents API in public beta on September 10, 2026. The important part is not that there is another way to call a model. The important part is that OpenAI is exposing the Codex harness itself: durable sessions, environment selection, tool orchestration, context compaction, sandbox execution, MCP connections, observability, and subagent delegation behind one managed API.
That is a real architectural shift for teams building agents. The hard part of a production agent is rarely the first model call. It is the loop around the model: preserving state, deciding where code runs, loading the right tools, resuming after interruptions, tracking what happened, and keeping credentials out of places where generated code can read them. The Agents API is OpenAI saying that this loop is now part of the platform.
What Happened
The September 10 announcement describes the Agents API as public beta access to the same managed harness and infrastructure behind Codex. Developers create sessions by specifying an agent configuration, an execution environment, tools, and input. OpenAI runs the managed Codex harness; the application submits work and receives events or results.
The API is organized around four concepts. An agent is the model, instructions, tools, and MCP servers available to the run. An environment is optional compute where the agent can work with files, run commands, load skills, and create artifacts. A session is a durable instance of that agent. Events and items are the observable stream of inputs, outputs, tool calls, progress, and saved work.
The launch also clarifies the pricing shape. The announcement says there are no additional fees specifically for using the Agents API; developers pay for model tokens and tools. The docs add the operational detail: OpenAI-hosted sandboxes use standard container rates, and model usage is billed separately at the selected model's API rates. In other words, this is not free orchestration. It is orchestration folded into the same platform bill you already need to model.
Availability has beta caveats. The overview currently says the Agents API supports data residency only in the United States and does not support Zero Data Retention. Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible. That matters for regulated workloads, and it is exactly the sort of footnote engineers should read before moving sensitive agent execution into a managed harness.
Why It Matters
Most agent systems fail in the plumbing. The happy-path prototype is easy: call a model, give it tools, parse output. The production system is where the edges multiply. A long task may need to run for minutes or hours. The user may disconnect. A tool call may need approval. The model may need more context than fits in the window. The agent may need to split work into independent investigations. A tool catalog may be too large to paste into every turn. A sandbox may need files, packages, network policy, and a cleanup lifecycle. Observability cannot stop at "the model returned text."
Until now, many teams have built that machinery themselves. Some build it as a queue plus a Responses API loop. Some use an agent framework. Some build a custom worker that wraps shell access, MCP clients, file storage, and a homegrown trace format. That can be the right decision when the agent is core product infrastructure, but it is expensive and easy to underbuild.
The Agents API moves the boundary. Instead of outsourcing only inference, you can outsource a large part of the harness: the stateful loop that turns model capability into a running agent. Your application still owns the product workflow, UI, domain tools, authorization model, environment choice, and safety policy. But OpenAI now owns more of the session machinery.
That changes build-versus-buy decisions. If your differentiation is a scheduling system, observability product, legal review flow, incident bot, or internal support workflow, rebuilding a durable agent runtime may be yak shaving. If your differentiation is the runtime itself, you may still keep more in-house. The existence of a managed harness makes that decision more explicit.
It also makes environment placement a first-class API choice. Agent compute is no longer a hidden side effect of "the model called a tool." The docs describe three modes: no environment, OpenAI-hosted environment, and self-hosted environment. That is the right abstraction. Not every agent needs a shell. Some need only remote APIs. Some need a disposable Linux workspace. Some need private network access, a custom image, or compute you govern directly.
How It Works
At the architecture level, there are three pieces: the harness, the environment, and your application server.
The harness is the OpenAI-hosted Codex instance that runs the model and tool loop and maintains session state. It can stream events, maintain conversation and saved work over time, summarize earlier work as context pressure grows, and resume a session where it left off. Your application server starts sessions, sends tasks, receives events, handles function tools, and integrates the agent into your product.
The environment is optional. If environment.type is none, the harness can still answer questions and call configured remote tools, including remote MCP servers reachable from OpenAI. But there is no built-in shell, no workspace files, and no apply-patch-style filesystem work. That is a good fit for pure API orchestration or agents that work entirely through service-side MCP connections.
If the agent needs to run scripts, edit files, or produce downloadable artifacts, environment.type can be openai_hosted. OpenAI provisions a Linux workspace with Python, Node.js, and command-line tools. The working directory is /workspace. You can configure packages, setup commands, input files, environment variables, skills, plugins, capability directories, and network access. Network can be enabled, disabled, or restricted to an explicit set of hostnames. Files in /workspace/outputs are published as immutable artifacts at turn completion, so the useful output can outlive the sandbox.
The docs also describe sandbox lifetime in practical terms. Connected sandboxes receive keep-alives, including between turns. If activity and keep-alives stop for an hour, the sandbox can be deleted. Deleting a session requests cleanup, but closing an event stream does not cancel the task. That distinction matters for product code: cancelling UI streaming is not the same thing as stopping the agent.
The third mode is self_hosted. Use it when the agent needs your infrastructure, private network, custom software, or compute profile. Your code starts the environment and connects an executor to the session. The executor runs commands and tools requested by the harness. Your application owns provisioning, reconnection, shutdown, and file persistence. This is the mode I would expect enterprises to evaluate first for agents that need internal repositories, staging services, private package registries, or sensitive network paths.
Tools are also split by where they run. Function tools are handled by your application code. MCP servers can be connected from OpenAI's service or from the session environment. A remote HTTP MCP server with the default service origin does not require an environment. An MCP server reachable only from a private network should connect from the environment. Stdio MCP servers run as processes inside the environment, so they require installed dependencies and an attached sandbox or executor.
Multi-agent support is an API-level capability. When enabled, the harness supplies delegation tools to the main agent. The main agent can create subagents, message them, wait for them, interrupt them, and combine their results. Each subagent has its own context. The docs recommend this for independent work, such as reviewing separate documents or investigating different causes of a failure, while keeping short or tightly dependent steps in the main agent.
Observability is built into the session model. The docs say you can inspect sessions in the Platform dashboard, follow live session events, inspect completed work, identify delegated command execution, and review token usage for root-agent and subagent turns. Trace retrieval and external trace exporters are not part of the public beta API, so teams with mature observability pipelines should treat the current tracing story as useful but not complete.
Example
Consider an incident investigation agent for a service platform. The agent needs to inspect metrics, read recent deploys, check error logs, and write a short mitigation report. Some tools are remote HTTP MCP servers. Some access private infrastructure. You probably do not want to give generated code your application API key. You also do not want every incident investigation to run on a developer laptop.
The Agents API shape would look roughly like this:
import OpenAI from "openai";
const client = new OpenAI();
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions:
"Investigate production incidents using the provided tools. " +
"Delegate independent checks to subagents. Save evidence and " +
"recommendations under /workspace/outputs.",
tools: [
{ type: "programmatic_tool_calling" },
{
type: "mcp",
server_label: "internal_observability",
transport: {
type: "http",
server_url: "https://mcp.internal.example.com/observability",
},
connection_origin: "environment",
required: true,
},
],
multi_agent: {
enabled: true,
max_concurrent_subagents: 3,
},
},
environment: {
type: "self_hosted",
workspace_directory: "/workspace",
capability_directories: ["/workspace/capabilities/skills"],
},
input:
"Investigate the elevated 5xx rate for service-api over the last 30 minutes. " +
"Check recent deploys, dependency failures, and regional error concentration.",
});
console.log(session.id);This is not meant to hide the real engineering work. You still need a secure executor environment, network policy, MCP authorization, a way to surface agent events to operators, and approval gates before remediation. But the shape is clean: your application declares the task, tools, and environment placement; the harness manages the session loop.
Security should be designed around the fact that agent-generated code can access the files, credentials, and network available to its environment. The sandbox security docs recommend isolating workloads, restricting outbound traffic, separating credentials, and keeping third-party credentials outside the environment where possible. The application API key should stay outside the environment. A self-hosted executor uses an environment key as CODEX_API_KEY, and that key is only for connecting environments. Long-lived third-party credentials belong in a secrets manager or broker, not casually injected into a workspace the agent can inspect.
My Take
This is the most interesting kind of platform release: it turns an internal operating model into an external boundary. Developers have been learning the same lesson independently for the last year: an agent is not just a model with tools. It is a runtime, a policy layer, a state machine, a filesystem contract, and an observability problem.
The Agents API does not eliminate those responsibilities. It relocates some of them. That relocation is useful if you trust the managed harness more than your own hastily assembled loop, but it also creates a new dependency on OpenAI's session semantics, beta API maturity, data retention posture, and dashboard-first observability.
The cleanest part of the design is the separation between harness and environment. It lets teams pick a placement strategy per workload. A documentation assistant might use no environment and remote MCP. A report generator might use an OpenAI-hosted sandbox with network disabled and a few pinned packages. An SRE or coding agent touching internal systems probably belongs in a self-hosted environment with narrow egress, short-lived credentials, and an approval model outside the agent's control.
The multi-agent story is also pragmatic. Subagents are not magic. They are useful when work can be decomposed into independent units with crisp expected outputs. They are risky when several workers can mutate the same files or act on the same external system without coordination. The fact that the docs call this out is a good sign. Teams should treat subagents like concurrency, because that is what they are.
My main caution is beta gravity. A managed agent harness can become central infrastructure quickly because it is easier than maintaining your own loop. Before that happens, teams should write down what they are depending on: session durability expectations, artifact retention, data residency, ZDR requirements, cancellation semantics, event schemas, token accounting, and sandbox cleanup behavior. Those details are not paperwork. They are the contract your product will debug at 2 a.m.
Conclusion
OpenAI's Agents API is important because it exposes the agent harness as product infrastructure. It gives developers a managed way to run durable sessions, attach compute when needed, connect MCP tools, compact context, delegate to subagents, stream progress, and inspect usage.
For experienced engineers, the practical takeaway is not "replace your agent stack tomorrow." It is to redraw the architecture diagram. Put the harness, environment, tools, credentials, artifacts, and observability on separate boxes. Then decide which boxes OpenAI should operate and which boxes must remain yours. The Agents API makes that boundary explicit.