2026 Comparative Analysis: Managed Agent Runtime Control Planes — Applied Technology Index

Executive Summary

A managed agent runtime control plane is a service that owns some combination of the agent loop, deployment, session lifecycle, compute provisioning, state persistence, streaming, identity, and observability. The category is not one product type. A provider may manage the reasoning harness while execution stays in a customer-controlled sandbox, or manage customer-authored containers while the application retains its own loop.

Four current systems expose materially different boundaries:

OpenAI Agents API manages the Codex-derived harness and lets the developer choose OpenAI-managed, self-hosted, or partner compute.
Claude Managed Agents manages the Claude agent loop, event history, and session control plane while tools run either in Anthropic cloud sandboxes or a customer-operated worker.
Amazon Bedrock AgentCore Runtime Instances manages persistent EC2 lifecycle in the customer’s AWS account but lets teams bring any model, framework, and agent code.
Microsoft Foundry Hosted Agents runs customer container images in per-session VM-isolated sandboxes and separates platform-managed endpoints, identity, scaling, filesystem persistence, and optional conversation handling from application-owned orchestration.

The central finding is that harness ownership and compute ownership are independent procurement decisions. “Self-hosted” may mean only that bash, files, and network egress execute on customer infrastructure while prompts, tool inputs, tool results, session history, and orchestration still cross a provider control plane. Conversely, “managed hosting” can mean the provider runs a customer-authored container while the agent loop remains portable application code.

Key findings

A managed agent is not the same as a managed sandbox. OpenAI and Anthropic can manage the harness while execution occurs elsewhere. AWS and Microsoft primarily manage deployment and compute lifecycle around customer code.
Session, conversation, filesystem, and memory are separate state planes. Microsoft explicitly separates sandbox sessions from conversation history. AWS retains EBS volumes across instance stops. Anthropic persists session events and sandbox state. OpenAI manages context and compaction in its harness. None should be described simply as “persistent state.”
Persistent compute and persistent storage are different. AWS terminates an instance at the maximum session lifetime but can retain and reattach volumes. Microsoft deprovisions idle compute while restoring $HOME and uploaded files later. Continuity does not imply one unchanged process.
Customer-controlled execution does not imply customer-only data handling. Anthropic states that tool inputs and outputs still flow through its control plane in the self-hosted model. Any split-plane design needs a field-level data-flow review.
Scale-to-zero changes the failure model. A resumed session may receive new compute, a refreshed image, or a cold start. Agents must externalize process handles, locks, leases, pending side effects, and recovery checkpoints instead of treating local process memory as durable.
Shared workspaces expand the trust domain. AWS can place several agents in one Instances session with a shared filesystem. This lowers coordination overhead but creates cross-agent integrity, identity, and cleanup requirements.
Protocol compatibility is not runtime portability. Microsoft supports Responses, custom Invocations, WebSocket, Activity, and A2A surfaces; OpenAI and Anthropic expose their own session and event resources. Moving an HTTP client does not migrate active state, tool policy, compaction behavior, workspace contents, or audit history.
Version pinning is necessary for resumability. Anthropic can bind a session to an agent version, and Microsoft can bind a session to a concrete immutable agent version. Resuming old state against untested code or tool schemas is a migration, not a routine retry.
Isolation labels need a threat model. A per-session VM, an EC2 instance hosting multiple agents, a provider cloud sandbox, and a customer worker have different kernel, filesystem, network, credential, and tenant boundaries.
The defensible default is an explicit responsibility matrix. Before buying, identify who owns loop behavior, model calls, tool execution, networking, secrets, persistence, tenancy, updates, recovery, audit export, deletion, and incident response.

Methodology

This analysis reviewed primary provider announcements and technical documentation available on 12 September 2026. Topic discovery followed the 10 September public beta announcement of OpenAI Agents API and AWS’s introduction of persistent AgentCore Runtime Instances. Public search and X were used only for signal discovery; the X search service was unavailable during the research window because its configured account had reached its spending limit. Product claims in this article are therefore grounded in provider-controlled sources rather than social posts.

The live Applied Technology Index research index and the local public research collection were checked before selection. Existing ATI articles cover agent harnesses, sandbox infrastructure, persistent workspaces and artifacts, asynchronous task lifecycles, durable execution, context compaction, and runtime policy. This article addresses a narrower unresolved question: which operational layers a managed agent platform owns, and which remain the customer’s responsibility.

Each system was assessed on eleven criteria:

Harness ownership: who controls model-loop logic, context management, tool scheduling, delegation, and stop conditions.
Compute placement: provider sandbox, customer account, customer worker, partner platform, or provider-managed container runtime.
Application packaging: provider-defined agent resource, tools and skills, source bundle, or customer container image.
Session model: lifetime, identity, pause, stop, resume, deletion, and behavior after compute replacement.
State planes: conversation history, filesystem, artifacts, memory, checkpoints, and business state.
Isolation: per-session VM or sandbox, dedicated instance, shared host, filesystem boundary, and credential identity.
Network and data boundary: where model inputs, tool arguments, results, files, and egress travel.
Protocol surface: request, streaming, event, webhook, WebSocket, and remote-agent interfaces.
Versioning: immutable versions, session pinning, runtime updates, and compatibility obligations.
Operations: scaling, observability, policy integration, budgeting, cancellation, and incident controls.
Portability: ability to move code, compute, state, tools, and active sessions independently.

This is a documented-capability and architecture comparison. No paid account was provisioned, and no common workload, cold-start benchmark, multi-day run, failure-injection suite, isolation test, cost model, or data-residency audit was executed across all four services. Preview and beta labels are reported as maturity signals, not as performance rankings.

Comparative Analysis Table

System	Managed boundary	Compute and packaging	Session and state model	Isolation and data boundary	Portability profile	Principal limitation
OpenAI Agents API	OpenAI hosts and maintains the Codex-derived harness, including long-session context management, tool use, tool search, programmatic tool calling, and subagent coordination	OpenAI-managed sandbox, customer infrastructure, or integrated sandbox partner; developers provide tools and select the environment	Managed sessions carry work across long tasks; automatic compaction preserves selected context as limits approach; environment files and artifacts depend on selected compute	Execution location is selectable, but the managed harness and model interaction remain OpenAI services; exact controls vary by sandbox provider	Compute is portable across supported environment modes; harness semantics and active session state remain service-coupled	Public beta; a provider-managed evolving harness reduces operational work but limits control over orchestration behavior and session migration
Claude Managed Agents	Anthropic manages the Claude loop, events, session state, compaction, tool scheduling, streaming, and agent configuration	Agent resource contains model, prompt, tools, MCP servers, and skills; tools run in an Anthropic cloud sandbox or customer worker	Server-side event history and conversation continuity; stateful sessions retain sandbox state and outputs; sessions can pin agent versions and set a list-cost budget	Self-hosting moves code, files, processes, and egress to the customer, but tool inputs and outputs still flow to Anthropic; skills and attached memory stores remain provider-managed and are synchronized	Tool execution can move to customer infrastructure; orchestration, event history, agent resources, and memory integration remain Anthropic-coupled	Beta and not eligible for Zero Data Retention or HIPAA BAA coverage in the documented stateful service; self-hosted workers still require provider control-plane data exchange
Amazon Bedrock AgentCore Runtime Instances	AWS manages EC2 provisioning, patching, scaling, stop/restart, teardown, runtime invocation, and integration with AgentCore identity and observability	Any model or framework; source bundle or container; capacity provider defines OS, allowed instance types, VPC, storage, and infrastructure roles in the customer’s AWS account	Session identified by customer-supplied `runtimeSessionId`; maximum run of 14 days; stopped sessions can resume on a new instance with retained EBS volumes; several agents can share one session	Managed EC2 runs in the customer account and VPC; agents have runtime-specific IAM credentials; multiple agents may share host filesystem and GPUs	Application and framework are portable; operational configuration and persisted volumes are AWS-specific; compute type cannot change after runtime creation	Persistent instance economics and first-start latency; shared sessions enlarge the trust boundary; customer remains responsible for application recovery and cross-agent state correctness
Microsoft Foundry Hosted Agents	Microsoft manages endpoint, per-agent identity, version routing, per-session compute, filesystem persistence, scaling, lifecycle, and built-in telemetry; customer code owns orchestration	Customer container image in Azure Container Registry; framework-agnostic protocol libraries; selectable CPU and memory	Session persists `$HOME` and `/files` across idle deprovisioning for up to 30 days of inactivity; conversation history is separate and platform-managed only for Responses	Per-session VM-isolated sandbox; Entra authenticates calls and a separate isolation key partitions sessions; customer container and downstream data flows remain customer responsibility	Containerized loop is comparatively portable; session APIs, filesystem restore, identities, protocol hosting, and active conversation records remain Foundry-specific	Hosted agents and session operations include preview surfaces; scale-to-zero cold starts and no traffic splitting require deliberate upgrade and recovery design

Observed Profiles

OpenAI Agents API: managed harness with a selectable execution plane

OpenAI Agents API exposes the harness and infrastructure behind Codex as a public beta service. OpenAI operates the loop while developers define the work, tools, and environment. The launch documentation identifies three compute routes: an OpenAI-managed sandbox, customer infrastructure, or an integrated partner environment. Named launch partners include Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel.

This design separates reasoning control from execution placement. The harness can coordinate model calls, web retrieval, MCP and custom tools, programmatic tool calls, and subagents while code and file operations execute in another environment. The partner layer broadens choices for VPC placement, file and secret handling, CPUs, GPUs, memory, cold starts, and cost.

OpenAI also positions harness evolution as part of the managed product. Automatic context compaction, dynamic tool search, code-mediated tool-result processing, and parallel subagents can improve without every customer rebuilding its own loop. That is the main operational benefit and the main coupling risk. A session’s behavior depends not only on a named model but on the provider’s versioned harness, context selection, scheduling, and tool semantics.

The correct portability claim is therefore limited. A team may relocate execution while retaining the same managed orchestration, but that is not equivalent to exporting the full live agent. Migration requires the conversation or compacted context, workspace and artifacts, tool configuration, credentials, pending external operations, subagent state, and enough harness behavior to continue consistently. The launch materials establish compute choice; they do not establish a vendor-neutral active-session format.

For high-consequence use, record the selected harness version or compatibility channel, model, environment provider, sandbox image, tools, skills, policy, and operation IDs. Treat every managed harness update as a possible behavioral change even when application code is unchanged.

Claude Managed Agents: provider-owned session semantics with customer-executed tools

Claude Managed Agents organizes the service around Agent, Environment, Session, and Event resources. The agent defines the model, system prompt, tools, MCP servers, and skills. The environment chooses Anthropic cloud execution or a self-hosted worker. A session binds the configuration to a task, and events carry messages, tool requests, tool results, status changes, compaction signals, and multi-agent communication.

The event model is operationally useful because it makes steering, interruption, status, and tool exchange explicit rather than hiding them inside one long HTTP request. Event history persists server-side and can be fetched. Sessions can reference the latest agent version or pin a concrete one. A session can also apply bounded overrides and can receive a hard list-cost budget expressed in whole US cents; enforcement occurs between model requests, so the request that crosses the limit completes first.

Anthropic’s self-hosted mode provides one of the clearest published split-plane descriptions. Tool code, filesystem access, spawned processes, and network egress stay on customer infrastructure. An environment worker polls or receives a webhook, claims a work item, creates an execution context, downloads skills, runs tools, and returns results. However, tool inputs and outputs still pass through Anthropic so Claude can decide what to do next. Skills and attached memory-store content are stored by Anthropic and copied or synchronized into the worker.

That boundary prevents a misleading conclusion: private egress does not mean every datum remains private to the customer environment. A tool result containing source code, customer records, credentials, or internal URLs may still enter the provider control plane and model context. Deployments need argument and result filtering before the worker posts data back, plus explicit rules for which tools may expose which classifications.

The standard file-tool path restrictions are also not a complete sandbox. Anthropic documents that file tools can be confined to working and allowed roots, while bash is not constrained by those path guards. Strong isolation therefore requires a container, microVM, or equivalent boundary around each session, not merely an allowed_roots configuration.

Claude Managed Agents is beta and stateful. Anthropic states that it is not currently eligible for Zero Data Retention or HIPAA BAA coverage. Teams with those requirements should not assume that moving tool execution to a self-hosted worker changes the control-plane retention status.

Amazon Bedrock AgentCore Runtime Instances: persistent customer-account compute

AgentCore Runtime Instances addresses workloads that do not fit a short-lived serverless microVM: multi-day jobs, specialized GPUs, direct operating-system access, or several collaborating agents on one host. AWS provisions and operates EC2 managed instances in the customer’s account through a capacity provider. The customer selects allowed instance types, VPC and subnets, storage, operating system, and IAM roles, while AgentCore manages instance lifecycle and patching.

A session is an isolated EC2 instance identified by a runtimeSessionId. The first invocation provisions the instance. Later invocations reuse it while active. A session may run for up to 14 days, compared with up to 8 hours for AgentCore microVMs. At the maximum lifetime, AgentCore stops the session and terminates the instance but can retain its persistent EBS volumes. Reusing the session ID provisions a new instance and reattaches those volumes.

This makes a critical distinction concrete: session continuity is volume continuity, not process continuity. Open file descriptors, child processes, in-memory queues, GPU state, kernel state, and uncommitted local transactions do not survive instance replacement. A reliable agent must checkpoint durable state, detect incomplete work, reconcile external side effects, and rebuild runtime-only resources after resume.

Runtime Instances also permits multiple agent runtimes that share one capacity provider to use the same session ID and land on the same EC2 instance. They can coordinate through a shared filesystem and share access to GPUs. Each agent runs with IAM credentials derived from its own runtime execution role, but filesystem sharing creates another authority channel. One agent may alter another’s inputs, executable code, caches, or artifacts unless directory ownership, integrity checks, and mount policy prevent it.

The model is attractive where data residency, existing AWS controls, Savings Plans, reserved capacity, VPC access, or GPUs matter more than scale-to-zero economics. It is not a serverless abstraction: the EC2 resources are billable in the customer account, and first invocation includes provisioning latency. The capacity provider is also structurally important because most of its configuration cannot be edited after creation, and compute type cannot be changed after a runtime is created.

Microsoft Foundry Hosted Agents: portable container code inside a managed session shell

Foundry Hosted Agents packages customer agent code as a container image and runs it on Microsoft-managed infrastructure. The platform creates a dedicated endpoint and Microsoft Entra agent identity, provisions a per-session VM-isolated sandbox, manages lifecycle and scaling, persists session files, and injects observability configuration. The container owns the agent loop and can use Microsoft Agent Framework, LangGraph, another framework, or custom code.

This is the inverse of the managed-harness pattern. The customer retains orchestration code while the provider manages the runtime shell. That can reduce behavioral lock-in because the container and framework can be tested elsewhere. It does not make live state portable: the endpoint, identities, session volumes, version bindings, conversation records, background behavior, and telemetry remain Foundry resources.

Microsoft makes a particularly useful distinction between a session and a conversation. A session identifies sandbox compute and the persisted $HOME and /files state. A conversation identifies message, tool-call, and response history. Under the Responses protocol, Foundry can manage conversation history and associate a session automatically. Under the Invocations protocol, the customer container manages conversation state even though the platform still preserves the sandbox filesystem.

Hosted Agents expose Responses, arbitrary-JSON Invocations, bidirectional Invocations over WebSocket, Activity integration, and preview A2A support. These protocol choices determine which lifecycle functions the platform manages. A Responses-compatible endpoint may thread history and support background execution, while a custom Invocations container owns more of its request, stream, and state contract.

The compute model scales per session. An idle timeout between 5 and 60 minutes, with a 15-minute default, deprovisions compute and saves state. Referencing the session later restores $HOME and /files onto compute. Sessions are permanently deleted after 30 days of inactivity. This design needs restart-safe containers: state required after a cold resume must live in preserved storage or an external service, not only in process memory.

Foundry versions are immutable snapshots of container image, resources, environment variables, and protocol configuration. A session can be pinned to a concrete version. At the endpoint level, one version receives all traffic; the documentation states that traffic splitting is not supported. Operators therefore need pre-deployment compatibility tests, explicit session pinning, and a rollback strategy rather than assuming a gradual percentage rollout.

The isolation key deserves careful interpretation. It partitions which sessions an authenticated caller can address, but Microsoft states that it is not authentication or authorization. Entra ID and application-level controls still decide who may act. Treating a tenant header as a security decision would collapse routing metadata into access control.

A practical responsibility matrix

Before selecting a managed runtime, complete this matrix for the exact deployment:

Responsibility	Questions that require a named owner
Harness	Who versions the loop, compaction, tool scheduling, retries, delegation, and stopping behavior?
Model	Who selects models, regions, inference policy, fallback, retention, and safety settings?
Compute	Where do commands run, who patches hosts, and what survives deprovisioning?
Files and artifacts	Which paths persist, who can read them, how are they versioned, exported, and deleted?
Conversation and memory	Are messages, summaries, memories, and events separate stores with separate retention?
Identity and secrets	Which principal signs provider calls, tool calls, and infrastructure operations?
Network	Which egress paths exist, and which inputs and results cross the provider boundary?
Isolation	Is the boundary a process, container, microVM, VM, account, VPC, or application partition key?
Side effects	Where are idempotency keys, approvals, transaction records, and reconciliation results stored?
Versions	Can old sessions remain pinned, and what happens when images, models, skills, or schemas change?
Operations	Who handles quotas, budgets, cancellation, telemetry, deletion, forensics, recovery, and incident response?

A service should not pass production review until every row has an enforceable answer and a tested recovery path.

Selection guidance

Choose a managed harness with selectable compute when agent-loop maintenance, context compaction, tool scheduling, and model-specific orchestration are the main burden, and service coupling is acceptable. OpenAI Agents API and Claude Managed Agents fit this profile, but their self-hosted execution options must be reviewed as split-control-plane architectures rather than full self-hosting.

Choose customer-account persistent instances when multi-day execution, GPUs, shared local workspaces, VPC locality, or existing EC2 commercial commitments dominate. AgentCore Runtime Instances provide the clearest infrastructure control in this set, but teams still own recovery correctness, shared-filesystem security, and persistent-instance economics.

Choose managed per-session container hosting when the application must retain its own loop and framework while delegating identity, endpoints, isolation, scaling, filesystem restoration, and telemetry plumbing. Microsoft Foundry Hosted Agents fit this model, with preview maturity, cold-start behavior, and platform session semantics included in the trade.

For regulated or high-consequence workloads, run the same failure-oriented acceptance suite against at least two candidates:

terminate compute during a model call, tool call, and external side effect;
resume after idle deprovisioning and maximum session lifetime;
pin an old session while deploying a new agent version;
revoke a credential or tool permission mid-session;
attempt cross-session, cross-user, and cross-agent filesystem access;
send secrets and regulated data through tool inputs and outputs to map control-plane exposure;
disconnect and reconnect every stream, webhook, and WebSocket path;
exhaust session budget, disk, memory, token, time, and concurrency limits;
export conversation, workspace, artifacts, policy decisions, and audit records independently;
reconcile one uncertain side effect without replaying it.

The winning platform is the one whose failures are observable, bounded, and recoverable under the organization’s data and authority model—not the one with the shortest first-agent tutorial.

Limitations

This analysis reflects documentation available on 12 September 2026. OpenAI Agents API was announced in public beta on 10 September 2026. Claude Managed Agents is beta. Microsoft Hosted Agents and session operations include preview surfaces. AWS Runtime Instances were newly announced. Interfaces, limits, regions, prices, data terms, partner support, and maturity labels can change quickly.

The compared products are not strict substitutes. OpenAI and Anthropic manage a provider-defined agent harness. AWS manages persistent infrastructure around customer agent code. Microsoft manages per-session container hosting and exposes several application protocols. Their placement in one table is intended to reveal control-plane boundaries, not produce a universal winner.

No common workload was run. This article does not measure task quality, cold-start time, throughput, concurrency, token consumption, instance utilization, GPU performance, persistence latency, storage durability, trace completeness, recovery time, or total cost. Provider documentation describes intended behavior but does not independently prove tenant isolation, correct deletion, policy enforcement, patch quality, or incident response.

The OpenAI announcement page was reachable through indexed official search content but returned an automated-access challenge to a direct non-browser request during this research run. Claims about the service are limited to the official announcement’s indexed text and do not extend beyond the provider’s published launch description.

Self-hosted and customer-account execution do not create identical compliance outcomes. Model requests, tool inputs, tool results, event history, skills, memory, logs, or telemetry may still be processed by provider services. Buyers must verify current contracts, data-flow diagrams, regional availability, retention, encryption, subprocess isolation, and subprocessor terms for their exact configuration.

Persistent files do not guarantee a recoverable business process. None of the reviewed storage mechanisms alone ensures exactly-once execution across email, payments, deployments, orders, or other external systems. Idempotency, durable intent records, remote-status lookup, and reconciliation remain application responsibilities.

This is technical infrastructure research, not a security certification, compliance opinion, or procurement approval. Production use requires architecture review, threat modeling, legal and privacy review, cost testing, failure injection, and workload-specific acceptance criteria.