Contents
When you adopt a managed agent runtime like the OpenAI Agents API, you are not buying a model. You are outsourcing the harness itself: sessions, orchestration, compaction, recovery. The real architectural decision is where the platform boundary sits. Everything inside it becomes the vendor’s failure domain and policy surface. Everything outside it (tools, execution environment, handlers, and organizational policy) remains yours to build and answer for.
Basis of this analysis. Expertise: written for system designers, agent harness engineers, and platform architects weighing control against convenience at a runtime boundary. Evidence: claims come from published OpenAI documentation pages (the Agents API overview, architecture, sessions, environments, lifecycle, compaction, data controls, and Bedrock pages) and the Codex Auto-review guide, each cited inline. Independence: no vendor ranking or product verdict is offered, and no hands-on use of the API is claimed. Verification limits: residency and retention statements are vendor-stated and date-stamped to the source fetch.
The Harness Is Now a Product, Not a Component
The OpenAI Agents API exposes the Codex harness, an OpenAI-hosted instance that runs the model and tool loop and maintains the session, as a managed API. The loop you would otherwise build and operate becomes a vendor boundary you call across rather than code you own (architecture).
That reframing matters because the harness used to be the part you wrote: the polling, the tool dispatch, the retry logic, the session bookkeeping. Once it is a hosted instance, orchestration and recovery become vendor-operated behavior you consume. Streaming and webhooks still deliver progress into your application, so your role shifts from implementing the loop to observing it and deciding what happens at either end of the wire.
Drawing the Boundary: What the Vendor Runs vs What You Provide
In the managed split, OpenAI manages sessions, orchestration, context compaction, and recovery, while the application provides tools and chooses its execution environment. That is a clean division on paper. In practice it determines who you page at 3 a.m. and whose code you cannot patch (overview).
The table below maps that split layer by layer. The rows the vendor owns are largely opaque to you. The rows you own carry the operational load.
| Layer | Vendor owns (Agents API) | Application owns (self-run or hybrid) |
|---|---|---|
| Sessions | Server-side session state retention and continuation across turns; deletion of sessions and published artifacts | Retention policy, what sessions may contain, compliance obligations on that state |
| Orchestration | The model/tool loop, hosted Codex instance, orchestration of calls | Tool definitions, wiring, and the application logic around the loop |
| Compaction | Context compaction, documented as its own guide | Confirming which compaction settings apply to your API path, and re-injecting anything critical that compaction drops |
| Recovery | Vendor-managed recovery behavior | Application-level handling of failures the vendor’s recovery does not cover |
| Tools | Nothing; tools are supplied by the application | Function tool definitions and handlers that receive calls and return results |
| Environment | Depends on the environment type; OpenAI-hosted options are provisioned by OpenAI | Choosing the environment, and owning its security and lifecycle when it is yours |
| Handler availability | Waiting behavior when a handler is unavailable | Keeping handlers up; failures in event or lifecycle handlers interrupt progress or environment management |
| Safety policy | Codex Auto-review is documented for Codex, not as an Agents API control | Sandbox design, monitoring, and organization-specific policy |
| Data residency | US-only residency; no ZDR; a self-hosted sandbox does not change this | The decision to use the managed line at all given those constraints |
The Environment Is a Choice You Must Make Deliberately
The environment, where commands run and files live, can be a remote sandbox, your laptop, a Docker container, or an AWS Lambda function. The self-hosted sandbox path is documented on its own page, so the managed harness does not decide your execution substrate for you. It reaches across the wire into whichever environment you connect (self-hosted sandboxes, architecture).
Environment is a selection, and the documentation covers more than one arrangement. Read the environment type you pick, because it decides who provisions and operates the compute. Patching, network egress, secrets, image provenance, and destroy-and-recreate discipline apply to any environment you run yourself. The harness can request actions. It does not inherit your threat model or your change-management process.
Server-Side Sessions: Continuity You Rent, Not State You Hold
Session state is retained server-side so work continues across turns without rebuilding context. Sessions and published artifacts can be deleted (sessions, overview). Your conversation memory therefore lives inside the vendor’s boundary, governed by their retention behavior rather than your own state store.
Continuity without context rebuilding is the convenience. Giving up the authoritative copy of the conversation is the price. You still decide what a session may contain, how long your organization tolerates it existing, and what deletion obligations apply. Deleting a session does not stop its environment, so compute has to be torn down separately (sandbox lifecycle).
Handler Availability Becomes a Distributed-Systems Problem
Function tools need a handler that receives calls and returns results. If that handler is unavailable, the agent can remain waiting for a result. Failures in event or lifecycle handlers can interrupt progress updates or environment management. Your components become the fragile half of a distributed loop (architecture).
A managed loop does not remove partial failure. It moves it. Your handlers now sit behind a vendor-operated caller with its own timeouts and retries, and you have limited visibility into the far side. Availability budgets, backpressure, idempotency of tool calls, and dead-letter handling on your endpoint become integration contract terms.
Compaction as an Outsourced Responsibility
Context compaction is among the work OpenAI manages, and it is documented as its own compaction guide. That guide describes a configurable threshold for the Responses API. Before you assume the same knobs exist on the Agents API path, check which settings apply to the API you are using.
Compaction is where long-running agents quietly lose fidelity: details summarized away, tool arguments softened, earlier constraints dropped. When you run the harness you choose the threshold, the prompt, and what is preserved. When the vendor runs it, you depend on its behavior and respond at the application layer, by re-injecting the state you cannot afford to lose.
Safety Layers at the Boundary: Auto-review Is a Complement, Not a Control
The Codex Auto-review guide says it “only evaluates eligible approval requests,” “can still make mistakes, especially in adversarial or unusual contexts,” and “should complement, not replace, good sandbox design, monitoring, and organization-specific policy.” It is “not a deterministic security guarantee” (Auto-review docs). That guide documents a Codex feature. It does not document an Agents API control, so do not count it as a vendor-owned safety layer for the managed line.
Read those caveats as a specification for your own controls. Auto-review covers eligible approval requests only. Everything outside eligibility goes unreviewed by it. The documentation positions sandbox design, monitoring, and organization-specific policy as the load-bearing controls, with Auto-review layered on top when it applies.
Residency and Retention: The Hard Constraint on the Managed Line
The platform states: “The Agents API currently supports data residency only in the United States and does not support Zero Data Retention (ZDR). Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible” (overview). The harness boundary carries your data even when the environment does not.
This is the constraint that overrides the others. Choosing your own container changes where code executes, not where session traffic is processed or retained. The platform’s data controls page is the place to check residency and retention per endpoint before you rely on either. Treat all residency and ZDR statements here as vendor-stated, and verify them against current documentation before any compliance decision.
Managed Does Not Mean Single-Vendor: The Bedrock Path
Bedrock Managed Agents, powered by OpenAI, is the AWS service built on the Agents API (overview). The Bedrock Managed Agents page describes the loop as hosted in Amazon Bedrock and defers to AWS for access requirements, Regions, and pricing. It also points to a separate data-handling guide for session state, execution files, logs, and model inference.
Re-hosting therefore changes the endpoint and the identity model, which matters if your organization already buys through AWS. Whether the session store and compaction policy move with the loop is a question to answer from that data-handling guide, not an assumption to make. The architectural test stays the same at every layer of reseller: which parts of the runtime’s internals can I see, patch, and audit, and which can I not?
When to Keep the Harness In-House
The self-run harness is the right boundary when Zero Data Retention or non-US residency is mandatory, when handler availability and compaction policy must be under your control, and when recovery behavior must be auditable. Convenience is what you trade. The table below sets out that trade on each side (overview). Cost is a separate axis, and vendor cost claims are self-reported. Anthropic says Sonnet 5.5 “costs up to 30% less per task than its predecessor” in its own testing (Claude Sonnet 5.5), so per-task economics, not list price, should drive the managed-versus-self-run decision.
| Dimension | Vendor-managed (Agents API) | Self-run harness |
|---|---|---|
| Model/tool loop | Hosted Codex instance, vendor-operated | Your code; you implement and debug the loop |
| Sessions | Retained server-side, continues across turns without rebuilding context | Your state store; you design persistence and continuation |
| Compaction | Vendor-run; configurable knobs depend on the API path | Your policy; tunable and auditable |
| Recovery | Vendor-managed; internals visible only through vendor docs | Yours; you define retry, checkpoint, resume |
| Tools | You supply them, plus handlers that must stay available | You supply them, plus the same handler obligations |
| Environment | You choose the environment type; provisioning depends on it | You choose and operate everything |
| Safety layering | Auto-review is a Codex feature; your own controls still apply | Entirely your sandbox design, monitoring, policy |
| Data residency | US-only; no ZDR; a self-hosted sandbox does not change this | Whatever you build and certify |
| Failure domain | Split: vendor owns loop and session internals; you own handlers and most environments | Unified: all of it is yours, for better and worse |
| Visibility into internals | Limited to vendor documentation | Total, since it is your code |
The self-run column is not the safer column by default. It is the column where every failure is legible and every control is yours to get wrong. Choose it when legibility and control are requirements. Choose the managed line when operating the loop is not where your team should spend its attention.
FAQ
If I choose my own sandbox or container, do I control where my data lives?
No. The environment is yours to choose, whether a remote sandbox, a laptop, Docker, or Lambda. The harness is not. Session state is retained server-side, the docs state residency is US-only with no ZDR, and “choosing a self-hosted sandbox does not make the Agents API ZDR-eligible.” The boundary still carries the data (overview).
What happens if my tool handler goes down mid-run?
The docs are direct: if a handler that receives calls and returns results is unavailable, the agent can remain waiting for a result. Failures in event or lifecycle handlers can interrupt progress updates or environment management. Handler availability is a distributed-systems obligation that stays on your side of the line (architecture).
Can I treat Auto-review as my safety control at the boundary?
No. The Auto-review docs say it “only evaluates eligible approval requests,” “can still make mistakes,” and is “not a deterministic security guarantee.” They describe a Codex feature, and they say it should complement sandbox design, monitoring, and organization-specific policy. Your policy layer stays yours (Auto-review docs).
The Bottom Line
The managed harness line is a control-versus-convenience trade drawn in a specific place. Inside the boundary sit the model/tool loop, session state, compaction, and recovery. Outside it sit the environment you execute in, the handlers you keep alive, and the policy your organization is accountable for. Renting the loop removes an operational surface your team no longer maintains. It does not remove residency limits, handler availability, or safety obligations. Those stay with the application.
How This Guide Was Built
This review is based on official OpenAI documentation pages: the Agents API overview, architecture, sessions, environments, lifecycle, compaction, data controls, and Bedrock pages, plus the Codex Auto-review guide, all fetched 2026-10-14. We did not run the tool hands-on, and no pricing pages or community reports were used. Residency, retention, and ZDR statements are vendor-stated and should be verified against current documentation before anyone relies on them for compliance decisions.
📖 Related Reads
- NiteAgent — AI agent development, frameworks, and production patterns
- ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
- NoCode Insider — AI workflow automation with no-code tools, agents, and APIs
Cross-links automatically generated from CodeIntel Log.
