OpenAI Now Sells the Agent Harness. You Still Own the Consequences.

On 10 September, OpenAI introduced the Agents API in public beta, and the shortest accurate description is also the most consequential one: the harness that runs Codex, productised. One API call takes a task, a model, a set of tools and an environment, and OpenAI runs the loop for you. The announcement is full of the things a managed harness absorbs: context compaction, tool discovery, programmatic tool calling, subagent orchestration, sessions that persist for days.

The question worth asking is not what the API does. It is which engineering responsibilities actually move to OpenAI when you adopt it, and which stay on your side of the line. I have read the announcement, the linked documentation and the public code, and the docs answer that question with more candour than the launch post. The managed set is real and genuinely useful. The unmanaged set is exactly where the money and the trust live.

Key Takeaways - The Agents API, in public beta since 10 September 2026, exposes the Codex harness as a service: sessions, orchestration, context compaction, tool search, programmatic tool calling and subagents are managed by OpenAI. Your environment can be an OpenAI-hosted sandbox, your own infrastructure, or one of nine named partners. - The harness work that disappears is real: compaction, tool discovery, parallel tool execution and subagent coordination are documented mechanisms, not marketing. - Session state is durable; your side effects are not. The docs are explicit that streams do not replay, the input queue is not durable, and a completed turn does not mean every tool succeeded. Exactly-once business effects remain your problem. - Approvals, secrets, external writes, per-agent spend and verification of completed work all stay with the application owner. There is no approval object in the API. - The launch carousel quotes eight customers, but only three publish measured outcomes, all self-reported. And the "no additional fees" line sits awkwardly next to container pricing in OpenAI's own docs.

What shipped on 10 September

The API surface is small, and worth naming precisely, because the naming is the architecture. Per the overview documentation, there are four concepts: an Agent (model, instructions, tools, MCP servers), an Environment (an optional sandbox for the agent to work in), a Session (the durable running instance), and the stream of events and items the session produces. You create sessions under POST /v1/agents/sessions with an OpenAI-Beta: agents=v1 header, and the beta labelling is doing honest work: this surface can change.

The environment is a choice with three settings. openai_hosted gives you a managed Linux sandbox on the same infrastructure that powers Codex and ChatGPT. self_hosted runs an executor on your own machines, an outbound-connecting codex exec-server process authenticated with a restricted environment key. none skips the sandbox entirely. Beyond those, OpenAI has lined up nine sandbox partners: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel. This is not a paper partnership list. Vercel shipped its integration changelog the same day, and Daytona published a guide for running sessions in its sandboxes the day after.

The harness itself is the open-source Codex harness, and that claim checks out at repository level: the openai/codex repo is public under Apache-2.0, and the machinery the docs describe is visible in it, including the exec-server you run for self-hosted environments and the code-mode runtime behind programmatic tool calling. What is not in the repo is just as telling: the server-side session orchestration, compaction-as-a-service and partner plumbing are OpenAI's operated layer. You can inspect the engine. You cannot inspect the factory.

There is a strategy note worth making, and HTA has the receipts for it. A month ago we covered OpenAI folding or killing every standalone agent product it had shipped and betting on one superapp. The Agents API is the other half of that decision. If the general-purpose agent did not win as a product, sell the machinery that made it run.

Four jobs the harness genuinely takes over

Scepticism about managed services is healthy, so let me be precise about what you stop building, because each of these is a documented mechanism with a real design decision inside it.

Context compaction. When a session approaches its context limit, the harness compacts earlier context automatically, so workflows can span multiple context windows without you writing compaction logic. The mechanism is visible in the compaction guide: the Responses API exposes a compact_threshold, and compaction emits an encrypted, opaque item that the docs describe as "not intended to be human-interpretable". That opacity is the trade you are making. You stop maintaining summarisation code; you also stop being able to audit what the harness decided was worth keeping. In the Agents API there is not even a documented threshold to tune. It is managed in the fullest sense.

Tool search. Agents with large tool estates can mark functions, namespaces or MCP servers with defer_loading, per the tool search guide. The model initially sees only names and descriptions; when it asks, relevant definitions are injected at the end of the context window specifically to preserve the prompt cache.

The documented caveat matters as much as the mechanism: changing the loaded tool set breaks the cache from that point on, and the docs hedge the savings claim to "may help reduce" token usage and cost. Deferred loading is a real technique (TrueForge shipped a version of it in August), but the cache-preserving placement is the kind of detail you only learn to do by burning someone else's tokens first.

Programmatic tool calling. Instead of emitting one tool call per model turn, the model can write JavaScript that runs in a fresh, isolated V8 runtime hosted by OpenAI, per the programmatic tool calling guide. No Node.js, no packages, no network, no filesystem, no persistent state; the program fans out parallel calls, chains them, filters results in code, and only the distilled output returns to context. In the Agents API this is on by default through an exec tool. Tucked into the same page is a sentence worth framing: for "writes or approval-sensitive actions", the docs advise direct tool calling rather than programmatic. Hold that thought.

Subagents. Set multi_agent.enabled and the main agent can decompose work across subagents that run in parallel, six concurrent by default, per the multi-agent guide. The create, message, wait and interrupt tools are supplied by the harness, not declared by you. Each subagent keeps its own context, which is the point: focused assignment, no shared scrollback. Two boundaries deserve a pause. First, coordinator and subagents share one filesystem; creating a subagent does not create another environment. A subagent is a context boundary, not an isolation boundary. Second, subagents inherit MCP tools and credentials but cannot call your function tools at all, which quietly constrains how you decompose anything that writes.

The Agents API manages context compaction, deferred tool discovery, a sandboxed V8 runtime for programmatic tool calls, and parallel subagents with isolated contexts, per OpenAI's documentation. Compaction output is encrypted and opaque, tool search exists to preserve the prompt cache, and subagents share the coordinator's filesystem.

A durable session is not a durable side effect

This is the section the announcement does not write, so the docs had to. Session state persists server-side until you delete it, and files the agent produces under /workspace/outputs survive even the sandbox's expiry as immutable, downloadable artifacts. That is a genuinely useful durability story for the conversation. It is not a durability story for your business effects, and the docs say so in plain language.

Start with the events documentation: "Streams do not replay missed events." If your client disconnects, recovery means opening a new stream, pulling the saved items and reconciling by item_id yourself. Then the webhooks guide: the connection wait "does not provide a durable input queue. A process crash or client disconnect may require retries." Retries, plural, unbothered.

For self-hosted executors, if your environment takes longer than five minutes to connect, the submission fails and the session can land in a failed state. Deleting a session emits no webhook and does not stop partner-side compute. And the observability guidance repeats the sharpest line in the whole documentation set: a completed turn does not guarantee that every tool in it succeeded.

Translate all of that into operational English. The harness gives you at-least-once semantics wrapped around your tools, and exactly-once is yours to build. If a turn's job is "refund the customer, then email them", and your client retries after a disconnect, the harness will happily run surviving work again. Whether the customer gets refunded twice depends entirely on whether your function handler is idempotent, meaning a retried call performs the effect once, not twice. The harness manages the loop. Your code touches the world, and the world does not roll back.

This is also where OpenAI's own summer hangs over the launch. Earlier this month we covered the incident where OpenAI's research agents found write paths nobody intended, on sites where a GET request was quietly an edit. In the Agents API the write path is deliberate: your function tools are how the agent touches production systems. That makes the boundary more auditable, not less necessary to audit.

The environment is a choice, and choosing is your job

The hosted sandbox, per its environment documentation, is a Linux workspace at /workspace with Python, Node.js and common CLI tools. You configure it with pinnable packages, setup commands (a nonzero exit blocks the session from starting), injected files (up to 50 per request, 5 MiB each), environment variables, skills and plugins. Sessions keep the sandbox alive between turns, but after one hour of inactivity it is deleted, and that timeout is not configurable. Artifacts are capped at 200 MiB per file and 500 MiB per turn.

Two defaults deserve more attention than they will get. Network policy is enabled out of the box, meaning permissive egress; the restricted mode takes an allowlist of between 1 and 100 exact hostnames, no wildcards. And the data posture, per the overview and the security documentation: US-only data residency, no zero data retention even for self-hosted environments, and 30 days of abuse-monitoring retention. For a European operator, that paragraph is not a footnote. It is a procurement conversation.

Secrets get an honest treatment that still lands the work on you. Environment keys you inject are readable by agent-generated code, so the docs recommend credential brokers and keeping application keys outside the sandbox entirely. The one managed secret path, vaults, attaches credentials to MCP tools, not to the sandbox filesystem.

Contrast the shape with the other persistence bet HTA covered last month. Grok Bot gives every account one always-on computer, signed into your accounts, holding your files and logins indefinitely. OpenAI has chosen almost the opposite: deliberately disposable sandboxes, reaped after an idle hour, with durable session state and artifacts floating above them. One vendor is betting the asset is the machine; the other is betting the asset is the session. Both are coherent. They fail differently, which is what your risk register actually cares about.

Approvals, secrets and spend: the unglamorous remainder

Now the part of the ledger that decides whether this thing can touch anything that matters.

Approvals are application-side. MCP tools can be marked require_approval, which pauses a running program until your application resolves it, but there is no approval object in the API itself, no managed queue of pending decisions, no approval audit trail as a service. The programmatic tool calling guide states the policy directly: "Require application-level approval before high-impact actions, regardless of the caller." If your mental model comes from Codex on the CLI, where permissions are snapshotted per turn and enforced by the OS, recalibrate. In the CLI, the runtime held the boundary on your machine. In the API, the boundary is your environment configuration plus whatever approval flow you build. The harness will pause for you. It will not decide for you.

Spend control is coarse. OpenAI added org- and project-level hard monthly spend limits on 22 July, per the changelog, and hitting one returns a 429. That is a blast-radius cap for the whole organisation, not a budget for an agent. There is no per-session or per-subagent spending limit, and the usage fields on sessions and turns are documented as best-effort, nullable and "not a final bill". If you want a runaway agent stopped at $50 rather than at your org cap, you are metering it yourself.

The bill has a third meter the announcement skipped. "No additional fees for using the Agents API," the launch post says; "you simply pay for the tokens and tools your agents use." The pricing page tells a fuller story: model tokens, built-in tool calls such as web search, and container time, billed per minute with a five-minute minimum, at rates from $0.03 to $1.92 per 20-minute session depending on whether the container has 1, 4, 16 or 64 GB of memory.

Container fees are small and perfectly fair as a concept. They are also unmentioned in the announcement, and the docs do not say which memory tier an Agents API hosted sandbox maps to, or whether keep-alive idle time between turns is billed. Two questions for the beta feedback channel, and for your cost model before you extrapolate anyone's cost testimonial.

Verification of completed work is not a feature. Nothing in the API checks that the thing the agent claimed to do actually happened. The docs' position is that a completed turn is a statement about the loop finishing, not about the world being right. If you are buying agents rather than building them, this is the line to underline: the managed harness manages the process. The outcome remains your audit problem.

Eight customers, three numbers

The announcement carries a carousel of eight customers: Ciridae, Long Lake, WithCoverage, SafetyKit, Dwelly, Hypha, deepsense.ai and Nash. Read it as evidence with the right label on it. These are vendor-published testimonials, and only three contain measured outcomes. Ciridae reports its evaluation score rising from 0.71 to 0.85 with four-times lower latency on subagent flows. SafetyKit reports 60% lower cost per case after migrating case review. Hypha reports 86% fewer failed agent responses, which it attributes to separating the harness from the sandbox. None publishes methodology. The other five quotes are speed or scale claims: agents stood up "in hours", work fanned across "hundreds of agents", "thousands" of long-running logistics agents in production.

That distribution is itself information. The measured claims cluster on exactly the features the API actually manages: subagent coordination, harness stability, migration effort. That is consistent with the beta being what OpenAI says it is. What the carousel cannot tell you is anything about failure rates, total cost of operation, or what happened when something went wrong at 3am, because testimonials never do. File them as existence proofs that real companies are running real workloads on this, four days into a public beta. Not as validation.

The build-or-rent question, repriced

HTA's running coverage has been mapping this layer all summer, and the Agents API changes the prices on two existing bets. In August, TrueFoundry open-sourced TrueForge on the pitch that you should own the harness, keep it model-neutral, and let the cheapest model that finishes the task win. OpenAI's counter is now a product: a harness versioned alongside each model launch, maintained by the people who build the model, and explicitly sold on the idea that reworking your harness for every model upgrade is wasted engineering.

Both bets concede the point that matters, that the harness is its own layer of the stack. They disagree about who should operate it and how portable your workloads remain. The Agents API is model-locked by construction. TrueForge is ops-heavy by construction. Pick your dependency with your eyes open.

What to do now

1. Today: read the overview and write two lists for one agent workload you actually run: which of its responsibilities sit in the managed set (compaction, tool discovery, parallel execution, subagents, session state) and which sit in yours (approvals, secrets, writes, idempotency, verification, spend). If the second list is longer, that is normal. It is supposed to be.

2. This week: if you prototype, set the sandbox network policy to restricted before your first run, because the default is permissive egress, and make every function handler that writes to an external system idempotent before the first retry teaches you why. Test your disconnect path deliberately: kill the client mid-turn, reconnect, and watch what reconciles and what repeats.

3. This month: write down your approval tiering before you wire in tools that spend money or change state: which MCP tools carry require_approval, what counts as high-impact, and who can resolve a paused program at 2am. Set the org-level hard spend cap if you have not already. It is the only automated brake the platform currently offers.

The bottom line

The working hypothesis going in was that OpenAI now supplies the harness and you still own the consequences. Four days of documentation reading says that is not a hypothesis any more; it is the product's actual architecture, stated in its own docs with unusual directness.

What disappears is real engineering: compaction, discovery, orchestration, session plumbing. What remains is everything that touches money, credentials and other people's systems, plus the two quiet constraints (US-only residency, no zero data retention) that will decide this for regulated buyers before any benchmark does. The open questions are a GA date that does not exist, idle-time billing that is not stated, and exactly-once semantics that are not promised anywhere. The harness is now a service. The consequences were never going to be.

If you are mapping which responsibilities would move in your own stack before adopting a managed harness, that is a conversation I have with clients regularly. Get in touch.

Sources

• OpenAI, "Introducing the Agents API": https://openai.com/index/introducing-the-agents-api/ (published 2026-09-10, retrieved 2026-09-14)

• OpenAI Developers, Agents API overview: https://developers.openai.com/api/docs/guides/agents-api/overview (retrieved 2026-09-14)

• OpenAI Developers, context compaction guide: https://developers.openai.com/api/docs/guides/compaction (retrieved 2026-09-14)

• OpenAI Developers, tool search guide: https://developers.openai.com/api/docs/guides/tools-tool-search (retrieved 2026-09-14)

• OpenAI Developers, programmatic tool calling guide: https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling (retrieved 2026-09-14)

• OpenAI Developers, multi-agent guide: https://developers.openai.com/api/docs/guides/agents-api/multi-agent (retrieved 2026-09-14)

• OpenAI Developers, session events: https://developers.openai.com/api/docs/guides/agents-api/sessions/events (retrieved 2026-09-14)

• OpenAI Developers, session webhooks: https://developers.openai.com/api/docs/guides/agents-api/sessions/webhooks (retrieved 2026-09-14)

• OpenAI Developers, OpenAI-hosted environments: https://developers.openai.com/api/docs/guides/agents-api/environments/openai-hosted (retrieved 2026-09-14)

• OpenAI Developers, environment security: https://developers.openai.com/api/docs/guides/agents-api/environments/security (retrieved 2026-09-14)

• OpenAI Developers, vaults: https://developers.openai.com/api/docs/guides/agents-api/tools/vaults (retrieved 2026-09-14)

• OpenAI Developers, pricing: https://developers.openai.com/api/docs/pricing (retrieved 2026-09-14)

• OpenAI Developers, API changelog (hard spend limits entry, 2026-07-22): https://developers.openai.com/api/docs/changelog (retrieved 2026-09-14)

• GitHub, openai/codex repository (Apache-2.0): https://github.com/openai/codex (retrieved 2026-09-14)

• Vercel changelog, "Build with OpenAI Agents API on Vercel": https://vercel.com/changelog/build-with-openai-agents-api-on-vercel (published 2026-09-10, retrieved 2026-09-14)

• Daytona docs, "Run OpenAI Agents API Sessions in Daytona Sandboxes": https://www.daytona.io/docs/en/guides/openai/openai-agents-api-self-hosted-sandbox/ (published 2026-09-11, retrieved 2026-09-14)

• MarkTechPost, "OpenAI Launches the Agents API in Public Beta": https://www.marktechpost.com/2026/09/10/openai-launches-the-agents-api-in-public-beta-putting-the-codex-harness-behind-one-api-call/ (published 2026-09-10, retrieved 2026-09-14)

• HTA, "OpenAI's Agent for Everything Is a Strategy, Not a Product": /en/insights/openai-agent-for-everything

• HTA, "Turn-Scoped Permissions Are Becoming an Agent-Runtime Primitive": /en/insights/turn-scoped-permissions

• HTA, "Grok Bot and the Always-On Assistant": /en/insights/persistent-cloud-computers

• HTA, "TrueForge: The Hard Part of AI Agents Isn't the Model": /en/insights/trueforge-agent-runtime

• HTA, "OpenAI's Wiki Incident: The Agents Didn't Break Out, They Wrote Out": /en/insights/openai-wiki-incident