OpenAI’s Agents API separates operation of the agent loop from control of the conditions under which the agent’s work becomes an enterprise action.
OpenAI’s Agents API introduces a consequential enterprise primitive: access to the Codex harness through an OpenAI-managed API. OpenAI manages sessions, orchestration, context compaction, and recovery, while the application supplies tools and chooses the execution environment.[1] The announcement describes the same separation in operational terms: OpenAI hosts and maintains the harness, while developers choose an OpenAI-hosted sandbox, their own infrastructure, or a supported sandbox provider.[2]
That is more than a deployment convenience. It separates operation of the agent loop from control of the conditions under which the agent’s work becomes an enterprise action.
Luminity’s architectural interpretation is a divided control plane composed of two cooperating control planes: OpenAI can operate the managed Codex harness while the enterprise retains responsibility for task admission, authority, connected-system access, consequential effects, and accountability. “Divided” does not mean disconnected. It means that one agentic system is governed through distinct but connected control domains.
The OpenAI Primitive: A Managed Codex Harness
OpenAI defines the Agents API as a way to build durable cloud agents with a managed Codex harness. The harness runs the model and tool loop and maintains the agent’s session. OpenAI’s documented managed responsibilities include sessions, orchestration, context compaction, and recovery.[1][3]
The narrow documented capability is therefore precise: the application can delegate operation of the Codex harness to OpenAI while continuing to select and configure the supported tools and execution environment.
The harness can run commands and code in a sandbox, apply skills and instructions, connect through tools or MCP, accept steering during work, compact earlier context, delegate to subagents, and resume a session.[1] OpenAI also exposes durable sessions, event streams, webhooks, and cancellation mechanisms so applications can submit work, follow progress, continue or steer a session, and stop active work while retaining the conversation.[1][4]
OpenAI describes the Agents API as powered by the open-source Codex harness and links to the first-party openai/codex codebase.[2][6] That repository provides visibility into the underlying Codex project; it does not, by itself, document the complete hosted Agents API control plane or transfer responsibility for enterprise authorization.
These capabilities reduce the amount of harness infrastructure an application team must build and operate. They do not, by themselves, answer who may submit a consequential task, which credentials the task may use, whether a downstream system should accept the resulting action, or what evidence the enterprise must retain.
The Enterprise Property: A Divided Control Plane
The Agents API architecture distinguishes three pieces: the harness, the environment, and the application server. OpenAI runs the harness. The environment is where commands, code, and files operate. The application server submits tasks, receives events, handles function tools, and—when the customer supplies the environment—manages its lifecycle.[3]
That separation creates the enterprise property this Dispatch owns.
The first control plane is managed agent operation. It includes the ongoing mechanics of the agent loop: session continuity, orchestration, context management, harness recovery, tool requests, and results.
The second control plane is enterprise authority and action conditions. It includes who may admit a task, the applicable Authority Envelope, which tools and connected systems are available, the credentials and downstream permissions in force, when intervention is required, how the enterprise recovers the workflow or consequential effect, and which Audit Trails support accountability.
The first plane can be managed by OpenAI. The second remains composed across the enterprise application, identity and access systems, the chosen environment, connected services, human decision points, and organizational policy. Recovery exists in both planes at different layers: OpenAI manages recovery of the harness and session, while the enterprise owns recovery of its workflow, connected systems, and consequential outcomes.
This is not a claim that OpenAI lacks controls. OpenAI documents configuration, sandbox, session, tool, vault, observability, and administration capabilities throughout the Agents API surface.[1][3] The architectural point is narrower: platform operation and enterprise authorization are different responsibilities, even when platform controls help implement the enterprise design.
Managed Work Is Not Yet Authorized Action
An agent can complete useful work inside the managed harness before that work is permitted to create a consequential effect.
Consider a remediation agent investigating a production incident. The harness may coordinate subagents, inspect supplied evidence, maintain context, call approved tools, and produce a proposed mitigation. None of those steps alone establishes that the proposal may change production.
The path from managed work to authorized action should remain explicit:
- Enterprise intent defines the task, owner, purpose, and expected outcome.
- Execution-path classification determines the consequence, reversibility, and operating conditions of the workflow.
- The Authority Envelope specifies the permitted tools, data, resources, operations, time, delegation, and escalation conditions.
Between boundary definition and consequential action, the Agents API and managed Codex harness perform the agent work within the configured tools and environment.
- Authorization and enforcement boundaries permit, constrain, interrupt, or deny the requested effect.
- The consequential effect reaches the enterprise system only when every applicable boundary permits it.
- Evidence connects intent, authority, agent activity, the resulting action, and its outcome.
This sequence does not place an enterprise approval gate around every model step. It distinguishes agent work from the point at which that work becomes an effect the enterprise must own.
OpenAI’s architecture supports this composition. Function tools are executed by application code, which receives the call and returns the result. In a self-hosted environment, the customer’s executor runs commands requested by the harness, while the application owns provisioning, reconnection, shutdown, and file persistence.[3] With either environment choice, the application can receive events and inspect results.[3]
The enterprise recommendation is therefore to place authorization where consequence occurs. A model-generated request, a harness tool call, or a human approval inside one interface should not be treated as universal authorization across every connected system.
Hosting Changes Operations, Not Authority
The Agents API supports more than one environment pattern, and the allocation of operational work changes with that choice.
With an OpenAI-hosted environment, OpenAI creates and manages the sandbox. The customer configures the packages, files, and network access the agent needs, while the application continues to send tasks, receive events, and handle function tools.[3]
With a self-hosted environment, the customer starts the environment, connects an executor, and owns provisioning, reconnection, shutdown, and preservation of required files. The executor performs the commands and tools requested by the harness.[3]
That self-hosted environment may run in the enterprise’s AWS account. This does not make the Agents API an AWS-operated service: OpenAI still manages the Agents API and Codex harness, while AWS hosts the customer-controlled execution environment. OpenAI and AWS separately offer OpenAI models, Codex on Amazon Bedrock, and Amazon Bedrock Managed Agents powered by OpenAI; those are distinct deployment paths rather than an AWS edition of the Agents API.[2][7]
As a partner of both OpenAI and AWS, Luminity treats that product boundary as architecturally material. Provider partnership does not collapse service identity, operating responsibility, data processing, or enterprise authority into a single control plane.
This changes infrastructure responsibility. It does not determine enterprise authority.
In either pattern, the enterprise still needs to decide which tasks are admissible, which identities and credentials may be used, what downstream systems authorize, when an action must stop or escalate, and what accountability attaches to the result. Hosting can move compute, filesystem, lifecycle, and network responsibilities. It cannot make the enterprise’s purpose, risk acceptance, or downstream authorization decisions.
The better architecture question is not simply “Where is the sandbox hosted?” It is:
Which party operates each component, which party grants each authority, and where is each consequential effect independently enforced?
Operating-Model Consequences
A divided control plane requires explicit interfaces between the managed harness and the enterprise operating model.
First, task admission becomes an enterprise control. A durable session is an operating capability, not a reason to accept every requested task. Applications should establish who may initiate or continue work, for which purpose, against which environment, and under which Authority Envelope.
Second, tool exposure becomes an authority decision. OpenAI can operate tool discovery and tool calling, but the enterprise chooses which tools exist, which identities they use, which calls require application handling, and what connected systems independently permit.[1][3]
Third, intervention requires joint design. OpenAI provides steering, events, webhooks, cancellation, and session management.[1][4] Enterprises still need operational ownership for who monitors, who may intervene, what conditions trigger interruption, and what recovery or escalation follows.
Fourth, observability must be reconciled with accountability. The Agents API exposes session events and dashboard inspection of turns, tool calls, and subagent activity. OpenAI notes that detailed trace retrieval and external trace exporters are not part of the public beta API, usage can be best-effort, and command-output truncation is not reported.[5] These records are valuable operational evidence, but they are not automatically a complete enterprise Audit Trail or proof that a decision was correct.
Finally, environment selection becomes an architectural decision rather than a shorthand for control ownership. Hosting placement should follow workload requirements for infrastructure, private-network reach, software, data, performance, recovery, and operational responsibility. Authority design should follow the workflow’s purpose, consequence, reversibility, identity, and downstream enforcement needs.
Limits and Responsibility Boundaries
The divided-control-plane interpretation has important limits.
It is an architectural model, not an OpenAI product name or an OpenAI guarantee. OpenAI documents the Agents API, managed Codex harness, environment choices, sessions, tools, and observability. Luminity uses “divided control plane” to describe the enterprise responsibility structure that emerges from those primitives.
A managed harness does not guarantee safe, correct, compliant, or authorized outcomes. Context compaction and recovery support continuity; they do not establish that retained context is trustworthy. Tool orchestration can execute configured capabilities; it does not establish that each downstream effect is semantically appropriate. Steering and cancellation create intervention mechanisms; they do not guarantee that intervention occurs before an irreversible effect.
An OpenAI-hosted sandbox does not transfer ownership of enterprise purpose, credentials, connected-system authorization, data classification, or accountability to OpenAI. A self-hosted sandbox does not give the enterprise control over the internal operation of OpenAI’s managed service. In both cases, responsibilities remain composed.
Observability is not complete provenance. Events and traces can show important activity without proving the legitimacy of the active Authority Envelope, capturing every downstream decision, or establishing the correctness of the result.[5]
The Agents API is in public beta, and OpenAI states that it will iterate toward general availability.[2] Product details may evolve. The durable architecture should therefore depend on explicit responsibility boundaries rather than incidental beta behavior.
The Durable Architectural Claim
A managed agent harness changes who operates the agent loop; it does not transfer the enterprise authority under which consequential action occurs.
The Agents API creates a divided control plane: OpenAI can operate the managed Codex harness while the enterprise retains control over the conditions under which execution becomes authorized action. The architecture is credible when those domains meet through explicit task admission, Authority Envelopes, enforcement boundaries, intervention paths, and accountable evidence.
Manage the harness as a service. Govern authority as an enterprise responsibility.
A managed agent harness changes who operates the agent loop; it does not transfer the enterprise authority under which consequential action occurs.
Manage the harness as a service. Govern authority as an enterprise responsibility.
