OpenAI opens up its agent infrastructure: what the Agents API changes for build-vs-buy in your SMB

On September 10, 2026, OpenAI introduced the Agents API in public beta, open to all developers. The API gives applications direct access to the "harness" that already powers Codex and ChatGPT's agentic features: OpenAI manages sessions, multi-step orchestration, context compaction as a conversation grows, and recovery after a failure, while the developer only supplies tools and picks where the agent's code actually runs. Agents built on it can execute code, edit files, connect to MCP servers, produce artifacts, and delegate sub-tasks to other agents. Execution happens in one of three places: an OpenAI-hosted sandbox (the same infrastructure behind Codex, configurable with files, packages, skills and plugins), a partner sandbox (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop or Vercel), or the developer's own infrastructure. OpenAI says there is no separate fee for the API itself — billing follows standard model token rates plus the usual rates for OpenAI tools and hosted sandbox containers.

What actually gets cheaper

• →Session state, multi-step orchestration, automatic context compaction and failure recovery are now handled by OpenAI rather than hand-built by each team — previously a real engineering cost for anyone assembling an agent from scratch.
• →Three sandbox options (OpenAI-hosted, nine named partners, or self-hosted) remove the need to stand up isolated execution environments in-house.
• →No markup on top of the API: pricing stays at standard model and tool rates, which lowers the cost of prototyping an agent internally.
• →The same plumbing already runs Codex and ChatGPT in production, which is a stronger reliability signal than a brand-new framework.

Why that does not make the hard part disappear

Cheaper infrastructure does not remove the reason most agent projects stall. A 2025 study led by Mert Cemri at UC Berkeley, Why Do Multi-Agent LLM Systems Fail?, analyzed over 1,600 annotated execution traces across seven popular multi-agent frameworks and catalogued 14 distinct failure modes, grouped into system design flaws, inter-agent miscommunication and poor task verification. The paper's central finding is that failures overwhelmingly trace back to how the system is designed, coordinated and verified — not to the underlying model's raw capability. Managed orchestration and compaction remove some of that surface area, but they do not decide which tools an agent is allowed to call, how its output gets checked before it reaches a customer or a supplier, or what happens when it is confidently wrong.

What it changes for your SMB

For an SMB owner or DSI weighing build versus buy on AI agents, this announcement lowers the cost of the "build" option's foundation — but the foundation was rarely where SMB projects failed. The real work is elsewhere: connecting an agent to your actual invoicing system, CRM, shared mailbox or WhatsApp line; deciding what it is and is not allowed to do unsupervised; and keeping continuous supervision once it is live, which is exactly what use cases like an unpaid-invoice follow-up agent, an email-triage agent or a regulatory-watch agent are built around — not the orchestration layer underneath them, but the governance layer on top of it. A cheaper harness makes it more tempting for an internal developer to assemble something quickly; it does not supply the ongoing monitoring, error handling and business-system integration that turn a working demo into something you can trust with real invoices or real customers. If your team does not already have engineering capacity dedicated to maintaining an agent in production, this announcement is a reason to have the build-vs-buy conversation again — not a reason to default to building.

Concrete steps

• →Before building internally, list who on your team will own the agent's failures in production six months from now — not just who will build the first version.
• →Ask any AI vendor you are evaluating whether they use managed infrastructure like this (lower operating cost, faster iteration) or a fully custom stack, and what that implies for your ability to switch providers later.
• →Keep any agent you build or buy scoped to a narrow, well-defined task with a human checkpoint before anything irreversible (a payment, a message to a client, a filed document) — the Berkeley study's top failure category is exactly agents acting past their intended scope.
• →Revisit the build-vs-buy decision as a cost-of-ownership question, not a cost-of-prototyping one: cheaper infrastructure shifts the total cost curve, but supervision and integration remain the majority of it for a small team.

The headline is that OpenAI just made agent infrastructure a commodity. The more useful reading for an SMB is narrower: the part that just got cheap was never the part that made your last automation project stall.