OpenAI’s Agents API brings the Codex harness to developers as a managed runtime for long-running AI agents.
It supports session handling, sandboxed execution, tool use, context compaction, and multi-agent orchestration.
The platform is aimed at complex workflows such as document processing, coding, research, and other multi-step tasks.
Building an AI agent used to mean assembling a model, a memory system, a tool-calling loop, and enough supporting code to stop the whole setup from breaking mid-task. OpenAI's Agents API, announced on 10th September 2026, changes that picture. It moves much of the agent harness and session infrastructure into a managed service, so developers spend less time on plumbing and more time on what the agent actually does.
The term 'harness' gets used loosely across the agent space. A harness is the control layer around the model. It decides what context the model sees at each step, which tools it can call, how tool results feed back into the conversation, and how work continues across many turns instead of a single exchange. The model supplies the reasoning. The harness turns that reasoning into a workflow that can survive pauses, retries, and long stretches of unattended running.
The Agents API brings the harness that already runs Codex to developers through a general-purpose service. OpenAI built it to keep agents running reliably for days, not hours, with environments where they can work across files, run code, and save results as they go. The service manages the harness and session state directly. Developers still choose where execution happens, using either an OpenAI-hosted sandbox or their own infrastructure.
Automatic context compaction trims older parts of a long session so extended workflows do not run into token limits. Subagent support lets one agent hand off narrower pieces of work to others and combine the results afterwards. Programmatic tool calling allows an agent to chain tool use through code rather than relying only on natural-language reasoning between steps.
The API also connects to Model Context Protocol servers, giving agents a standard way to reach external tools and data. MCP simplifies that connection, but it does not remove the need to set clear limits on what those tools can access.
Execution runs inside a sandbox, hosted by OpenAI or self-hosted depending on how much control a team needs. A sandbox is not just a safety label. It sets the real boundary of what an agent can do: which files it can touch, what network access it has, and when a human needs to approve an action before it goes through. For enterprise deployments, that boundary often matters as much as the model's raw ability.
Getting a model to call a tool once is the easy part. Keeping a workflow reliable afterwards, across many tool calls, failures, and days of runtime, is where most custom agent projects run into trouble. As tasks stretch longer, those challenges turn into infrastructure problems: managing state, recovering from failure, running code safely, and knowing when a task is done.
The Agents API absorbs much of that work, which shifts the developer's focus from building an agent loop to defining the tools, permissions, and workflows that make the agent worth using. OpenAI can also update the harness alongside new model releases, so teams are not forced to rebuild their agent loop every time model capability improves.
OpenAI now offers three separate starting points rather than one API layered beneath another.
| Factor | Agents API | Agents SDK |
|---|---|---|
| Who runs the harness | OpenAI, fully managed | Runs inside the developer's application |
| Session state | Handled by OpenAI | Managed by the developer or app storage |
| Sandboxing | Built in, hosted or self-hosted | Configured by the developer |
| Integration effort | Low | Medium to high |
| Best fit | Long-running, infrastructure-heavy tasks | Custom workflows needing full control |
The Responses API sits at a lower level than both, offering direct access to model and tool calls for teams building orchestration from scratch. The right pick depends on how much infrastructure control a project actually needs, not on which option looks fastest to prototype.
Consider a request to review fifty enterprise accounts for renewal risk. An agent on this runtime could query the CRM, pull recent support activity, retrieve contract data, hand trend analysis to a subagent, combine the findings into a report, and pause for approval before contacting a customer. The model decides what happens next.
The tools reach into company systems. The subagent handles a parallel slice of work. The harness keeps the sequence moving without the developer rebuilding state after each step.
Also Read: OpenAI API Pricing: Costs, Tokens, and Pricing Calculator Guide
Document-heavy, long-running workflows are an obvious early fit, especially tasks where an agent must review large volumes of information while preserving context across many steps. Coding tasks suit the platform naturally given the shared Codex harness, and multi-agent research is a growing pattern, helped by built-in orchestration instead of manual coordination across separate calls.
OpenAI is also retiring Agent Builder and Evals after November 30, 2026, pointing code-based workflows toward the Agents SDK. Teams evaluating this stack today are really choosing between a managed runtime and a code-first approach.
Also Read: OpenAI Batch API and Rate Limits: Efficiently Handling Large-Scale API Requests
The bigger shift is not that OpenAI added another API for agents. It is that the infrastructure around the model, the harness, the sandbox, and the session state is becoming part of the agent itself. Teams are no longer deciding only which model to use. They are deciding how much of that runtime they want to own, and as agents take on longer, real operational work, that decision may carry as much weight as the model itself.
The OpenAI Agents API is a managed runtime for building AI agents that can handle long-running, multi-step tasks. It provides infrastructure for session state, tool use, orchestration, context management, and sandboxed execution.
The Agents API is a managed runtime operated by OpenAI, while the Agents SDK is an open-source framework that runs within a developer's own application. The API reduces infrastructure work, while the SDK provides greater control over the agent loop and deployment.
The Codex harness is the control layer around the AI model that manages context, tools, execution, and the agent loop. The Agents API brings this infrastructure to developers as a general-purpose runtime for building agents beyond coding.
Developers can build agents for coding, research, document processing, data analysis, customer operations, and other workflows that require multiple steps and tools. Multi-agent workflows can also divide complex tasks among specialized agents.
Yes. The Agents API can connect with Model Context Protocol (MCP) servers, allowing agents to access external tools and data through a standardized interface. Developers still need to define appropriate permissions and access boundaries for those tools.