OpenAI Agents API: buy the harness, or keep yours?

The OpenAI Agents API gives your application access to the Codex harness as a managed service. OpenAI's own summary is the clearest statement of what changed: OpenAI manages sessions, orchestration, context compaction and recovery, while your application provides tools and chooses its execution environment.

Read that list again if you spent this year building an agent. It is, almost exactly, the code you wrote and did not enjoy writing. The interesting question is no longer whether the loop can be bought. It is what you are handing over when you buy it.

What the managed harness takes over

The architecture documentation splits the system into three pieces. The harness is the OpenAI-hosted Codex instance that runs the model and tool loop and maintains the session. The environment is where the agent runs commands, executes code and works with files — a remote sandbox, your laptop, a Docker container, or an AWS Lambda function. The application server is your code: it submits tasks, receives events and handles function tools.

The harness handles running commands in a sandbox, applying skills and instructions, connecting to external data through tools or MCP, steering the agent mid-task, summarising previous work to manage the context window, breaking work into subtasks for subagents, and resuming a session where it left off.

Context compaction is the entry on that list that will land hardest. Every team building a long-running agent has written some version of it, usually twice, and usually badly the first time. Subagent delegation with a concurrency cap is the second. Both are now configuration.

An environment is optional. Setting environment.type to none gives you a harness that calls the model, uses configured tools and returns results, with no compute and no files — which is enough for a large class of agents that read from services and write answers. The built-in Bash and apply-patch tools, workspace files and executor MCPs are simply unavailable in that mode.

What is explicitly not managed is the part where your code has to keep up. Progress reaches you by streaming, by webhooks, or both, and function tools need a handler that receives each call and returns a result. OpenAI's own warning is worth quoting in a design review: if that handler is unavailable, the agent can remain waiting for a result, and failures in your event or lifecycle handlers can interrupt progress updates or environment management. A managed loop does not make your side of the boundary reliable. It moves the outage from a crashed worker you can see to a session sitting patiently in someone else's infrastructure, which is a harder thing to alert on.

Three runtimes, and the question that separates them

OpenAI now offers three ways to run an agent, and its runtime comparison is unusually honest about the trade.

	Agents API	Agents SDK	Responses API
Where the agent runs	OpenAI runs a managed Codex harness	The SDK runs inside your application	Your application, optional hosted orchestration
State between tasks	Saved session configuration, turns and items	Your storage and SDK sessions	Manual history or response chaining
Integration effort	Low	Medium	High

The dividing question is not effort. It is where the state between tasks lives. With the Agents API, the session configuration, the turns and the items are held by OpenAI. That is the convenience and it is also the commitment, because a session is not a thing you can copy to another provider.

Where the lock-in actually sits

Model portability has been the industry's comfort blanket for two years. Swap the endpoint, re-tune the prompts, carry on. It was always a slight fiction, and the Agents API makes it a larger one, because the harness is where the accumulated engineering lives.

If your compaction strategy, your recovery behaviour, your subagent fan-out and your session store are all OpenAI's, then moving provider is not an endpoint change. It is rebuilding the loop you deliberately chose not to build. That is a legitimate thing to accept — teams accept it with managed databases every day — but it should be a decision someone made on purpose, not a discovery made eighteen months later. It is the same build-versus-buy calculation that applies to any platform component, with one twist: the thing being bought is the part of the system that was, until recently, your differentiator.

The mitigation is unglamorous and worth doing anyway. Keep your tool definitions, your prompts and your evaluation suite in your own repository and under version control, exactly as we argued for keeping agent knowledge in git. Those artefacts are portable. The harness is not. If the valuable part of your system is a well-specified set of tools and a rigorous eval suite, you can move. If the valuable part is undocumented behaviour inside a managed loop, you cannot.

The sandbox deserves the most thought

OpenAI's sandbox security guidance opens with the sentence that should govern the whole design: agent-generated code can access the files, credentials and network available to its environment.

Its recommendations are the right ones, and they are all things your team has to implement rather than switch on. Run workloads in isolated compute and use separate environments for users or workloads that must not share data. Allow outbound traffic only to approved endpoints. Note that executor MCPs connect from your environment while remote MCPs connect from OpenAI's service, so the two need different network rules — an easy thing to get wrong once and never notice.

The credential guidance is the sharpest part. The executor gets an environment key that can only connect environments and cannot authorise any other API action, and OpenAI states plainly that agent-generated code can read that key. Your application API key stays outside the environment. Third-party credentials stay outside too, ideally behind a broker that injects secrets into approved outbound requests without placing them where the agent can read them.

None of this is new thinking — it is the same allowlist-first posture we described for AI agent sandbox security — but a managed harness makes it easier to skip. When provisioning is someone else's job, the network policy quietly becomes nobody's.

What it costs, and the shape of that cost

Billing is model rates plus standard tool rates plus, for OpenAI-hosted sandboxes, standard container rates. No new pricing tier, which is welcome, but a different cost shape from a plain completion.

A container that exists for the life of a session is billed for the life of a session, which means idle agents cost money in a way idle API clients never did. Sessions are durable by design, and OpenAI notes you can delete sessions and published artefacts when you no longer need them. Treat that as an instruction. Session and sandbox lifecycle belongs in your code from the first prototype, because the failure mode is not an error — it is an invoice.

OpenAI Agents API: how we would decide

For a team starting an agent product now, the managed harness is the sensible default. Writing your own compaction and recovery to a worse standard, in order to preserve an optionality you will probably never exercise, is not a good use of a first quarter. Start with environment.type: none, add a sandbox only when the agent genuinely needs to run code, and keep tools and evals in your repository.

For a team that already has a working loop in production, the case is weaker than it looks. Your loop encodes real knowledge about your domain's failure modes, and a migration is a rewrite of the least visible and most load-bearing component you own. The honest test is whether context management and recovery are currently costing you engineering weeks per quarter. If they are, migrate. If they are not, the existing loop is an asset.

For anything touching regulated data or a private network, the self-hosted environment is the only configuration worth evaluating, and the work it saves is smaller than the headline suggests — you still own provisioning, reconnection, shutdown and file persistence. What you gain is the harness, not the infrastructure.

The pattern underneath all three cases is the one worth naming. Agent orchestration is becoming a commodity, the way web frameworks and job queues did before it. The durable engineering is moving to the edges: the quality of your tool definitions, the rigour of your evaluations, and the discipline of your sandbox. That is where we would put the effort on any AI engineering project starting this quarter, whoever runs the loop.