OpenAI Agents API Is a Managed Harness. Run the Continuity Drill Anyway.

At 2:14 on a Thursday afternoon, a session that has spent ninety minutes moving a payments module onto a new schema stops producing events. No error. The dashboard says running. The sandbox, the model, the orchestration, and the summary of everything the agent decided at minute 40 are all on a computer you have never seen, rented through the OpenAI Agents API and billed to you by the minute.

That is the deal, and on most days it is a good one. In public beta since September 10, 2026, the Agents API rents you the Codex harness as a service: the session, the loop, the compaction, the recovery. Convenience is concentration. Everything that used to be scattered across your own machines now sits with one vendor, and one vendor’s outage, price change, or terms change now reaches every job at once.

The move is a drill you can run this week. Inventory the three dependencies every job carries (model, harness loop, sandbox), write a failover route for each, and decide before the first real session which three things never live only on the vendor’s side: transcripts, approvals, and secrets. Then kill a running session at minute 20 on purpose and see what comes back.

What OpenAI shipped on September 10: a Codex harness rented by the session

On September 10, OpenAI made the Agents API “available in public beta today to all developers” (OpenAI). The one-line pitch is the whole product: “Build and run cloud agents with the Codex harness, fully managed by OpenAI.” Four primitives carry it. An Agent is the model, instructions, tools, and MCP servers; an Environment is an optional sandbox or computer where the agent accesses files; a Session is a durable instance of an agent that works on tasks; Events are the inputs sent to an agent and the output produced during a session. The docs draw the line plainly: OpenAI manages “sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment” (Agents API docs).

Screenshot: OpenAI, “Introducing the Agents API” (Sep 10, 2026), captured Sep 13, 2026.

The execution environment is the one dependency you get to choose. Sandboxes are OpenAI-hosted, partner-hosted, or self-hosted on machines you control, and OpenAI names nine partners offering hosted environments: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. Context is compacted automatically as a session nears its limit, tool search loads tool definitions on demand, and subagents split a task into independent pieces. Billing follows the parts: model usage at the selected model’s API rates, OpenAI tools at their standard rates, and “OpenAI-hosted sandboxes use standard container rates.”

Two lines in the docs matter more than the feature list. The API “currently supports data residency only in the United States,” and it “does not support Zero Data Retention (ZDR)”; the limits apply even when the sandbox is yours.

Screenshot: OpenAI Developers, Agents API overview (primitives, pricing, sandbox lines), captured Sep 13, 2026.

InfoWorld’s Anirban Ghoshal covered the launch on September 11 and named the concern in one sentence: “Lock-in is the biggest concern. If OpenAI provides the model, context management, tools, orchestration, and execution environment, moving to another platform becomes harder.” He placed the product alongside Anthropic’s Claude Managed Agents, in public beta since April, and Amazon Bedrock AgentCore, whose managed harness went GA in June (InfoWorld). The buying matrix across those three is its own piece; how the Codex harness fits the rest of OpenAI’s tooling is already written.

Why a rented loop raises the continuity bar

When the harness ran on your laptop, a provider outage was a stalled process you could see, kill, and restart from the transcript on your disk. A managed loop moves the transcript, the compaction summary, the retry logic, and (if you took the hosted sandbox) the working tree onto the vendor’s side. The model-cutoff drill you may have run for the Cursor shutoff assumed the loop was yours. Here the loop is the thing that can go away.

Chatbots suggest; agents act. A session that dies mid-job has already pushed to a branch, called tools, and maybe raised an approval that is now sitting in a queue on a vendor page. The requirement moved from “have a backup account” to “know what state you can recover, from where, in how many minutes.”

The OpenAI Agents API continuity drill in five steps

Budget an afternoon for steps 1 through 3 and one quiet morning for step 4. Every file and command below is a shape, labeled illustrative; substitute your job names and your real paths.

Step 1: inventory the three dependencies every job carries

Each job on the Agents API depends on three things the vendor supplies and two you supply. Write them down per job, not per account, because the fallback for a nightly refactor is not the fallback for an incident bot that talks to customers.

Dependency	On the Agents API	Who else can supply it	What does not travel
Model	The OpenAI model selected in the Agent	Another vendor, through a different harness	Prompt habits tuned to one family
Harness loop	The Codex harness, managed: sessions, orchestration, compaction, recovery	Codex CLI on your runner; another managed vendor; your own loop	Session state, compaction summary
Sandbox	OpenAI-hosted container, a partner host, or a self-hosted environment	Your VM or container, or a partner	The working tree, unless pushed
Tools (yours)	MCP servers the Agent is pointed at	The same servers, from any harness	Nothing, if they are MCP
Task spec (yours)	Instructions in the Agent	Any harness	Nothing

The last two rows are the portable half of the system, and they stay portable only if you keep them that way: tools as MCP servers you host, task specs as files in the repo rather than text pasted into a console. The model row is the honest one. The launch material documents an OpenAI model field and no cross-provider model option, so put cross-provider failover outside the API.

# deps.yaml (illustrative): one entry per job, kept next to the task spec
jobs:
  payments-schema-refactor:
    model: { primary: openai/<selected-model>, fallback: none-inside-api, local: alias:planner }
    loop: { primary: agents-api, fallback: codex-exec-on-runner, local: any-harness }
    sandbox:
      {
        primary: openai-hosted,
        fallback: self-hosted-agents-environment,
        local: docker-golden-image,
      }
    spec: tasks/payments-schema-refactor.md
    residency: { us_only_ok: true, zdr_required: false }

Three managed harnesses in five months, on InfoWorld’s dating for April and June and OpenAI’s own date for September 10. A crowded category is good news for the fallback column.

Step 2: write the failover route per dependency

A route is a primary, a fallback, a last resort, and the trigger that moves you along it. Write it as a table you can read at 2:14 p.m., not as a paragraph.

Dependency	Primary	Fallback	Last resort (local)	Trigger to move
Harness loop	Agents API session	codex exec on your runner, from the events mirror	Any harness, from the task spec alone	No events for 10 minutes; two recoveries in a row
Sandbox	OpenAI-hosted container	Self-hosted Agents API environment in your network	Your VM from a golden image	Container spend over the job’s cap; residency requirement changes
Model	The OpenAI model in the Agent	None inside the API	Your alias layer’s other family	Only through the loop’s last resort
Evidence	Session events on the vendor side	Continuous mirror to JSONL	The mirror is the record	Always on; never a trigger

The fallback for the loop is the same harness lineage running where you can see it. Codex CLI runs non-interactively with codex exec "<prompt>" (Codex non-interactive docs; Codex CLI reference), so the job the managed loop was doing can be picked up by the same harness on a runner you own, fed by the task spec and the mirror from step 3.

# illustrative: the fallback lane for the loop, on a runner you own
codex exec --sandbox workspace-write --ask-for-approval on-request \
  "$(cat tasks/payments-schema-refactor.md) Resume from branch agent/payments-2 and sessions/<id>.jsonl."

Two rules keep the table useful. The sandbox fallback is in your network first, because a self-hosted environment is the only one where the working tree and the secrets never left. And the evidence row has no trigger, because a mirror you switch on after the failure is a mirror of nothing.

Step 3: decide what stays local before the first session

Three things must exist on your side while the session runs, not after: transcripts, approvals, secrets.

Transcripts. Consume the session’s events as they happen and append them to a file you own, one per session, keyed to the task spec’s hash. Events are the inputs sent and the output produced, which is exactly what you need to resume elsewhere; the compaction summary is the vendor’s memory of the job, and it stays with the vendor. One thing the mirror cannot do: with US-only residency and no ZDR, the record also exists on the vendor’s side and you cannot make it not exist. That decides what is allowed to enter the session at all, which is the secrets rule below.

{
  "ts": "2026-09-17T14:02:11Z",
  "session": "ses_…",
  "seq": 412,
  "type": "tool_call",
  "tool": "git.commit",
  "args_sha256": "9f3c…",
  "approval": "apr_0187",
  "cost_usd": 0.014
}

Illustrative record shape. The fields that matter at resume time are seq, the last checkpoint, and the last approval id.

Approvals. Any tool call that touches production, money, customer data, or a lockfile routes through an approval you record on your side: approver, action id, argument hash, decision, expiry. The vendor may show the same request in its console; the ledger is yours so that after a recovery you can prove an action had a matching approval, and so an expired approval cannot be silently reused. The export ritual for a vendor-hosted harness is its own runbook.

Secrets. Nothing long-lived goes into the Agent’s instructions or into the environment of a hosted sandbox. Broker them: the agent asks for a capability, your broker mints a token scoped to one repo or one API with a ten-minute TTL, and the tool call carries the token. On a self-hosted sandbox the broker runs in your network and the raw credential never crosses the API at all. I have never once regretted a token that expired too soon.

# broker.yaml (illustrative): the agent never sees the value under `secret`
capabilities:
  git-push: { secret: vault:gh-app/payments, ttl: 10m, scope: repo:payments, approval: none }
  deploy-prod: { secret: vault:deploy/prod, ttl: 0, scope: none, approval: never-from-agent }

What leaves with the vendor and what you keep. Everything in the left box is gone at the cut unless the right box was being written while the session ran.

Step 4: kill the session at minute 20 on purpose

Pick a task with a known finish line: a 40-minute refactor with a test suite that goes green when it is done. Start it on the Agents API with the mirror, the ledger, and the broker in place. At minute 20, cut it. Revoke the key, stop the session, or drop the sandbox; each is a different failure and you will want all three eventually, but start with the key, because that is the one a leaked credential will hand you.

Then resume on each route and write down what came back.

1. Route 1, managed retry: let the vendor’s recovery do its job. Measure minutes to resume and whether the resumed session still honors the constraint you gave at turn three.
2. Route 2, your runner: codex exec from the events mirror and the task spec, on a machine you own. Measure minutes to the first useful tool call and how much of the first twenty minutes it re-spends.
3. Route 3, any harness: hand the task spec alone to a different harness. Measure the same two things.

# drill.yaml (illustrative): one block per drill, in the repo
drill: 2026-09-18
job: payments-schema-refactor
cut: { at: 20m, method: revoke-key }
routes:
  managed-retry:
    { resumed_in: 4m, kept_constraints: 2/3, lost: [in-flight tool call, sandbox scratch files] }
  your-runner: { resumed_in: 11m, kept_constraints: 3/3, respent_tokens_pct: 35 }
  any-harness: { resumed_in: 19m, kept_constraints: 3/3, respent_tokens_pct: 60 }
secrets_in_sandbox_at_cut: none
approvals_replayed: 0
next_drill: 2026-10-16

The numbers above are placeholders; yours are the point. Run the drill again in a month, after you have fixed what the first one found, and diff the two files.

Step 5: price the fallback lane and set the triggers

The managed lane charges model tokens, tool calls, and container time. The fallback lane charges your VM plus every token the resumed session re-spends on work the dead one already did. From the drill you have respent_tokens_pct per route; multiply it by the job’s average spend and you have the price of one cut, which decides whether route 2 is worth keeping warm.

Then set three thresholds in writing: the event gap that pages someone (ten minutes is a sane default for a job that emits a tool call every minute or two), the number of consecutive recoveries that moves a job to route 2 (two), and the container spend per job above which that job class moves to a self-hosted sandbox. Put all three in deps.yaml, next to the routes they trigger.

What breaks when the managed loop dies, and how you’ll know

The silent stall. The session says running and emits nothing. Signal: the gap between consecutive seq numbers in your mirror exceeds the page threshold. Without the mirror, the signal is a person noticing at 4 p.m.

Recovery with a thinner memory. The vendor resumes the session, but the compaction summary dropped the constraint from turn three and the agent starts touching files that were out of scope. Signal: the post-recovery diff includes paths outside the task spec’s allowlist; tests that already passed run again.

The working tree that went with the container. A hosted sandbox dies with uncommitted work. Signal: a resumed session’s git status is clean where you expected a dirty tree. Fix: checkpoint to a branch on every approval and every twenty tool calls, as a line in the task spec.

The approval in flight. A tool call was waiting on approval when the session died. After recovery it is requested again, or worse, assumed. Signal: two approval requests with the same action id in your ledger, or a gated tool call in the mirror whose approval field is empty.

The residency discovery. Someone classifies a workload as non-US or ZDR-required after it has already run. Signal: nothing in the logs; it arrives in a review. Fix: the residency line in deps.yaml, checked before the job class is allowed to start.

Rent the loop, keep the record: the operating layer under a managed harness

A managed harness is a fine place to run a loop and a poor place to keep the only copy of the record. The continuity drill is operating-layer infrastructure, not a smarter prompt: the mirror, the ledger, the broker, and the route table sit beneath every harness you rent or run, so a vendor can change without the job changing. That is the argument the command center makes for the fleet on your desk and agentic ops makes for the practice around it. The harness does the work; the operating layer keeps the evidence, the meter, and the kill switch.

When the harness is on a computer you have never seen, that layer is the only part you still own. Replaying a fleet’s day works only if the events reached your disk while the session was alive, and fleets split between a laptop and rented machines get their own runbook.

FAQ: OpenAI Agents API continuity

What is the OpenAI Agents API?

The OpenAI Agents API, in public beta since September 10, 2026, runs the Codex harness as a managed service. You define an Agent, pick an Environment, and start a Session; OpenAI manages sessions, orchestration, context compaction, and recovery, while you supply the tools and choose where the sandbox runs.

Can I self-host the sandbox for the OpenAI Agents API?

Yes. Environments can be OpenAI-hosted, hosted by one of nine named partners, or self-hosted on your own machines. Self-hosting keeps the working tree and secrets in your network; it does not change the residency and retention limits, which the docs state as US-only and no ZDR.

What happens when an OpenAI Agents API session dies mid-job?

OpenAI manages recovery, so the session may resume with a compacted memory of the work. What you keep depends on what you mirrored: session events to a local log, approvals to your own ledger, and work to a checkpoint branch. Without those, an unrecoverable session is a job restarted from zero.

Sources

• OpenAI, “Introducing the Agents API” (September 10, 2026)
• OpenAI Developers, Agents API overview (primitives, pricing, residency and ZDR limits)
• InfoWorld, “OpenAI launches managed Agents API to simplify enterprise AI agent development” (Anirban Ghoshal, September 11, 2026)
• OpenAI Developers, Codex non-interactive mode (codex exec)
• OpenAI Developers, Codex CLI reference (sandbox and approval flags)