OpenAI’s Agents API turns the Codex harness into a service. The environment boundary is the real decision

What launched, and what OpenAI is actually selling

On 10 September 2026, OpenAI released the Agents API in public beta to all developers. The short description is accurate: this is the managed harness behind Codex exposed as an API.

That distinction matters. A model API accepts input and returns output. A useful software agent also needs a durable session, a place to run code, a way to recover after interruption, rules for loading tools, context management across long work, and some method of dividing a job between specialist workers. Teams have been building that layer themselves. OpenAI is now offering it as infrastructure.

The launch example creates a session by supplying four things: a task, a model, tools and an environment. The harness can then compact context, select and call tools, coordinate subagents, stream events, preserve artifacts and resume work. OpenAI says the service uses the same evolving Codex harness it operates for its own products.

The important word is harness. OpenAI is not simply selling another chat endpoint. It is trying to become the control plane between a model and the computers, credentials, files and services on which an agent acts.

The architecture in one diagram

The diagram separates four planes because treating them as one product hides the operational choices.

Your application supplies the user experience, the task, business policy and approval rules. The managed harness handles the agent loop: context, tools, recovery and delegation. The environment is the computer on which files and commands exist. The tool and state planes connect the agent to external authority and preserve the evidence of what happened.

OpenAI currently supports an OpenAI-hosted sandbox, a self-hosted environment, and integrations with sandbox providers. That means adopting the API does not require surrendering every workload to one compute boundary. It also means that “we use the Agents API” says very little about where customer data, source code or secrets actually run.

What OpenAI manages, and what the buyer still owns

The responsibility split described by OpenAI’s launch post and Agents API documentation.

Layer	Agents API supplies	The developer must decide
Harness	Context compaction, recovery, tool selection, steering and subagent coordination	Instructions, success criteria, approval points and failure policy
Model	Access to the selected OpenAI model through the managed session	Model choice, service tier, token budget and evaluation threshold
Environment	Interfaces for hosted, self-hosted or partner sandboxes	Where files execute, network access, persistence, isolation and cleanup
Tools	MCP, custom functions, web search and programmatic tool calling	Credentials, least privilege, allowlists, rate limits and write confirmation
State	Sessions, events, items and artifacts that can survive a turn	Retention, export, audit evidence, incident response and deletion requirements
Parallelism	Built-in delegation to multiple subagents	Concurrency limit, duplicate work, aggregate cost and permissions inherited by workers

This is a favourable split for teams that already know their boundaries. It can be dangerous for teams that read “managed” as “governed”.

The harness can decide how to call a tool efficiently. It cannot decide whether that tool should carry production write access. It can recover a session. It cannot decide how long the session’s accumulated context should remain available under your data policy. It can create subagents. It cannot know whether four workers reading the same customer repository violate a contractual restriction.

The managed layer removes orchestration code. The governance layer remains yours.

The technical shape: one session binds model, tools and computer

The official overview shows the design clearly. A session is created with an agent definition and an environment. Tools, including remote MCP servers, sit inside the agent definition; the sandbox sits beside it. A reduced JavaScript example looks like this:

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [{
      type: "mcp",
      server_label: "operations",
      transport: {
        type: "http",
        server_url: "https://example.com/mcp"
      }
    }],
    multi_agent: {
      enabled: true,
      max_concurrent_subagents: 3
    }
  },
  environment: {
    type: "openai_hosted"
  },
  input: "Investigate the incident and save the evidence."
});

Three consequences follow from that object.

First, MCP becomes part of application architecture. The server is not an optional convenience once it can publish content, change a ticket or query a customer system. Its authentication, scopes and tool descriptions are production controls.

Second, the environment is explicit. Files and commands do not float abstractly inside the model. They exist in an OpenAI-hosted container, your own infrastructure or a partner sandbox, each with a different network, storage and forensic story.

Third, parallelism is a configuration choice. Subagents can reduce elapsed time because independent work runs together. They can also multiply tool calls and token use. A concurrency number is therefore a cost and risk limit as much as a performance setting.

The API fee is zero; the operating bill is not

OpenAI says there is no additional fee for the Agents API itself. The service is billed through the models, tools and environment it consumes. The documentation says model usage uses the selected model’s API rates, OpenAI tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates.

That makes “free orchestration” true and incomplete. A long-running agent can accumulate model tokens across many turns, open containers for extended periods, search the web, call paid tools and fan work out to subagents. The useful unit is cost per completed, verified task, not the price of the first prompt.

Selected standard short-context model prices per one million tokens, captured from OpenAI’s pricing page on 12 September 2026. Prices can change.

Model	Input	Cached input	Output
GPT-6 Astra	$5.00	$0.50	$25.00
GPT-5.6 Sol	$2.00	$0.20	$10.00
GPT-5.6 Terra	$1.00	$0.10	$6.00
GPT-5.6 Luna	$0.10	$0.01	$0.60

The five controls to set before production

1. Choose the environment from the data backwards. Decide which files, secrets and records the task needs, then choose hosted, self-hosted or partner execution. Do not start with convenience and retrofit the boundary later.

2. Give each MCP server its own identity and scopes. Reading a knowledge base, preparing a draft and publishing to production are different grants. Separate credentials make revocation and audit possible.

3. Put human approval on consequential writes. The harness can continue for hours and recover after interruption. That durability increases the value of explicit approval before publication, deletion, payment or production configuration changes.

4. Treat retrieved text as untrusted input. Web pages, tickets, documents and tool responses can contain instructions aimed at the agent. Restrict which tools can follow retrieved content and keep secrets out of contexts that do not need them.

5. Retain the events that prove the result. A final answer is not an audit trail. Preserve the tool call, target, returned status, artifact digest and approval event needed to reconstruct the change without retaining unrelated sensitive context forever.

These controls are familiar because the underlying problem is familiar. An agent is a service account with reasoning, memory and a computer. The novelty is the speed and autonomy with which it can use them.

The position

The Agents API is consequential because most agent failures are no longer failures of raw model intelligence. They are failures of continuity, tools, state, environment and recovery. OpenAI has productised that layer and attached it to the harness already refined through Codex.

For a small team, this can remove months of orchestration work. For a larger organisation, it can establish a common control plane across agents that previously arrived as separate scripts and vendor frameworks. Both are real advantages.

The mistake would be to outsource the harness and assume the risk went with it. The environment still determines where work happens. MCP still determines what the agent can touch. Session policy still determines what persists. Events still determine whether an auditor can tell success from a convincing answer.

The buying question is therefore not “can it run an agent?” It plainly can. The question is whether you can state, before the first production session, where it runs, what it can change, what one completed task costs, and which evidence proves the change was authorised.