Who should own your agent loop?

OpenAI put the Agents API into public beta on 10 September. The headline capability is useful: I can create a session with a model, tools, environment and input in one call, while the managed Codex harness handles orchestration, sessions, context compaction, recovery, tool search, MCP support and optional subagents.

For me, though, the interesting decision is not whether that machinery works. It is whether I want the provider to own the agent loop at all. Once I am building an automation for a client rather than a disposable demo, the runtime, session state and data path become part of the architecture.

The plumbing is worth removing

A lot of agent engineering is not especially distinctive. Session storage matters, but I rarely want it to be the clever part of a project. The same goes for retry behaviour, recovering a run, compacting a growing context and arranging a sandbox in which tools can operate.

The Agents API turns that collection of concerns into a managed harness. Environments can be OpenAI-hosted, self-hosted or provided through partner sandboxes. OpenAI lists Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel.

That is attractive for prototypes. When I am testing whether an agent workflow is useful, I would rather spend my time on the tool boundaries, permissions and failure cases specific to the job. This is also why I like building small, self-contained demos in my prototype lab: the question at that stage is whether the workflow deserves to exist, not whether I have built the perfect runtime around it.

There is no extra API fee for the Agents API itself; usage still means paying for tokens, tools and containers. I would still measure the whole workflow rather than treating "no extra fee" as "no runtime trade-off".

Managed means somebody else owns the loop

The distinction in OpenAI's documentation is unusually helpful here. The Agents API is for cases where OpenAI runs the harness. The Agents SDK is for cases where I run the loop inside my own application. The Responses API remains the lower-level option for raw model calls. The new API does not replace the SDK.

InfoWorld described the managed service as removing the need to assemble a runtime, session store and sandbox. That is exactly the convenience, but it also describes what I am giving up control over.

With an in-app loop, I can decide where state lives, how execution is observed, where policy checks happen and which systems see which data. With a managed loop, I need to understand the provider's answers to those questions rather than assuming my application's boundaries still apply.

That is not automatically bad. It is simply a different ownership model.

Residency belongs in the first architecture review

This is where a quick prototype can create an awkward future decision. The Agents API documentation currently states US data residency and says Zero Data Retention is not available on this API.

For a UK or EU client, or any workflow involving regulated information, I would treat that wording as an early contract and architecture question. I would not wait until the workflow has proved itself, accumulated integrations and quietly become production infrastructure.

The practical questions I want answered are straightforward:

• What information enters the managed session?
• What state is retained, where, and under which terms?
• Does the client's policy permit that data path?
• Would moving the loop later change the compliance or audit story?

Those answers depend on the client and the data. The important bit is asking before implementation convenience hardens into architecture.

MCP is the useful escape hatch

MCP being first class is the part I find most strategically useful. If my business tools are MCP servers with clean contracts, the agent harness becomes less coupled to the actual capabilities.

That matters because the MCP ecosystem is moving independently of any one agent runtime. In the same week, Google's mcp-toolbox v1.11.0 added MCP Apps and MCP Resources, while FastMCP v4.20.10 and v4.20.11 shipped fixes around httpStream ping defaults, hidden-tool capability and tool output schemas.

I do not read those releases as a reason to chase every MCP feature. I read them as evidence that the tool boundary is becoming a useful place to invest. If the tools remain mine, changing who runs the loop is closer to an infrastructure decision than an application rewrite.

My default for client builds

My current rule is simple: prototype on the managed harness, but keep the tool layer as MCP servers I control.

That gives me the boring runtime work for free while I am still discovering the workflow. If the prototype becomes a product, I can then make the runtime decision with actual requirements in front of me.

I would move the loop into the application when latency, total cost, residency requirements or a client's audit requirements justify owning it. Until one of those constraints appears, I would rather not maintain orchestration plumbing merely to prove that I can.

The part I want to own from day one is the boundary around the tools. Runtime ownership can change. Rebuilding every integration because the first harness became permanent is the migration I would rather avoid.