OpenAI has released the OpenAI Agents API in public beta, giving developers a managed way to build AI systems that can plan, use tools and continue complex work over multiple steps. Announced on 10 September 2026, the service puts the Codex agent harness behind an API while OpenAI handles much of the session infrastructure that teams previously had to assemble themselves.
The launch is important because the difficult part of an AI agent is rarely a single model call. Useful agents need state, tool access, secure execution, progress streaming and recovery when work takes longer than expected. The new API aims to provide those building blocks as a hosted service.
What is the OpenAI Agents API?
The Agents API is a managed runtime for long-running, multi-step agent tasks. OpenAI’s documentation says it runs the Codex harness and manages the underlying infrastructure, allowing developers to concentrate on an agent’s instructions, tools and business logic.
Its core capabilities include automatic context compaction, multi-agent orchestration, programmatic tool calling and support for Model Context Protocol (MCP) servers. It also saves session configuration, turns and items so an agent can maintain continuity across tasks.
This makes the API distinct from two existing options. The Agents SDK runs the agent loop inside the developer’s application and provides more control over deployment, storage and approvals. The Responses API operates at a lower level for teams that want to call models directly or build their own orchestration. The Agents API is the lower-integration option when OpenAI should manage the runtime and state.
What changed with the public beta?
The public beta makes the managed Codex harness available to all developers rather than limiting it to selected users. According to OpenAI’s changelog, developers can create durable sessions, stream progress, connect private tools and MCP servers, and choose where code execution happens.
Durable sessions for longer work
An Agents API session contains the agent configuration, conversation turns and generated items. Developers can continue a session instead of repeatedly rebuilding history for every request. Automatic context compaction is designed to keep long workflows manageable when they approach a model’s context limits.
This is especially useful for work that unfolds over several stages, such as analysing a repository, preparing a report from multiple data sources or coordinating a support investigation.
Hosted and self-hosted sandboxes
Agents can run in an OpenAI-hosted sandbox, a self-hosted sandbox or without a sandbox. The official quickstart demonstrates a coding assistant that creates and runs a Python script in an OpenAI-hosted environment. Teams with stricter data, network or compliance requirements can instead connect infrastructure they control or use a supported provider.
Tools, MCP and multiple agents
The runtime can connect to service tools, application-defined function handlers and MCP servers. It also supports delegation among agents, enabling specialised workers to cooperate on parts of a larger task. These features reduce the amount of custom orchestration code required for tool selection, hand-offs and execution tracking.
Why the Agents API matters
Agent prototypes are easy to demonstrate but difficult to operate reliably. Production systems need to preserve state, retry failed steps, control credentials, capture logs and separate model reasoning from executable actions. A managed harness turns several of those infrastructure problems into platform features.
For startups, this could shorten the path from proof of concept to a working product. For larger organisations, it provides a more standard architecture for tasks such as software maintenance, research, document processing and operational automation. Developers can also stream events to an interface, giving users visibility while a long-running task is in progress.
The release also signals a broader shift in the AI market: model providers are moving beyond text-generation endpoints toward complete execution runtimes. Competition will increasingly focus on how securely and reliably models can act, not only on benchmark scores.
Practical impact for developers and businesses
A software team could use the API to build an assistant that inspects a codebase, edits files in a sandbox, runs tests and returns verified results. A business intelligence workflow could collect approved data, invoke analysis tools and produce a report while preserving its session across follow-up questions. Customer-support teams could connect internal functions so an agent gathers account context before recommending a next step.
OpenAI’s quickstart shows that requests currently use the beta Agents namespace in its SDKs. Direct HTTP requests require the OpenAI-Beta: agents=v1 header. Applications also need appropriately scoped permissions for agent reads and writes, plus model-inference access. Because the product is in beta, teams should isolate integrations behind their own service layer rather than coupling critical systems tightly to an interface that may change.
Risks, limitations and security concerns
A managed runtime reduces engineering work, but it does not remove responsibility for agent safety. Any agent that can execute code or call business tools can make costly mistakes if permissions are too broad. Developers should apply least-privilege credentials, restrict network access, validate function arguments and require human approval for destructive or irreversible actions.
Prompt injection remains another major concern. Untrusted web pages, documents and tool responses can contain instructions intended to redirect an agent. Teams should treat retrieved content as data, separate it from system policy and enforce authorisation outside the model.
There are also architectural trade-offs. A hosted harness means greater dependence on OpenAI’s platform, operational limits and future pricing. Self-hosted execution may improve control but transfers more security and maintenance work back to the customer. Organisations should evaluate retention, regional availability, auditability and compliance requirements before processing sensitive information.
What to watch next
The most important near-term questions are how the API evolves after beta, what service limits and pricing apply at scale, and which observability controls become available for production deployments. Developers should also watch for changes to SDK namespaces, sandbox policies, MCP integrations and approval workflows.
Real-world reliability will matter more than polished demos. Useful benchmarks should measure task completion, recovery from tool failures, cost per successful workflow and the frequency of human intervention—not simply model accuracy on isolated prompts.
Conclusion
The OpenAI Agents API gives developers a higher-level route to building AI agents without owning every part of the orchestration stack. Durable sessions, managed context, tool integration and flexible sandboxes address genuine engineering problems, particularly for coding and other long-running workflows.
However, public beta means teams should adopt it deliberately. Start with narrow tasks, minimal permissions, comprehensive logs and clear approval gates. If OpenAI can combine convenience with dependable controls, the API could become a practical foundation for the next generation of agent-based applications.