OpenAI's Agents API is in public beta - what it means for who builds your automation

OpenAI put its Agents API into public beta on September 10, 2026. It takes the internal harness that runs Codex — the part that keeps an agent's session alive, manages its context, calls its tools, and spins up sub-agents to delegate work — and exposes it as a single API that any developer can call. Until now, that machinery was OpenAI's alone. Now it is a product.

What is genuinely new

Building a long-running agent used to mean writing your own plumbing: a loop to keep the conversation state coherent across dozens of steps, logic to compress context before it blew the token limit, a way to search and select tools instead of stuffing all of them into every prompt, and — if you wanted the agent to actually do things instead of just talk — a sandboxed environment to run code or browse the web in.

The Agents API packages all of that. It handles session continuity and automatic context compaction. It can search for the right tool instead of loading every tool definition into every call. It runs tool calls in parallel when they don't depend on each other. And it supports subagents, so one agent can delegate a sub-task to another and get a result back, rather than one model trying to hold the entire job in its head.

For execution, OpenAI gives three choices: its own hosted sandbox, a partner sandbox (Cloudflare, Modal, Vercel, E2B and others are listed as integration partners), or your own infrastructure if you want full control. That's the real shift — not the model, but the runtime around the model. The pieces that automation shops like ours used to hand-build for every client engagement are now a checkbox.

What it means for a business owner

If you've been quoted a build for an internal agent — something that researches, triages documents, or works through a multi-step workflow across several tools — a chunk of that quote was infrastructure, not intelligence. Session management, context handling, sandboxing: those are solved problems now, at least for anything you're willing to build on OpenAI's models.

That changes the calculus on build-vs-buy. A workflow that previously took weeks of scaffolding before you even got to the business logic can now start there. It also lowers the switching cost of trying agentic automation at all: you can prototype a document-triage or research agent without first committing engineering time to infrastructure that might get thrown away if the pilot doesn't work out.

It does not remove the need for someone who understands your workflow well enough to design what the agent should actually do, or the judgment to know when the automation should stop and hand off to a person. OpenAI is selling you a better chassis. It is not selling you the map of your own business.

The honest caveat

The billing is not fully transparent yet. OpenAI publishes four sandbox memory tiers — from $0.03 to $1.92 per 20 minutes depending on RAM — but the Agents API's own session-creation reference has no parameter to choose a tier, and OpenAI hasn't documented which one applies by default or how idle time (an agent sitting there waiting on a tool response) gets billed. Compare that to Anthropic's managed-agent pricing, which states a flat per-session-hour rate and explicitly excludes idle time. Right now, a multi-step agent workflow on OpenAI's hosted sandbox is a cost you can't fully predict in advance.

There's a second cost worth naming: subagents multiply your failure surface as much as your capability. Every sub-task is another place a run can fail, retry, or double-bill you on a non-idempotent tool call. And this is a public beta — OpenAI itself recommends having a rollback plan, which is a polite way of saying the interface may still change under you.

None of this is a reason to wait indefinitely. It's a reason not to point a production workload at it without a cost ceiling and a plan for what happens when a run fails partway through.

What to do about it

If you're evaluating whether to build an internal agent, this is a good moment to prototype on someone else's infrastructure instead of your own, precisely because the scaffolding is now free to try. Run it on a bounded, non-critical workflow first — internal research or document triage, not anything customer-facing or financial — and track actual token and sandbox spend against your own estimate before you commit. The gap between the two numbers will tell you whether "managed" is actually cheaper than what you'd have built yourself, or just cheaper to start.