OpenAI's Agents API moves the agent harness out of your codebase

OpenAI introduced the Agents API on September 10, 2026 — a managed cloud service, in public beta, that runs the same harness and infrastructure behind Codex and ChatGPT for Work behind a single API call.

I want to walk through what that means concretely, because "agent API" has become a crowded label. This one is specific: OpenAI is no longer just shipping a model you call in a loop. It's shipping the loop.

What actually shipped

A single call to client.beta.agents.sessions.create() now creates a running agent session: you specify a model, a set of tools (MCP servers, custom functions, built-in web search), an environment, and an input task. OpenAI's infrastructure takes it from there — executing tool calls, managing context, and returning results to a workspace directory you designate.

The part worth pausing on is the environment choice. You can run the agent in an OpenAI-hosted sandbox (the same sandboxing infrastructure behind Codex and ChatGPT), in your own VPC, or on a partner's infrastructure — OpenAI names Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel as launch partners. That's a deliberate separation: the harness (how the agent reasons, calls tools, manages context) is OpenAI's product; the execution environment (where code actually runs, what it can touch) is a decision you still make per workload.

The part I'd actually call new

Most "agent framework" announcements are really prompt-orchestration libraries — reasonable defaults for a loop you were already going to write yourself: call the model, parse the tool call, execute it, feed the result back, repeat, watch the context window, compact when it gets full. Every team building agents in production has written a version of this, and every version rots a little differently.

The Agents API removes that loop from your codebase and puts it behind a versioned service boundary. Three specific capabilities back that up:

• Context compaction. As a session approaches its context limit, the API automatically compacts earlier context, preserving what the agent needs to keep going — without you writing your own summarization-and-truncation logic for sessions that run for hours or days.
• Tool search and programmatic tool calling. Tool search loads tool definitions on demand rather than stuffing every schema into the prompt up front, which keeps token usage and cache hit rates sane as the tool count grows. Programmatic tool calling lets the agent run calls in parallel, chain them, and filter results in code, so bulk data work doesn't have to round-trip through the model's context.
• Native multi-agent support. Setting multi_agent.enabled lets a session delegate independent pieces of a task to subagents that run concurrently, each with its own context, with the parent coordinating and merging results. This used to require you to build your own dispatch-and-merge layer on top of whatever framework you'd chosen.

That last one is the detail I'd flag if you've built agent orchestration by hand: subagent coordination is exactly the kind of code that's simple in a demo and miserable in production — you end up hand-rolling supervision, partial-failure handling, and result aggregation. Several of the customer quotes in OpenAI's launch post are specifically about that pain: Ciridae reports a 4x latency reduction on subagent workflows they'd previously found "cumbersome to observe and orchestrate," and Hypha reports an 86% reduction in failed agent responses after separating the harness from the sandbox.

Why the open-source harness matters

The Agents API runs on the open-source Codex harness — the same codebase, publicly inspectable, that OpenAI operates and maintains for you. That's a different trust model than a black-box hosted agent: you can read the orchestration logic that decides how your agent uses tools and manages context, even though you're not the one running it. It also means the harness improves with each model release without you reworking your integration — versioned access to harness capabilities is part of the pitch, since reworking your own orchestration layer every time a new model ships is exactly the kind of maintenance tax this product is targeting.

The tradeoff worth naming

Hosted orchestration means less code to own, but it also means your agent's core reasoning loop now lives on OpenAI's infrastructure and versioning schedule rather than in your repo. For teams that have already sunk real engineering time into a custom harness, or that need orchestration logic they fully control for compliance reasons, that's a real cost, not just a migration hassle. For everyone else — and I'd guess that's most teams shipping agents today — the calculus is straightforward: hand-rolled context management and subagent dispatch are undifferentiated work. If OpenAI is willing to operate and version that layer for the price of tokens and tools with no extra platform fee, building it yourself needs a specific justification, not just inertia.

The Agents API is in public beta today, available to all developers, with pricing limited to token and tool usage. If you're currently running your own agent loop in production, this is worth a prototype before your next harness rewrite.