Managed Agent Harness vs Self-Hosted Agent Loop: What You Gain, What You Lose

The phrase “self-hosted agent” now hides at least three different architectures. You can use a managed harness with OpenAI-hosted compute, a managed harness connected to infrastructure you operate, or run the harness and agent loop yourself. Those choices have very different implications for control, recovery, context management, security, latency, and operational burden.

The mistake: treating self-hosting as one decision

In conventional software, “self-hosted” usually means the application runs on infrastructure you control. Agent systems complicate that definition because the runtime can be split. The model-and-tool loop can run in one place while code execution, files and private-network access happen somewhere else.

OpenAI's current Agents API architecture makes this split explicit: OpenAI runs the harness, while the execution environment can be absent, OpenAI-hosted, or self-hosted. A self-hosted environment therefore does not mean the agent loop is self-hosted.

This distinction matters because many teams choose a more complex runtime than they need. They want private-network access or custom packages, conclude that the entire agent must be self-hosted, and accidentally take ownership of context management, orchestration, recovery and lifecycle that could have remained managed.

Three architectures that are often called “self-hosted”

The two-plane model

Managed harness: what you actually gain

A managed harness removes more than a while-loop. OpenAI's current Agents API manages sessions, orchestration, context compaction and recovery. Anthropic's work on managed agents describes the same broader motivation: harnesses contain assumptions about model behaviour, and those assumptions need to evolve as models improve.

That means the benefit is not only fewer lines of code. The platform can update runtime behaviour, long-horizon context handling, subagent coordination and recovery without requiring every application team to rebuild those mechanisms.

• Less application-owned orchestration code.
• Managed durable-session behaviour.
• Managed context compaction and recovery.
• A runtime that can evolve with model capabilities.
• Simpler adoption of platform-native subagent and long-running-agent features.
• Potentially lower operational burden for teams whose differentiation is not the harness itself.

Managed harness: what you give up

Delegating the harness also delegates some control. Your application no longer owns every detail of iteration, context strategy, orchestration and runtime evolution. A platform update can improve the system, but it can also change behaviour your product implicitly depended on.

This creates a different kind of engineering requirement: strong evals, explicit product boundaries and an integration layer that prevents managed-session behaviour from becoming your business source of truth.

Self-hosted execution environment: the middle architecture

OpenAI's self-hosted environment model is important because it decouples private compute from harness ownership. The platform still runs the Codex harness, while an executor runs inside your environment and receives commands over an outbound connection.

You control provisioning, files, dependencies, network access and cleanup. The harness can therefore work against private infrastructure or custom software without requiring the entire agent runtime to move into your application.

The cost is lifecycle responsibility. Your application must map sessions to compute, avoid duplicate provisioning, reconnect environments, coordinate shutdown and preserve any files that must outlive the environment.

When self-hosted execution is enough

• The agent needs access to a private VPC or internal service.
• The agent needs custom binaries, packages, drivers or system software.
• The workload must run on hardware or cloud accounts you control.
• Files must remain inside a controlled environment.
• You need your own sandbox provider or isolation model.
• You want platform-managed orchestration but infrastructure-controlled execution.

When you may need to own the harness too

Owning the harness becomes justified when the harness itself is part of your product differentiation or constraint set. OpenAI's current runtime overview positions the Codex SDK for running the Codex harness in infrastructure you operate, while Responses is the lower-level option when you want to own the agent loop yourself.

The key is to identify a requirement that genuinely lives in the harness plane, not the execution plane.

The Control Escalation Test

Use the least self-hosted architecture that satisfies the actual requirement. Escalate control one layer at a time.

Operational burden grows nonlinearly when you own the harness

A self-operated loop sounds simple in a demo: call model, inspect tool call, execute tool, append result, repeat. Production adds durable state, retries, duplicate events, cancellation, approval, context overflow, tool timeouts, process restarts, trace persistence, backpressure, concurrent work and recovery after partial side effects.

Long-running-agent research from Anthropic repeatedly shows that harness design materially affects performance. Their work on long-running application development uses explicit planning, structured artifacts and evaluator agents because naïve loops tend to lose progress or terminate prematurely. The harness is therefore production logic, not plumbing.

Security boundary: self-hosting compute does not automatically make the agent private

A self-hosted execution environment controls where commands run and where files live, but the managed harness and model interaction still cross the service boundary. Teams should therefore map data flows explicitly rather than use “self-hosted” as shorthand for a privacy property.

OpenAI's self-hosted executor uses restricted environment credentials and outbound connections. That is useful isolation, but your application still needs its own rules for secrets, private-network exposure, user-to-environment isolation, file retention, tool authorization and data classification.

Latency and cost: control can move bottlenecks rather than remove them

Self-hosting may reduce some data-path or environment-startup costs, but it can also add provisioning time, WebSocket lifecycle, cold starts, sandbox cleanup, observability infrastructure and engineering overhead. A managed environment may cost more per unit of compute while being cheaper to operate at low or irregular volume.

The correct comparison is total system cost: model and tool usage, environment time, infrastructure, engineering effort, on-call burden, failure recovery and the cost of slower iteration.

A production decision matrix

Hybrid is not a compromise — it is often the clean architecture

A managed harness with self-hosted execution is not “half self-hosted.” It is an intentional separation of concerns. The platform owns long-horizon agent-runtime complexity, while your infrastructure owns execution, private connectivity and files.

That boundary resembles other cloud architectures: managed control plane, customer-controlled data or execution plane. The important design work is defining the contract between them — session identity, environment identity, credentials, files, tool permissions, lifecycle events and cleanup.

What would change this answer?

The recommendation changes if managed harnesses expose substantially more runtime control, if self-hosted harnesses gain simpler durable-session and recovery primitives, or if regulation requires the entire agent loop and model interaction to remain inside infrastructure you operate.

It also changes with model capability. Anthropic explicitly notes that harness assumptions can become stale as models improve. A control mechanism that is essential today may become unnecessary later, while a new model capability can create a new governance requirement.

Limitations

This article separates architecture responsibilities; it does not claim that one hosting model is universally more secure, cheaper or more reliable. Those outcomes depend on implementation, workload, compliance requirements, team skill and provider behaviour.

The OpenAI Agents API is still in public beta, and managed-agent products from different vendors expose different boundaries. The two-plane model is intended to help compare those architectures without assuming that every vendor uses identical terms.

Conclusion

The useful question is not “Should we self-host the agent?” It is: Which plane do we actually need to control?

If the requirement is private compute, custom packages, local files or internal-network access, self-host the execution plane and keep the harness managed. If the requirement is orchestration semantics, context strategy, provider control or runtime lifecycle itself, then harness ownership may be justified. Escalate control only as far as the requirement demands.

FAQ

Glossary

Primary sources and further reading