--- title: "OpenAI’s Agents API Turns the Codex Harness Into Managed Infrastructure" description: "The September public beta moves context management, tool orchestration, subagents, and long-running session state behind a managed API while leaving execution environments configurable." date: 2026-09-15 topic: agents tags: ["agents-api","codex","agent-harnesses","mcp","sandboxing"] production: ai-assisted source: https://notes.suffro.com/posts/agents-api-managed-codex-harness --- # OpenAI’s Agents API Turns the Codex Harness Into Managed Infrastructure OpenAI’s September 10 release of the Agents API is more consequential than another agent SDK. It turns the harness behind Codex into a managed service, moving a substantial part of the agent loop from application code into provider-operated infrastructure. According to the [launch announcement](https://openai.com/index/introducing-the-agents-api/), developers specify a task, model, tools, and execution environment while OpenAI runs the orchestration layer that coordinates model calls, context, tool use, and subagents. The public beta is available to developers without a separate orchestration fee; model, tool, and execution costs still apply. That changes where agent engineering lives. Instead of every application rebuilding its own long-running loop, context-compaction logic, tool router, subagent scheduler, and recovery path, those mechanisms can now be consumed as infrastructure. ## Long sessions become a managed primitive One of the harder problems in agent systems is not getting a model to take one action. It is keeping useful state intact after dozens or hundreds of actions. The Agents API includes automatic context compaction as a session approaches its context limit. OpenAI says the harness summarizes or restructures earlier context so the agent can continue across multiple context windows without the application implementing its own compaction layer. This is a meaningful architectural change because context management is part of agent behavior, not just storage. A long-running agent has to preserve goals, decisions, constraints, intermediate findings, and unresolved work while discarding enough detail to stay within a finite context window. Moving that logic into the harness reduces bespoke application code, but it also moves a correctness-sensitive mechanism behind a managed interface. The launch material does not provide an independent benchmark of how well information survives repeated compaction over long tasks, so the feature should not be read as evidence that multi-hour or multi-day agents are automatically reliable. ## Tool use is treated as a scaling problem The release also addresses a second bottleneck: agents with many available tools. The [OpenAI announcement](https://openai.com/index/introducing-the-agents-api/) describes tool search that loads relevant tool definitions only when needed instead of placing an entire tool catalog into the active context. The API also supports programmatic tool calling, where the agent can call tools in parallel, chain operations, and process intermediate results in code before returning only the useful subset to the model. The supported tool surface includes MCP servers, custom functions, and built-in tools such as web search. This matters because large tool catalogs create two separate costs. They consume context, and they increase the number of choices the model has to reason over. Lazy tool discovery is therefore not merely an API convenience; it is an attempt to make tool-rich agents more tractable without permanently paying the context cost of every possible capability. ## Subagents are part of the harness Multi-agent orchestration is also built into the API. A main agent can delegate independent pieces of work to subagents that run in parallel. Each subagent keeps its own context, while the main agent coordinates the assignments and combines their results. The launch examples expose concurrency controls directly in the agent configuration. That is technically different from an application manually spawning several independent model calls. The managed harness owns the delegation lifecycle and context separation, which makes parallel research, coding, and analysis workflows easier to express. OpenAI includes customer quotes reporting large latency or reliability improvements after adopting the system, but those numbers are vendor-selected testimonials rather than independently reproduced evaluations. The stronger evidence in the launch is architectural: subagent coordination is now a first-class API capability rather than something every developer has to implement around the model. ## Orchestration and execution are deliberately separated The API does not require the agent’s code execution to happen inside OpenAI infrastructure. Developers can use an OpenAI-hosted sandbox, their own environment, or one of several integrated sandbox providers. The [developer announcement](https://community.openai.com/t/introducing-the-agents-api-and-hosted-sandboxes/1396481) lists options that vary by CPU, GPU, memory, storage, deployment model, and VPC support. OpenAI’s hosted sandbox can run code, manipulate files, install packages, use skills or plugins, and produce artifacts. The company says it uses the same sandboxing infrastructure as Codex and ChatGPT. This separation is one of the more useful parts of the design. The managed harness owns the agent loop, but the environment where code and files live can remain under the developer’s control. That gives teams a way to adopt managed orchestration without necessarily moving every execution workload into the same provider boundary. It does not remove the usual safety and systems concerns around tools. A sandbox limits where code runs; it does not by itself prove that an external API call was correct, that permissions were appropriate, or that a long workflow reached the intended final state. ## The agent harness is becoming a product layer The release also makes explicit something that agent builders have increasingly encountered in practice: model quality and harness quality are separate engineering problems. OpenAI says the API is powered by the open-source [Codex repository](https://github.com/openai/codex), while the hosted service operates and evolves the harness on the developer’s behalf. That means the coordination logic is inspectable at a high level, but the production experience is still a managed service whose behavior can change as the beta evolves. For developers, the tradeoff is straightforward. A managed harness can remove a large amount of undifferentiated orchestration code and make features such as compaction, tool discovery, and subagents available without building them from scratch. At the same time, more of the application’s behavior now depends on a provider-maintained execution layer rather than code owned entirely by the application team. The cost model deserves similar care. The Agents API itself adds no orchestration surcharge, but long sessions, repeated model turns, tool calls, hosted containers, and parallel subagents still consume billable resources. [The New Stack’s September 11 coverage](https://thenewstack.io/openai-agents-api-compute/) highlighted exactly this point: lowering the engineering friction around long-running agents can make it easier to create workloads whose inference use grows quickly. ## What changed for agent builders The important development is not that OpenAI launched another way to call a model. It is that several pieces that were previously application architecture have been bundled into a managed agent runtime. Context compaction, tool discovery, parallel tool execution, subagent orchestration, durable sessions, and sandbox integration are now offered as one coherent layer. That can materially reduce the amount of infrastructure required to build serious agents. The limitations are equally important. The system is still in public beta, the launch evidence is dominated by first-party material and selected customer reports, and there is not yet an independent evaluation showing how the managed harness behaves across long, failure-prone workflows. For now, the Agents API is best understood as infrastructure rather than proof of autonomy: it standardizes more of the machinery needed to keep agents working, but it does not remove the need to evaluate what those agents actually do. ## Sources - [OpenAI, "Introducing the Agents API"](https://openai.com/index/introducing-the-agents-api/) - [OpenAI Developer Community, "Introducing the Agents API and hosted sandboxes"](https://community.openai.com/t/introducing-the-agents-api-and-hosted-sandboxes/1396481) - [OpenAI Codex repository](https://github.com/openai/codex) - [The New Stack, "OpenAI’s researchers burned $7,000 a day on AI agents — now it’s opening the floodgates"](https://thenewstack.io/openai-agents-api-compute/)