Field report · · AgentConn Team
OpenAI's Agents API Is Really a Hosted Codex Harness
MCP, skills, and subagents ship as first-class primitives. The real story is three labs converging on the same agent vocabulary.
OpenAI’s Agents API Is Really a Hosted Codex Harness
OpenAI shipped the Agents API in public beta on September 10, 2026. The pitch is straightforward: one API call gives you the same orchestration layer that runs Codex — sessions, sandboxes, tool execution, context compaction, and multi-agent coordination — without building any of that infrastructure yourself. But the product isn’t the real story. The real story is what OpenAI chose to put inside it: MCP servers as a first-class tool type, skills as the unit of agent capability, and AGENTS.md as the instruction format. Three competing labs have now converged on the same vocabulary for what an agent is and what it does, and nobody called a standards meeting.
Steve Coffey, an OpenAI engineer, announced it as “a brand new way to build Agents in the cloud, backed by the Codex harness.” The framing matters: this isn’t a new model or a new SDK. It’s OpenAI taking the infrastructure that already powers Codex and offering it as a managed service. Think of it as Codex-as-a-Service — you bring the task and the tools, OpenAI runs the loop.
What the Agents API Actually Does
The API is built around four primitives: the Agent (model, instructions, tools, MCP servers), the Environment (optional sandbox), the Session (durable agent instance), and Events/Items (inputs and outputs). Your application sends input and receives events while OpenAI runs the agent and provisions its sandbox.
Here’s what the harness handles for you:
- Context compaction. As a session nears its context limit, the API automatically summarizes earlier exchanges — no application-level state management needed for multi-hour tasks.
- Tool search. Tool definitions load on demand rather than sitting in a static catalog, reducing token cost while preserving model cache hits.
- Programmatic tool calling. Agents can run tool calls in parallel and chain operations without round-tripping to your application.
- Subagent delegation. Complex tasks break into independent pieces delegated to subagents that maintain their own context. You configure
max_concurrent_subagents(default: 4) and the main agent coordinates. - MCP integration. Connect any MCP server via HTTP transport — the example in the docs hooks up OpenAI’s own documentation MCP at
developers.openai.com/mcp.
The sandbox options are what make this a real infrastructure play. You can run agents in OpenAI’s hosted sandbox (the same environment Codex uses), on your own infrastructure via codex exec-server over WebSocket, or through partner integrations with Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. That partner list is the tell — OpenAI is positioning itself as the orchestration layer, not the compute layer.
Early adopters are reporting measurable results. Ciridae saw evaluation scores jump from 0.71 to 0.85 with 4x latency reduction. SafetyKit cut cost per case by 60%. Hypha reduced failed responses by 86%. These are the numbers that matter more than feature lists — they show the harness doing real work, not just demoing well.
The Convergence Nobody Planned
Here’s the part most coverage missed. Open the Agents API docs and look at the vocabulary: MCP servers, skills, AGENTS.md. Now look at Claude Code: MCP servers, SKILL.md files, CLAUDE.md. Look at Google’s Gemini agent tooling: MCP servers, function declarations with the same JSON Schema format, agent instructions.
Three major labs arrived at nearly identical formats for describing what an agent can do — and they did it without a standards committee. As MindStudio documented: “A skill definition written for Claude can be adapted for GPT-4o or Gemini in minutes.” The wrapper names differ (tool_use vs tool_calls vs functionCall), but the core — name, description, parameter schema — is the same JSON Schema everywhere.
Romain Huet from OpenAI DevRel framed the progression explicitly: “AGENTS.md gave agents shared instructions. Agent Skills and .agents config gave them shared capabilities and configuration. Now, Agent Plugins make those capabilities portable.” That’s not a product announcement — it’s a description of a de facto standard emerging in real time.
The Agent Plugins 1.0.0 specification makes it official. Published by a technical steering committee including Amazon, Cursor, Microsoft, OpenAI, and Vercel, it packages skills and MCP server configurations into a portable plugin.json format. Build once, run across any compatible agent client. Anthropic isn’t on the TSC, but the format is compatible enough that the gap is cosmetic.
The O’Reilly Radar analysis puts it in context: MCP has achieved “more than 97 million monthly SDK downloads, over 10,000 active servers” and support from ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. An MCP server built for one client now works across all of them. That’s not an ecosystem — it’s infrastructure. The Agent Skills vs MCP architecture guide captures the emerging pattern: “Skills encode the procedure while calling MCP servers for live, authenticated data.” Static knowledge in markdown, dynamic capability over JSON-RPC. Two layers, one agent.
This matters for builders because it means the plumbing layer is commoditizing. Your harness architecture — memory, eval, domain logic — is where differentiation lives now. The skills ecosystem is a shared layer, not a proprietary moat.
What the Community Is Saying
The Hacker News thread (338 points, 178 comments) reveals the fault line in developer sentiment. The top-voted comment argues the real value “isn’t in the API itself but in solving fundamental challenges: where does the state persist?” The build-vs-buy debate is fierce: some developers insist custom harnesses are manageable and preferable for control, while others counter that “it’s not possible to fight OpenAI or Anthropic’s engineering teams” on infrastructure.
The vendor lock-in concern is visceral and historically grounded. Multiple commenters cite the Assistants API retirement — OpenAI’s previous attempt at managed agent infrastructure, which was deprecated with limited notice and forced migrations. “After being burned by the rug-pull of OpenAI retiring the Assistants API,” one user wrote, explaining why they’ll build custom this time. Others advocate for self-hosting on VMs with Claude Code or Codex CLI as “superior to managed APIs.” The model-agnostic camp points to DeepSeek Flash and GLM as competitive alternatives that sidestep the lock-in question entirely — if your tools are MCP servers and your instructions are markdown files, swapping the model underneath is a configuration change, not a rewrite.
This tension — convenience vs. control — is the defining question for every team evaluating the Agents API. The technical capabilities are real. The trust deficit is also real.
The OpenAI Developer Forum discussion on Agent Plugins carries similar skepticism. Developers question whether the standard genuinely solves problems MCP doesn’t already address. One poster asked bluntly: “That already exists and is called MCP?” Others worry about “embrace, extend, extinguish” dynamics when a commercially interested consortium defines the standard.
How It Works: A Session Walkthrough
The developer workflow follows four steps. First, you create a session with an agent configuration — model choice, system instructions, tool definitions, and MCP server connections. Second, you provide a task (a natural language prompt or structured input). Third, you monitor progress via Server-Sent Events streaming or webhooks. Fourth, you send follow-up tasks or steering input to refine the agent’s direction mid-run.
The session is durable. If an agent hits a rate limit, encounters a transient error, or needs to wait for an external tool response, the session persists. You can resume it hours later with full context intact. This is the gap that custom harness builders spend the most time filling — and the gap the Agents API is explicitly designed to close.
For teams already using the Agents SDK in their own infrastructure, migration is incremental. The same MCP servers, the same tool definitions, and the same agent instructions work in both environments. The difference is who runs the loop.
Agents API vs. the SDK: Two Layers, One Stack
A common confusion: the Agents API is not a replacement for the Agents SDK. They’re complementary layers. The SDK (released April 2026) integrates agent loops directly into your application code — you run the harness, you manage the infrastructure. The API delegates that entire orchestration layer to OpenAI’s managed service while supporting the same tool ecosystem.
Think of it as the same distinction as running PostgreSQL yourself vs. using a managed database. The query language is the same; the operational burden is different. If you’re prototyping or building a product where agent infrastructure isn’t your core competency, the API removes real friction. If you need full control over the execution environment, the SDK is still there.
For a broader view of how this fits the competitive landscape, our Codex vs Claude Code comparison breaks down the harness-level differences. The Agents API doesn’t change the multi-agent orchestration patterns — it just gives you a managed option for running them. And if you’re working across vendors, the cross-vendor agent queue patterns still apply.
What This Means for You
If you’re evaluating agent infrastructure today, the convergence on MCP + skills is the signal, not any single API. Build your tools as MCP servers and your procedures as skills. They’ll work across OpenAI, Anthropic, and Google tooling — and across Cursor, VS Code, and whatever IDE ships next quarter.
If you’re already running production agents, the Agents API is a “managed PostgreSQL” decision. It reduces operational overhead but adds a dependency. Weigh it against your compliance requirements (US-only data residency is the current constraint) and your team’s ability to maintain custom infrastructure.
If you’re building agent tooling, Agent Plugins 1.0.0 is the format to target. The TSC includes the major players, and the specification is deliberately minimal — a plugin.json plus skills and MCP config. Bet on portability.
If you’re watching the competitive landscape, this is OpenAI catching up to Anthropic’s head start on the harness layer. Claude Code has had MCP, skills, and multi-agent delegation for months. Google’s ADK shipped similar primitives. The Agents API is OpenAI’s answer — not by inventing something new, but by hosting what already works and adding managed infrastructure around it. The winner won’t be the lab with the best API; it will be the one whose harness makes agents most reliable in production.
Looking Ahead
The Agents API is in public beta. OpenAI has said they’ll iterate quickly based on developer feedback. The current limitations — US-only data residency, no Zero Data Retention — will narrow the addressable market until they’re resolved. But the trajectory is clear: harness infrastructure is becoming a managed service, and the primitives it runs on (MCP, skills, system instructions) are shared across the industry.
The question for 2027 isn’t “which agent API wins.” It’s whether managed harness services prove reliable enough to replace the custom infrastructure that serious teams have already built — or whether the Assistants API pattern repeats and developers learn, once more, that owning your orchestration layer is worth the operational cost.
The Agents API is available in public beta at developers.openai.com. Flavio Copes published a hands-on deep dive covering sessions, MCP configuration, and webhook handling.