OpenAI introduced the Agents API public beta on September 10, 2026. The core product is not another model endpoint. It exposes the agent harness behind Codex and ChatGPT Work as a developer-facing foundation. OpenAI’s premise is that an agent capable of real long-horizon work must manage context, tools, files, execution environments, and subagent coordination—not just wrap one model response in an API.
The entry point is intentionally small: a developer can specify the task, model, tools, and environment in one API call to create an agent session. The Agents API supports MCP, custom functions, and built-in web search, and can connect capability directories, files, skills, plugins, and secret stores. That puts reasoning and execution in one operating unit, while the application and environment still determine which tools are actually available.
OpenAI separates the harness from the compute environment. Developers can choose an OpenAI-managed sandbox, their own infrastructure, or partner environments from Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. Those options can differ in VPC deployment, file and secret storage, CPU, GPU, memory, cold-start, and cost profiles. An organization can therefore adopt a common agent workflow without automatically moving every data and execution boundary to one provider.
The OpenAI-hosted sandbox targets teams that want a faster start. It uses the sandbox infrastructure behind Codex and ChatGPT so agents can run code, work with files, and produce artifacts. Developers can provide packages, skills, and plugins for a task. A sandbox is not permission to let an agent read and write everything, though. Production deployment still needs separate file, network, credential, and output boundaries, along with a recoverable execution environment.
Long-running work is where the runtime earns its place. The Agents API automatically compacts earlier context as a session approaches its limit, allowing workflows to span multiple context windows. Tool search loads relevant tool definitions when needed to reduce unnecessary tokens and cost. Programmatic tool calling can run calls in parallel, chain operations, and filter results in code before bringing the useful subset back into context. These are runtime engineering problems, not issues that disappear when a model is upgraded.
Multi-agent support is part of the harness as well. The API can split a complex task into independent pieces, run focused subagents with their own context in parallel, and have a main agent coordinate the results. That can reduce waiting in research, analysis, and coding workflows. It also creates new failure modes around cost, duplicate work, permission propagation, and result merging. Each subagent should have explicit inputs, outputs, tools, and stop conditions before a team increases concurrency.
OpenAI says the Agents API is available to all developers in public beta with no additional API fee beyond the normal cost of the tokens and tools used. The post includes customer examples involving evaluations, case review, logistics, and cross-tool workflows, but these are vendor-provided early cases rather than independently reproduced effectiveness studies. Teams should measure success, human intervention, latency, tokens, retries, sandbox cost, and data-exposure risk on their own tasks before adoption.
The larger shift is that agent competition is moving from which model answers best to which platform supplies a complete, upgradeable, observable execution layer. OpenAI combines an open-source Codex harness with managed runtime options, shortening the path from prototype to long-running work. Enterprises still own their permission, approval, logging, rollback, and accountability boundaries. The API makes agents easier to build, which means those governance decisions become architectural decisions earlier.
