OpenAI's Managed Agents API: Hosted Sandboxes vs Self-Hosted Execution

The plumbing that comes before the agent

Anyone who has built an autonomous agent knows how much of the work has nothing to do with the agent's actual job. Before reaching the interesting logic, a team has to write the execution loop, store conversation state, choose which tool runs next, recover from failures, compact context as sessions grow and supply a secure place to run code and touch files. Only then does the real task get its turn.

OpenAI's managed agents service, in public beta now, is meant to lift most of that burden. Developers don't get one more model endpoint to bolt onto an orchestration framework. They get a managed runtime for agents. Four inputs describe the whole job: the task, the model, the tools and the environment where work happens. The platform then covers a large share of the machinery needed to run it.

The engine underneath deserves attention. OpenAI is turning the harness behind its own coding agent, Codex, into infrastructure for outside builders. It's much more than a thin layer over a chat or completion API: it holds the orchestration that drives an agent through repeated steps, decides tool use, manages an expanding session and runs execution, and it can coordinate extra agents on parts of a problem simultaneously.

The starting line moves as a result. Teams no longer need to spend the early phase of a project rebuilding the machinery that makes an agent operate, and they can begin much nearer the application. What lets an agent run, act, recover and coordinate turns into a managed capability.

What the managed harness covers

The bet behind the release is that most requirements for reliable agents are shared, not product-specific. Whatever the business problem, an agent needs a record of what has happened in the session, a way to match the next step to the right tool, a method for shrinking a conversation that's outgrown the context window, and a way to split large work into independent parts. Those are largely solved problems, and every company re-solving them in its own code wastes time that belongs to the product.

Centralizing that logic in one managed harness gives developers a base to build upon in place of one they'd pour themselves. The harness owns the model loop: context goes to the model, a decision comes back, it's executed, and the result returns as new input. It keeps session state so long tasks don't lose earlier progress. It compacts context on its own as a session approaches the model's capacity. And it chooses which tool definitions matter right now, sparing the model from irrelevant options.

Choosing where the agent works

After the task, model and tools are defined, one decision remains: where does execution happen? The service offers a real fork here, and the trade-offs between the two paths matter more than almost anything else in setup.

Hosted workspace

In the first path, OpenAI spins up a full Linux workspace per session and runs it. Python, Node.js and common command-line utilities come preinstalled, which gives the agent somewhere to execute code, work with files and produce results while the developer never handles a virtual machine, container image or deployment pipeline. Finished tasks can have their outputs converted to immutable artifacts, handy for teams that want a permanent, unchangeable record of precisely what a given run produced.

Because OpenAI handles provisioning and the sandbox lifecycle from creation through teardown, this route suits rapid deployment. A team wanting an agent up quickly, without days of internal infrastructure approvals or deployment scripting, gains a lot by pointing a session at OpenAI's compute. It also fits elastic workloads, where agent runs may spike unpredictably and the team would rather not own scaling logic. Selecting it takes a small environment block naming the hosted type and a directory for capability files.

"environment": {
  "type": "openai_hosted",
  "capability_directories": ["/workspace/capabilities/skills"]
}

Self-hosted execution

The second path leaves execution on infrastructure the developer owns, be it a container, a virtual machine or a remote sandbox from a third-party provider. Inside that environment sits a component named the exec server, which dials out to OpenAI over a WebSocket. Commands flow in from the managed harness over that link, and the exec server runs shell operations and local Model Context Protocol interactions on the developer's machine before sending results back.

One security detail stands out. The connection uses a restricted key created for that purpose, so the broader application-level API key never has to sit inside the execution environment. If the environment were compromised, an attacker would find a credential with narrower scope than the full application key.

Self-hosting hands a team far more say over which compute is used, how private networks are reached and where data lives. Regulated organizations, and teams whose agents must reach internal systems that the public internet can't see, will typically need that. Yet control brings chores: the team handles isolation and security patches for the environment, scaling under load, monitoring and cleanup when sessions end. Having orchestration managed somewhere else leaves all of this untouched.

What stays with OpenAI either way

It's tempting to assume that self-hosted execution means the agent runs entirely under a company's roof, cut off from OpenAI after the first model call. That would be wrong. Even self-hosted, OpenAI keeps running the harness and the model-side orchestration that decides what the agent does at each step. Only the execution layer moves, meaning the actual commands, file handling and compute. The reasoning loop, session management and coordination logic stay on OpenAI's side of the connection whichever environment a team picks.

Long sessions and large tool catalogs

Anything beyond a trivial agent runs into two problems fast. One is sessions that outgrow a model's context window. The other is tool catalogs so big that sending every definition with every request burns tokens and slows the model down. The managed harness takes on both.

For long sessions, it compacts earlier context automatically as a conversation nears its limit, keeping what the agent still needs and discarding what's become irrelevant. A workflow can therefore span far more than one context window without hand-written summarization or truncation logic.

For tool-heavy work, a feature called tool search brings in only the definitions that apply to the current step, reducing token use and cost and helping keep the model's cache intact. After the right tools load, a companion capability allows programmatic tool calls. The agent can fire several calls in parallel, chain related operations, and filter or merge results in code so only the useful portion reaches the model's context. With large data volumes that's a big advantage, since the agent needn't scan every raw result for the handful of relevant facts.

The configuration lists tools in the agent block, including an MCP server entry.

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "internal_docs",
      "transport": {
        "type": "http",
        "server_url": "https://docs.example.com/mcp"
      }
    }
  ]
}

Several agents on one task

Perhaps the boldest capability is native support for multiple agents working on one task in parallel. Instead of making a single agent plow through a complex problem step by step, a developer can switch on multi-agent support and let the harness split the task into independent pieces. Each piece goes to a subagent with its own separate context.

Every subagent stays focused on a narrow assignment and doesn't juggle the whole task, while a coordinating main agent oversees the effort and merges results into a final answer. For research, large-scale analysis or coding that divides into independent streams, this structure can noticeably shorten completion time, and nobody has to design and build an orchestration layer for concurrent agents.

Enabling it takes a flag in the agent's configuration, alongside the model choice.

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

Which path fits which team

The two execution paths correspond neatly to two sets of priorities. Teams that put speed first, and like never thinking about compute, are served by managed sandboxes. Someone validating a new agent idea, or launching without haggling over infrastructure budgets, will probably adopt the hosted route sooner and spend less engineering time doing so.

Self-hosting makes more sense once requirements outgrow what a shared, general-purpose sandbox can satisfy. Examples include private networks the agent must reach, custom machine images with proprietary tooling, specialized compute such as particular GPU configurations and regulated data boundaries that bar information from leaving a jurisdiction or network. In those cases the extra operational responsibility is just the cost of doing things correctly.

Who should wait

Not every team has to rush toward this offering. If an existing SDK-based loop works reliably, handles retries gracefully and causes little friction for its maintainers, there may be scant reason to migrate. Replacing a working system merely because a managed alternative exists tends to add risk without matching benefit.

Things look different when session state, retry handling and failure-recovery logic have become a real time sink. Passing those jobs to a managed service that already handles them, and gets better with each model release, frees substantial capacity for work that actually differentiates a product.

A fair rule of thumb: hand off whatever you don't need to control, and keep a grip on whatever the business depends on. That counts most for deployment topology, sensitive-data handling and the exact, predictable production behavior of an agent. Infrastructure that no one on the team wants to own should be delegated. Behavior that defines a product's reliability or a company's compliance stance shouldn't.

Open foundations

One feature lends the release credibility: the harness rests on open-source foundations. OpenAI operates and maintains the production build within the managed service, while the code underneath can still be inspected publicly. Anyone curious how the model loop, tool selection and subagent coordination behave can read the logic and skip the documentation. That openness balances the otherwise closed character of a fully managed cloud service and helps teams trust what's running their production workloads.

Pricing and beta status

Public beta is open to all developers, with no separate subscription fee stacked on regular usage. Charges track the tokens a session uses and the tools it calls, under the standard pricing already set for the underlying models. Since developer feedback will keep shaping the service on the road to general availability, early adopters should plan for shifts in behavior, defaults and features across the next months.

A managed Agents API built on the harness that already powers Codex marks a real change in how much infrastructure a team must build before an autonomous agent does useful work. By offering a fully hosted environment and a self-hosted path that still gets centrally managed orchestration, OpenAI lets developers choose the trade-off that fits their situation and doesn't force one deployment model on everyone.

The adoption call reduces to a question that suits any new infrastructure layer: does it remove work nobody wanted to own, and does it keep the team firmly in charge of what defines the product?