{inercia}

OpenAI Agents API

OpenAI Agents API ​

OpenAI shipped an Agents API — a managed way to run the Codex harness against your own tools and infra, the shift flagged in Agents Inside vs. Outside the Cluster: providers run the reasoning loop and call back into your tools, not the reverse.

What it actually is ​

  • Not a generic "build any agent" API — it exposes the Codex harness (Codex CLI/cloud's runtime; OpenAI manages sessions, orchestration, context compaction, and recovery).
  • Core objects: Agent (model + instructions + tools + MCP servers), Environment (optional sandbox/compute), Session (durable instance running tasks over time), Events/items (streamed output/input).
  • Distinct from the Responses API (stateless-ish, per-request tool loop) and the deprecated Assistants API.
  • Built-in: multi-agent/subagent delegation, programmatic tool calling, MCP connections, skills, steering a running session mid-turn.

The environment model ​

  • environment.type: none (no sandbox — function tools or remote MCP only), openai_hosted (OpenAI provisions and manages the sandbox), self_hosted (your infra runs an "executor" the harness talks to).
  • The self-hosted case is the relay-inversion pattern from the earlier post, made literal: the harness runs in OpenAI's cloud; your executor runs commands and holds files.
  • How much control you retain vs. AgentCore/Foundry's equivalents is unclear.

How it compares ​

  • Compare against Bedrock AgentCore, Azure AI Foundry Agent Service, and Claude Managed Agents — all four are converging on "provider hosts the loop, you bring tools/infra."
  • OpenAI's version is Codex-flavored — bash, apply-patch, workspace skills, subagents — not a blank-slate builder. Narrower and opinionated, or does it generalize beyond coding? Unclear.
  • No portable agent spec exists across these four; each has its own session/environment model — the standardization gap flagged earlier (ACP/A2A convergence still incomplete).

Caveats ​

  • Currently beta (OpenAI-Beta: agents=v1 header).
  • Data residency: US-only; no Zero Data Retention (ZDR) support — self-hosting your own sandbox doesn't make it ZDR-eligible.
  • No turn-time bound or latency SLA. Turns run asynchronously: track progress via streaming events (agent.session.turn.completed/failed/cancelled) or webhooks, not a synchronous "answer in N ms" contract. No maximum duration or completion SLA is documented — a turn runs until the agent finishes, fails, or you cancel it (agent.session.input.cancel). The only hard deadline: a 5-minute connection timeout for a self_hosted executor at input time, not an execution bound. Bounding wall-clock and token spend is the caller's job, per Bounding your agent.
  • Pricing needs a closer look: model usage at standard rates, plus separate container/sandbox rates for OpenAI-hosted environments.

Takeaway ​

  • Confirms the earlier thesis: providers want to own the reasoning loop; "cluster as capability provider" still holds — your MCP tools and self-hosted executor become the interface, regardless of where the harness runs.
  • Should also reference MCP Tunnels for the private-infra bridging angle: a self-hosted environment has the "cloud agent reaching into your network" problem too.

© 2026 {inercia}