Until recently, I was building a shared Agent Runtime by putting Codex CLI behind a server API. A web UI, n8n workflow, or Salesforce application could call the same execution engine. Each use case would supply its own instructions, runtime context, and output contract.
Then, on September 10, 2026, OpenAI released the Agents API in public beta. It exposes the managed Codex harness and infrastructure for long-running work through an API. OpenAI takes on sessions, orchestration, context management, and recovery.
My first reaction was obvious: do I still need the runtime I built?
The answer is that I should be willing to let some of it go. If its value was simply running a Codex CLI process on my server, a managed API can reasonably replace that implementation. But the boundary I built between the caller and the agent serves a different purpose. Trusted context, execution authority, deterministic state, and business policy do not move to a managed harness just because the harness can run the agent.
The question is which responsibilities can follow the runtime into a managed service, and which must remain with the application.
Why I Built an Agent Runtime in the First Place
Running an agent on my own server was never the goal. Each new AI proof of concept required us to reconnect model calls, authentication, files, tools, sessions, and response formatting. I wanted to shorten the time between a business team’s question and a working response: the feedback latency.
I separated the design into three responsibilities:
- Stable Runtime: the shared foundation for invoking an agent and managing execution state.
- Variable Agent Definition: the instructions, tools, and output contract for a particular use case.
- Runtime Context: confirmed facts supplied by the caller, such as identity, record, scope, and permissions.
The important part was the explicit contract between the calling application and the executing agent. Codex CLI was one way to implement the runtime. The model could change, the CLI could become an SDK, or a self-hosted process could become a managed API. The customer, user, record, permissions, and business state known to the application should not drift along with those implementation choices.
What the Agents API Can Take Over
The Agents API does more than attach a session ID to a model request. OpenAI’s architecture documentation describes a managed Codex harness that runs the model and tool loop while maintaining the session. The application submits work and receives events; where needed, it still manages function tool handlers or the lifecycle of a self-hosted environment. The overview says OpenAI manages sessions, orchestration, context compaction, and recovery, while the application configures tools and the execution environment.
That overlaps with a substantial part of what I had to consider in a self-hosted runtime:
- Agent session lifecycle and long-running turn orchestration.
- Context continuation, compaction, and execution recovery.
- Tool invocation and subagent coordination.
- Sandbox provisioning and work with files and artifacts.
- Progress observation through streaming and webhooks.
The practical change is a smaller operational burden for the agent harness. Long-running agents make questions about process health, session continuity, growing context, intermediate artifacts, and subagent coordination especially persistent. If a managed harness handles those reliably, I have little reason to own every part of that infrastructure myself.
But managing an agent’s execution state is different from managing the authoritative state of a business transaction.
An Agent Session Is Not a Business Transaction
An Agents API session can preserve work across turns. Streams and webhooks can expose progress, and a turn can end as completed, failed, or canceled. That continuity is useful. It does not answer the questions an enterprise application must answer before changing a business record:
- Who initiated the request, and which tenant or account owns the data?
- Which records may this user access or modify?
- Is the action the agent proposed authorized, and does it require human approval?
- Has the same mutation already happened?
- Could a retry after a timeout duplicate a side effect?
- Which system holds the final authoritative state?
Consider an agent that analyzes a Salesforce Case and proposes changing its Category to A. Its session may preserve the reasoning, tool calls, and intermediate results. The session cannot, by itself, establish whether the Case has already changed, whether the current user may edit it, or whether a repeated request should update it again. Those are matters of business transaction state and authority.
This is why I previously separated MCP tool planning from execution authority:
An agent can decide what should be done. The application must decide whether it may actually be done.
A managed runtime does not remove that distinction.
Put a Runtime Contract Between the Application and the Harness
The design question has shifted for me. Instead of concentrating on how to build the Agent Runtime, I now ask how to replace it without changing what the caller means.
The application supplies trusted runtime context to an Agent Runtime Contract. An adapter can route the request to either my self-hosted Codex runtime or the managed Agents API, then return a normalized result. If the result proposes a business action, application policy and a controlled executor handle the path to the business system.
The contract should express the application’s needs rather than copy a particular OpenAI request schema. On input, those needs might include:
- Input and instructions.
- A reference to trusted context.
- A correlation identifier.
- Allowed capabilities and the expected output contract.
- Execution policy and resume semantics.
On output, the contract might normalize:
- Terminal status and a runtime session reference.
- The correlation identifier, artifacts, and proposed actions.
- Execution events and a terminal error class.
The field names are less important than their meaning. An application should keep its own job ID or correlation ID instead of making a vendor session ID or event type into a business identifier. The managed session ID is an execution reference specific to that implementation. Keeping it behind the adapter lets the caller use the same business-facing contract when the runtime changes.
The contract also needs a boundary on writes. I treat an agent’s recommendation as an Execution Proposal. For an Opportunity stage change, the application checks the user’s scope, the current record state, any approval requirement, and an idempotency key. Only then does a controlled executor perform the Salesforce mutation. Readback checks that the resulting state matches what was expected.
The Agents API may be able to coordinate tool calls, but tool connectivity does not grant business execution authority.
Let Requirements Choose the Runtime
A permanent build-versus-buy verdict would hide the reasons for choosing either implementation. A self-hosted runtime can still fit a fast proof of concept, fine-grained execution control, or close integration with existing infrastructure. A managed harness can reduce the work of operating sessions, orchestration, and recovery. The choice depends on the workload:
- Execution environment: private networks and tightly coupled existing systems may favor self-hosting; a standard sandbox and cloud execution may be sufficient for managed execution.
- Operating effort: direct control may justify maintaining a harness; otherwise, delegating its operation may be preferable.
- Experiment speed: an existing internal runtime may be the fastest route; a team starting fresh may benefit from managed sessions and orchestration.
- Regulation and data: some requirements call for self-managed control; others can be met by the provider’s current data controls.
- Change requirements: custom behavior may favor self-hosting, while managed capabilities may be easier to adopt through a service.
One current constraint matters to that decision. As described in OpenAI’s documentation in September 2026, the Agents API supports US data residency only and does not support ZDR. Selecting a self-hosted sandbox does not make the Agents API itself ZDR. Those conditions may change, which is another reason not to turn today’s runtime capabilities into permanent architectural assumptions.
A workload may need self-hosting today for compliance and qualify for managed execution later. Another workload may need to move back into an internal environment. With a stable boundary, that is a runtime migration. Without one, it becomes application redevelopment.
Carry the Boundaries from PoC to Production
This connects to my experience building agent proofs of concept with n8n. I was not arguing that all enterprise AI transformation should run on n8n. It made workflows visible quickly and let us test responsibility for state, validation, branching, and retries with Python and JavaScript. In production, those responsibilities might move to Step Functions, Lambda, Kubernetes workloads, or an application backend.
The same applies to the self-hosted Codex CLI I used in a proof of concept. It does not have to remain the production runtime if the Agents API is a better fit. What should survive is the boundary we validated:
- Who supplies authoritative context?
- What may the agent decide, and which tools may it use?
- Who holds authority for an actual mutation?
- Who owns state and retries?
- How is output validated against a contract?
- How can failures and replay be observed?
When those answers are explicit, changing the runtime implementation is manageable. When authentication, business policy, record state, tool execution, retries, and persistence are all tangled inside one self-hosted process, a better managed API does not make migration easy.
As Agents Improve, the Boundary Matters More
Building a runtime myself helped me see which complexity I would gladly hand to a managed service and which responsibilities the application must retain. Models, harnesses, tools, sandboxes, and multi-agent capabilities will keep changing. Rebuilding the surrounding architecture for each improvement is not a workable plan.
A lasting design may be less about perfecting one Agent Runtime than making it possible to replace that runtime when the requirements change. As managed agents improve, applications still need to define what agents may do and what the applications themselves must own. A clear boundary makes each new runtime an implementation option instead of an architectural threat.