Managed Agent Runtimes - What Claude Managed Agents, the OpenAI Agents API, Amazon Bedrock, and GKE Agent Substrate Each Run for You, and What Stays With You

First Published: 2026-10-03
Last Updated: 2026-10-03

Developers who currently manage their own agent loops now have more options to delegate loop management, tool execution sandboxes, and session persistence to providers. These self-managed loops can be built using technologies such as the Messages API, Responses API, Claude Agent SDK, Strands Agents, and OpenAI Agents SDK. Anthropic's Claude Managed Agents entered public beta on April 8, 2026. AWS's Amazon Bedrock AgentCore Harness became generally available (GA) on June 17, 2026. OpenAI's Agents API entered public beta on September 10, 2026. Google's GKE Agent Substrate was made available for evaluation and non-production use on September 11, 2026. AWS's Amazon Bedrock Managed Agents entered preview on September 29, 2026.

While often discussed together as part of the broader category of "managed agents," each platform handles different responsibilities. GKE Agent Substrate does not have an agent loop. The GitHub repository clarifies that Agent Substrate is not an SDK for building agents, but rather a system for running agents at scale. Configuration management also varies across platforms. With Claude Managed Agents, agent configurations have versions, and sessions are tied to the version at creation. During a session, only the agent's tools and mcp_servers settings can be modified. With OpenAI Agents API, sessions copy the configuration of the saved agent at creation. Updating the saved agent only affects new sessions. During a session, the model, reasoning.effort, and service_tier can be changed; tools and instructions cannot. The two platforms have reversed capabilities regarding what can be modified mid-session.

Even if you choose a configuration where the tools are executed on a user's own infrastructure (a self-hosted sandbox), the loop and model inference remain with the provider. Anthropic states that, even with a self-hosted sandbox, the orchestration remains with Anthropic while the tool execution is shifted to the user's infrastructure. The input and output of the tools continue to flow to Anthropic's control plane. OpenAI likewise states that even when choosing a self-hosted sandbox, the managed harness and model inference will utilize OpenAI's services.

This article presents a comparison of five products from four different companies, aligning descriptions from each company's official documentation under the same perspective. The perspectives being compared are: the loop, the sandbox for executing tools, session state persistence, configuration versions and pinning to sessions, what can change during a session, tool permissions, limits, credentials, and memory. Cells where information is not found in the source material are marked as "not found" rather than being filled with speculation. The article does not include rankings, recommendations, pricing, or performance metrics. This article is based solely on materials reviewed on October 3, 2026, and has not been verified through practical testing.

Related articles on this site:

1. What This Article Compares, and the Verification Date
2. The Same Aspects, Side by Side
3. When a Configuration Change Takes Effect — The Effect Timing Table
4. Claude Managed Agents
5. OpenAI Agents API
6. AWS — AgentCore Harness and Amazon Bedrock Managed Agents
7. GKE Agent Substrate
8. What Stays on the Provider's Side Even with a Self-Hosted Sandbox
9. Where the Sources Disagree
10. Frequently Asked Questions about Managed Agent Runtimes
11. Summary
12. References

1. What This Article Compares, and the Verification Date

This section first defines how this article counts the products and how it distinguishes words that name different things. Following that, it records the dates of verification, the consulted materials, the status of each product, and what is not covered.

1.1 Four Providers, Five Products, and How They Were Chosen

This article focuses on four companies and five products. Only AWS offers two products within this selection.

Anthropic's Claude Managed Agents
OpenAI's Agents API (hereinafter referred to as OpenAI Agents API)
AWS's Amazon Bedrock AgentCore Harness (hereinafter referred to as AgentCore Harness)
AWS's Amazon Bedrock Managed Agents (hereinafter referred to as Bedrock Managed Agents. The abbreviation used in AWS documentation is BMA)
Google's GKE Agent Substrate (hereinafter referred to as Agent Substrate)

These five are not exhaustive; rather, they represent the products selected for this article. The selection focuses on products from these four companies that became available as platforms for running agents, or reached General Availability (GA), between April and September 2026. Products from other providers are not covered. Underlying products from the same company are not listed in columns but are mentioned in the main text. AgentCore Runtime (a runtime to which users bring their own code, including the loop) will be discussed in Section 6, and GKE's Agent Sandbox (GA in May 2026) will be mentioned in Section 7.4. AWS's two products differ in who wrote the loop. The AgentCore Harness utilizes Strands Agents, an open-source framework from AWS. Bedrock Managed Agents is an AWS-specific adaptation of OpenAI's Agents API. Therefore, this article divides AWS into two separate columns. Agent Substrate does not have a loop, but it is included in the list as an agent platform. The fact that it lacks a loop is itself one of the results of this comparison.

1.2 Words That Name Different Things

The materials covered in this article frequently use the same term to refer to different things. For clarity, this article will use the following distinctions.

Managed Agents: Anthropic's Claude Managed Agents and AWS's Bedrock Managed Agents are separate products. This article will consistently refer to Anthropic's product as Claude Managed Agents and AWS's product as Bedrock Managed Agents.
Harness: Each company refers to the component that manages the agent's loop and surrounding processes as a "harness." The harness for OpenAI's Agents API is an instance of Codex hosted by OpenAI. AgentCore Harness is the name of an AWS product. The harness for Bedrock Managed Agents is an OpenAI Codex harness running within Amazon Bedrock. Anthropic describes its product, Claude Managed Agents, as an agent harness that can be configured. When this article uses the term "harness," it will always specify which company's harness is being referenced.
Session: Each company's sessions are distinct resources. OpenAI's documentation states that the Agents API session, the Agents SDK session, the Responses API conversation, and the sandbox are all separate resources. The session for AgentCore Harness is identified by the runtimeSessionId and refers to a session in the AgentCore Runtime. In this article, "running session" refers to the resource for that session, located on the provider's side.
Vault: Both Anthropic and OpenAI use the term "vault" to refer to a location where credentials are stored. The two vaults have different functions (see Section 2.3). The token vault within AgentCore Identity, which AgentCore Harness uses to retrieve API keys, is also a separate entity. It is not related to AWS Backup's vault.
Agent: When this article uses the term "agent configuration," it refers to the configuration resource stored on the provider's side. This corresponds to Claude Managed Agents' agent and the saved agent within OpenAI's Agents API.
Agent Sandbox and Agent Substrate: Google has two entities: Agent Sandbox and Agent Substrate. Google's GKE documentation states that Agent Substrate is built on top of Agent Sandbox's functionality. This article will focus on Agent Substrate. The differences between the two are described in Section 7.4.

1.3 The Verification Date and the Sources Read

This article's content is based on information verified by reviewing official documentation from various companies on October 3, 2026. Since platform.claude.com and developers.openai.com do not display update dates, the date the information was obtained is considered the verification date. The materials reviewed are listed below (see Section 12 for URLs).

Anthropic: Overview of Claude Managed Agents, Start a session, Session operations, Cloud environment setup, Define your agent, Permission policies, Session budgets, Authenticate with vaults, Using agent memory, Tools, Self-hosted sandboxes, Security model, Session event stream, Reference, ant apply page, API references for Update Session and Update Environment, Pages for each platform, API and data retention, Release notes.
OpenAI: 24-page guide for the Agents API (Agents API, Architecture, Configuring Agents, Run and continue sessions, OpenAI-hosted sandboxes, Self-hosted sandboxes, Vaults, Plugins, Files and artifacts, Sandbox security, Errors and recovery, Bedrock Managed Agents, and more), Agents page, API reference, Changelog, Deprecations.
AWS: Developer guide for AgentCore (specifically, the 14 harness pages) and the InvokeHarness API reference, the page describing how AgentCore Runtime works (titled "microVMs"), the Troubleshoot AgentCore Runtime page, sections on Bedrock Managed Agents in the Bedrock user guide, and the Amazon Bedrock Agents Classic maintenance mode page, What's New, AgentCore and Bedrock FAQ.
Google: Documentation for GKE, including the About GKE Agent Substrate page (Last updated 2026-10-02 UTC), GKE release notes, two blog posts from Google Cloud, the README and portions of the docs from GitHub's agent-substrate/substrate, the README from kubernetes-sigs/agent-sandbox, a proposal issue for the CNCF sandbox, and the Agent Substrate page on the CNCF website.

1.4 Status and Availability (as of October 3, 2026)

The following table details the status of each product and where it is offered. The status terminology used reflects the language used in each company's documentation.

Product	Provider	Status	Where It Is Offered	Agent Loop
Claude Managed Agents	Anthropic	Beta. The overview page states that all endpoints require the `managed-agents-2026-04-01` beta header (see Section 4.5 for memory store endpoints). Became public beta on April 8, 2026.	Claude API and Claude Platform on AWS. The Amazon Bedrock, Google Cloud, and Microsoft Foundry pages list Claude Managed Agents as a feature that is not currently supported.	Anthropic runs the loop.
OpenAI Agents API	OpenAI	Public beta (since September 10, 2026). Requires the `OpenAI-Beta: agents=v1` header in requests.	OpenAI API	A Codex harness hosted by OpenAI runs the loop.
AgentCore Harness	AWS	Generally Available (GA) since June 17, 2026. However, the AgentCore FAQ still lists it as "preview" (see Section 9).	AgentCore regions (refer to the region table in the developer guide).	AWS runs the loop (with a harness built with Strands Agents).
Bedrock Managed Agents	AWS (developed jointly by AWS and OpenAI)	Preview (since September 29, 2026). Was in a limited preview starting April 28, 2026.	US East (N. Virginia), US West (Oregon), US East (Ohio)	OpenAI's Codex harness runs the loop inside Amazon Bedrock.
Agent Substrate	Google	Available for evaluation and non-production use by all Google Cloud customers. Production support is provided through a private GA program with an allowlist. The open-source core is pre-version 1.0.	User's own GKE Standard cluster.	Not part of the product.

Regarding Claude Managed Agents, two differences are outlined on the Claude Platform on AWS page compared to Anthropic's Claude API (first-party). First, a session can run autonomously, without user events, for a maximum of 6 hours before requiring re-authentication. Second, a session on a self-hosted environment cannot attach a memory store.

1.5 What This Article Does Not Cover, and Related Articles

This article focuses solely on comparing the functionalities offered by different companies, presenting them from a consistent perspective. The following topics will not be addressed:

Determining who runs the loop across Anthropic's three components (Client SDK, Claude Agent SDK, and Claude Managed Agents) is covered in Section 2 (SDK vs Raw Messages API) of Claude Agent SDK Complete Guide. This article will focus only on Claude Managed Agents, aligning them with the offerings of other companies.
The configuration options, the items that can be overridden per invocation, and the responsibilities remaining with the user in the Amazon Bedrock AgentCore Harness are detailed in Amazon Bedrock AgentCore Harness. This article will only present the key points.
The unit of isolation and the design that avoids storing credentials are discussed in Agent Sandboxing and Blast-Radius Isolation on AWS. The differences between gVisor and virtual machines are explained in Section 5.3 (Two Shapes - A User-Space Kernel and a Virtual Machine per Pod) of Workload Isolation Levels on Amazon EKS.
The process of modifying tools or instructions mid-conversation in the Claude API's Messages API is covered in Mid-Conversation Changes in the Claude API. Claude Managed Agents is the layer one level above it.
Usage details for Claude Agent SDK, Strands Agents, and OpenAI Agents SDK.
The process of migrating from OpenAI's Assistants API, Agent Builder, and Amazon Bedrock Agents Classic.
Rankings, recommendations, pricing, and performance metrics.

2. The Same Aspects, Side by Side

This section will align five products across rows that share a common perspective. The table will be divided into three parts: the first focusing on who runs what, the second addressing configuration management, and the third covering tool permissions, limits, credentials, and memory.

2.1 Who Runs What

Aspect	Claude Managed Agents	OpenAI Agents API	AgentCore Harness	Bedrock Managed Agents	Agent Substrate
Agent loop	Anthropic	OpenAI-hosted Codex harness	AWS. A harness built with Strands Agents runs in the AgentCore Runtime.	Amazon Bedrock's OpenAI Codex harness	Not part of the product. The agent code running on Agent Substrate runs the loop.
Model inference	Anthropic's side	OpenAI's service	The provider of the chosen model. If not specified, uses Amazon Bedrock's models.	Amazon Bedrock	Not part of the product.
Tool execution	`cloud` (managed by Anthropic) or `self_hosted` (user's infrastructure)	`none` (no execution environment), `openai_hosted`, `self_hosted`	Built-in shell and file operations run in microVMs that are isolated per session. Inline functions are executed in the user's code.	`self_hosted` (user's compute resources) or `aws_bedrock_agentcore` (AgentCore Runtime)	Sandboxes using gVisor or Cloud Hypervisor. Within the user's GKE cluster.
Session state the provider keeps	Conversation history, sandbox state, and output are stored on the server. Sandbox state is retained for 30 days from creation.	Agent configuration, conversation, and saved work. OpenAI-hosted sandboxes may be deleted if inactive for 1 hour.	Session storage (if configured) and conversation state from AgentCore Memory (if enabled).	Conversations managed by the service. Their lifecycle is separate from that of the execution environment's files.	The provider does not keep it. The user-managed Agent Substrate stores snapshots of suspended agents' RAM and local files in Cloud Storage.
What your application does	Sends events and receives results as a stream. Executes custom tools. If `self_hosted`, runs an environment worker.	Sends tasks and receives events. Handles function tools. If `self_hosted`, runs an executor (`codex exec-server`).	Calls the harness. Executes inline functions.	Sends and receives events. If `self_hosted`, runs an exec server.	Provides the agent's code itself (including the loop).

The following figure uses color-coding to differentiate between the five rows of this table based on whether the provider or the user is responsible, whether the user can choose, or whether the item is not part of the product. The colors indicate only the responsible party and do not represent any judgment of quality.

Who Runs What in a Managed Agent Runtime

2.2 Configuration — Versions, Pinning, and Mid-Session Changes

Aspect	Claude Managed Agents	OpenAI Agents API	AgentCore Harness	Bedrock Managed Agents	Agent Substrate
Saved configuration	Agent (model, system, tools, mcp_servers, skills, etc.)	Saved agent (instructions, model, reasoning, tools, etc.)	Harness	Not found in the documentation. The API reference does not list any operations to save agent configurations. Configurations are passed at session creation.	Model and tool configurations are not part of the product. An ActorTemplate defines the container image, environment variables, and compute resources.
Versions	A version number increments by 1 each time the configuration is changed.	The versioning mechanism is not found in the documentation.	A new version is created with each update, and the version does not change after it is created.	Not found in the documentation.	ActorTemplates are treated as immutable; new versions use new templates (per the OSS glossary).
Which configuration a session uses	A snapshot of the agent's version at the time of creation. If only the ID string is passed, the latest version is used.	The saved agent's configuration, copied at creation.	The version that the endpoint specified in each call (DEFAULT if omitted) points to (per the general rule on the Runtime page).	The configuration passed at creation.	Not applicable.
Override for one session at creation	`agent_with_overrides` (model, system, tools, mcp_servers, skills).	Overrides applied at creation, effective only for that specific session.	Overrides specified for each call (see the next row).	Not found in the documentation.	Not applicable.
Changes during a session	`tools` and `mcp_servers` (when the session is `idle`). Addition via `system.message` events (for supported models only). Changing or removing the budget. API-based file addition and deletion for session resources.	`model`, `reasoning.effort`, `service_tier`.	For each call, it is possible to override model, system prompt, tools, etc. The harness resources do not change.	Not found in the documentation. The API reference does not list any operations to update a session's configuration.	Not applicable.
Cannot change during a session	Model (including `inference_geo`), system, skills, `vault_ids`. Memory stores can be attached only at creation.	`reasoning.summary`, `text`, `tools`, `instructions`, `multi_agent`.	The execution environment, memory, lifecycle hooks, and other items outside the 9 that can be overridden per call are changed by updating the harness, which creates a new version (for memory, see Section 9).	Not found in the documentation.	Not applicable.
Saved configuration updated while a session runs	The running session retains the toolset configuration from the time of creation. Updates apply to sessions created later.	The running session does not change. Updates only apply to new sessions.	The harness pages do not name it (Section 3.4).	Not found in the documentation.	Not applicable.

In this table, the term "not applicable" indicates that a particular aspect does not apply to that product. It should be distinguished from "not found in the documentation" (see Section 2.4). The API reference for Bedrock Managed Agents limits its scope to the session, event, and item operations used in the preview examples. The operation that lists sessions can be filtered by agent_id, and the response includes the agent field, which contains the agent's ID. Therefore, this article marks the empty cells for Bedrock Managed Agents as "not found in the documentation."

2.3 Tool Permissions, Limits, Credentials, and Memory

Aspect	Claude Managed Agents	OpenAI Agents API	AgentCore Harness	Bedrock Managed Agents	Agent Substrate
Tool permissions	`always_allow`, `always_ask`, `auto`. The default for the agent toolset is `always_allow`, while the default for the MCP toolset is `always_ask`.	Tool-specific approval settings are not found in the guide. For computer use, there is approval required before the browser navigates to a new origin. With MCP, the `allowed_tools` setting can restrict the tools that are available.	Tools available can be restricted using `allowedTools`. Calls can be stopped using the `before_tool_call` lifecycle hook. Inline functions return calls to the user's code.	The user guide calls for applications or tools to enforce authorization and any required human review for actions with external effects. With MCP, the `allowed_tools` setting can restrict the tools that are available. The What's New post from September 29, 2026, mentions support for human approval before high-impact actions (Section 9).	Not applicable.
Budgets and limits	Session budget. The session will transition to `idle` when the list cost reaches the cap, and stops with the `budget_reached` stop reason.	How users can set a session budget is not found in the guide. An error `session_budget_exceeded` exists.	Limits such as `maxIterations`, `timeoutSeconds`, and `maxTokens`. The definition of `maxTokens` varies across documentation (Section 3.4 of Amazon Bedrock AgentCore Harness).	A user-set budget is not found in the documentation. The Preview availability and limitations page states that the example configuration limits and the account limits apply.	Not applicable.
Credentials	Vault. `environment_variable` is replaced with the actual value during egress, and the agent does not see the value. `environment_variable` is not yet supported in self-hosted sandboxes.	Vault. In the `openai_hosted` sandbox, the network proxy replaces placeholders. Credentials are not supplied to self-hosted environments.	The harness retrieves credentials from the AgentCore Identity token vault at the time of the call.	Sessions use three identities: the caller, the role assumed by the service, and the identity the execution environment uses.	A Google Cloud blog post and the OSS documentation mention injection via proxy, while the GKE documentation lists it as unsupported (Section 9).
Memory	Memory store (`agent-memory-2026-07-22`). Attached at session creation.	Not found in the guide.	AgentCore Memory. The default value varies across documentation (Section 9).	The user guide states that there is no built-in long-term memory. The FAQ states that memory persists across sessions (Section 9).	RAM and file snapshots. A long-term memory store is not found in the documentation.

2.4 How to Read the Empty Cells

The empty cells in the three tables can be categorized into three types:

Not part of the product, not applicable: This refers to cases where the information falls outside the scope of the product, as indicated by the documentation or evident from the product's structure. The loop and the model inference for Agent Substrate fall into this type.
Not found in the documentation: This refers to information that could not be found after searching with different search terms, even after reviewing the documentation read on October 3, 2026, and following links within that documentation. This does not necessarily mean the information is nonexistent. Examples include tool-level approval settings, user-defined session budgets, and memory for the OpenAI Agents API. The search terms used are listed in Section 5.5.
Not named in the documentation: This refers to cases where the documentation contains general principles, but does not specifically address the subject of the particular row. This applies to what happens to running sessions when the AgentCore Harness is updated, which the harness pages do not name (Section 3.4).

3. When a Configuration Change Takes Effect — The Effect Timing Table

This section outlines when changes to settings take effect, presenting this information in an Effect Timing Table. The table uses the same columns as those found in Mid-Conversation Changes in the Claude API. AGENTS.md Across Coding Agents also uses a table with the same columns.

3.1 Columns and Values

The common columns are as follows:

What You Give It: This refers to the data being passed. In this article, this includes updates to agent configurations, session updates, events, and credential replacements.
Where It Is Set: This indicates the location where the data is placed. In this article, this refers to resources such as agents, sessions, environments, and vaults.
When It Takes Effect: This describes the point at which the change becomes active, as documented in the materials. The values are selected from the vocabulary listed below.
What a Running Session Keeps: This specifies what is retained from an ongoing conversation or session when a change is made. Write it only when the source states it explicitly.
Where the Source Says So: This indicates the source document that supports the information in that row.

The running session referenced in this article refers to the session resource located on the provider's side (see Section 1.2).

The values for When It Takes Effect are selected from the following vocabulary. On the next request is the same value used in Mid-Conversation Changes in the Claude API. The other five values have been added in this article.

At session creation: The change takes effect when the session is created. Subsequent changes will not apply to that session.
From the next turn on: The change takes effect from the next turn after the change is made.
From that turn on: The change takes effect from the turn associated with the event and all subsequent turns.
For one invocation: The change takes effect only for that single invocation.
Periodically during the session: The change takes effect when the information is periodically re-evaluated during the session. The material does not specify the interval.
On the next request: The effect applies from the next request sent. In this article, this refers to the next request that calls AgentCore Harness.

In the What a Running Session Keeps column, begin each entry with one of the following terms. Unchanged indicates that the running session maintains the previous settings without alteration. Changed for this session only means that only the settings for that specific session are modified, leaving saved settings and other sessions unchanged. Changed for this call only signifies that only the settings for that single instance are altered. Reaches running sessions indicates that the change applies to currently running sessions. Do not begin entries with these terms for rows that only describe general rules or rows that state The source does not say.

For cells where the source material does not provide information, write The source does not say. Before writing it, search the full text of the sources the row cites, and the pages they link to, using the terms running, existing, new sessions, already, version, and update, as well as the subject of the row. If the source material only describes general principles and does not specifically mention the subject of the row, do not write The source does not say.; write that fact in the cell instead.

3.2 Effect Timing Table, Part 1 — Claude Managed Agents

What You Give It	Where It Is Set	When It Takes Effect	What a Running Session Keeps	Where the Source Says So
Agent updates (new version)	Agent	At session creation	Unchanged. A running session retains the toolset configuration from when it was created. Updates apply to sessions created later.	Define your agent, Start a session, Permission policies
Overrides using `agent_with_overrides`	Session creation request's `agent`	At session creation	Changed for this session only. The agent resource itself remains unchanged, and no new version is created.	Start a session
Updates to `tools` and `mcp_servers`	Session. Only when the session is `idle`.	From the next turn on	Changed for this session only. The entire array is replaced. It is not propagated back to the agent.	Session operations, Reference
`system.message` event	Session event	From that turn on	Changed for this session only. The agent's `system` is not replaced; instead, the event's content is appended as a `role: "system"` turn. Supported models only.	Session event stream, Session operations
Environment updates	Environment	The source does not say.	The source does not say. The source says only that environments are not versioned.	Cloud environment setup
Vault credential rotation	Vault	Periodically during the session	Reaches running sessions. Rotation, archiving, and deletion are reflected in running sessions without requiring a restart.	Authenticate with vaults

This table contains two cells that state The source does not say. Both are in row 5, the environment update. A search of the Cloud environment setup page, the Update Environment API reference, and the environment.updated row of the webhooks page, using the terms above and environment, found no information regarding the impact on running sessions. Regarding environment archiving, a comment in the code examples on the page states that existing sessions will continue.

3.3 Effect Timing Table, Part 2 — OpenAI Agents API

What You Give It	Where It Is Set	When It Takes Effect	What a Running Session Keeps	Where the Source Says So
Updates to the saved agent	Saved agent	At session creation	Unchanged. The session retains a copy of the settings as they were at creation. Subsequent updates to the saved agent will not affect the session.	Configuring Agents
Overrides at session creation	Session creation request	At session creation	Changed for this session only. This change does not affect the saved agent or other sessions.	Configuring Agents
Updates to `model`, `reasoning.effort`, or `service_tier`	Session (`POST /v1/agents/sessions/{session_id}`)	From the next turn on	Changed for this session only. The update takes effect from the turns started by messages sent after the update completes. A turn already in progress keeps the previous settings. Conversation history remains unchanged.	Configuring Agents
Replacing credentials for `environment_variable` within a vault	Vault	At session creation	Unchanged. Existing credentials configured within an existing sandbox will not be changed. To use the replaced values, create a new session.	Vaults
Updates to vault MCP credentials (`mcp_oauth`, `static_bearer`)	Vault	The source does not say.	The source does not say. The Vaults page describes updates that replace secrets without changing the ID or authentication type, but does not mention the impact on running sessions.	Vaults
Changes to a plugin file or an environment template that lists plugins	Plugin, environment template	At session creation	Unchanged. Existing sessions will not re-read the tools. To use the changes, create a new session.	Plugins

This table contains two cells that state The source does not say. Both are in row 5, the MCP credential update. A search of the Vaults page using the terms from Section 3.1 and credential and refresh found no description of the impact on running sessions. The same page states that even if stored credentials are deleted, the original token is not revoked with its provider, and running sessions do not stop.

3.4 Effect Timing Table, Part 3 — The Two AWS Products

What You Give It	Where It Is Set	When It Takes Effect	What a Running Session Keeps	Where the Source Says So
AgentCore Harness update (new version)	Harness	On the next request (a call through the DEFAULT endpoint; per the general rule on the Runtime page; for sessions already running, see the next column)	Only the general rules are documented. The DEFAULT endpoint automatically updates to point to the new version, while named endpoints remain associated with the original version. The harness versioning mechanism is the same as that used in Runtime, and the Runtime page states that requests are resolved to the version the endpoint points to. The harness pages do not name running sessions. The Runtime page names running sessions for platform version V2: sessions already running on a previous runtime version's snapshot continue until they end. The troubleshooting page for Runtime states that sessions continue to use the code assets deployed at their creation, even after updating those assets with `UpdateAgentRuntime`, until the session ends. Which `platformVersion` a harness runs on was not found on the harness pages (Section 6.3).	AgentCore harness versioning and endpoints, AgentCore Runtime page, Troubleshoot AgentCore Runtime
Per-invocation overrides (model, system prompt, tools, etc.)	`InvokeHarness` request	For one invocation	Changed for this call only. The harness resources themselves do not change. Even if you change the model for each call in the same session, the conversation continues.	Models and instructions
Update to the source of the skill	Source of the skill	At session creation (retrieved during the first call of the session)	Unchanged. Within the session, the retrieved skill remains stored. When the VM expires and a new session begins, it is retrieved again.	Skills
Configuration of Bedrock Managed Agents sessions (model, instructions, tools)	`agent` in the session creation request	At session creation	The source does not say. The API reference lists operations (7 in total), but does not include an operation to update session configuration.	BMA preview REST API reference
Update to the AgentCore Runtime used as the execution environment for Bedrock Managed Agents	AgentCore Runtime definition	At session creation	Unchanged. The processes running in the existing session are not replaced. To apply changes, you must create a new session.	Troubleshooting (Bedrock Managed Agents)

This table contains one cell that reads The source does not say. This cell refers to the session settings for Bedrock Managed Agents on the fourth row. A search of the Bedrock Managed Agents documentation using the terms update, version, and existing session found no information on how to modify the settings of a running session. The API reference limits its scope to the operations used in the preview examples (Section 2.2). The first row simply states that the harness pages only describe general principles and do not explicitly mention running sessions. The harness versioning page indicates that the harness versioning mechanism is the same as AgentCore Runtime versioning. A search of the 14 AgentCore Harness pages this article read, using the terms running session, existing session, already running, and in-flight, found no results. The term new session yielded one result, corresponding to the description of skill reacquisition on the third row.

Agent Substrate does not have any rows in this table. This is because Agent Substrate does not store resources such as models, tools, or instructions. The ActorTemplate mentioned in the GKE documentation is a blueprint that defines container images, environment variables, and compute resources.

3.5 Two Rows That Run in Opposite Directions for Anthropic and OpenAI

When comparing Sections 3.2 and 3.3, two rows run in opposite directions.

The first concerns settings that can be changed mid-session. In Claude Managed Agents, agent configurations that can be modified mid-session are those on the tool side (tools and mcp_servers). The model and system settings cannot be changed. With the OpenAI Agents API, the settings that can be modified mid-session, apart from metadata, are those related to the model (model, reasoning.effort, service_tier). The tools and instructions settings cannot be changed. In both cases, to modify settings that cannot be changed mid-session, a new session must be created.

The second concerns replacing environment variable-formatted credentials (environment_variable). In Claude Managed Agents, credentials stored in the vault are periodically re-read throughout the session and delivered to the running session. Even if you replace the environment_variable credentials in the OpenAI Agents API vault, the credentials for existing sandboxes will not change. A new session is required. The documentation does not specify whether changes to MCP credentials in OpenAI affect running sessions.

Conversely, updating saved configurations does not affect running sessions in either system. Claude Managed Agents pins sessions to a version, while the OpenAI Agents API copies the configuration at creation time. Although the mechanisms differ, in both cases, the changes only apply to new sessions. AgentCore Harness differs from these two; it resolves the version through the endpoint each call names (DEFAULT if omitted; resolution of the version is governed by the general rules on the Runtime page) and accepts overrides with each call. The harness pages do not name running sessions (Section 3.4).

The following diagram illustrates the timelines for Claude Managed Agents, OpenAI Agents API, and AgentCore Harness, showing when configuration changes take effect. Within the diagram, the terms At session creation, From the next turn on, From that turn on, For one invocation, and On the next request refer to the values described in Section 3.1.

When a Configuration Change Reaches a Running Session

4. Claude Managed Agents

This section describes what Claude Managed Agents takes on, following Anthropic's documentation. Claude Managed Agents are currently in beta. The overview page states that all endpoints require the managed-agents-2026-04-01 beta header (the handling of memory store endpoints is detailed in Section 4.5). According to the overview page, access to Claude Managed Agents is enabled by default for all API accounts.

4.1 Agent, Environment, and Session

Claude Managed Agents consist of three distinct resources:

Agent: This encompasses the configuration, including the model, system, tools, mcp_servers, and skills. It has a version.
Environment: This defines where the session will run. Users can choose between Anthropic's managed cloud sandbox (cloud) or a self-hosted sandbox on their own infrastructure (self_hosted). Multiple sessions can share a single environment. In a cloud environment, each session is provided with a separate sandbox (a new Linux container).
Session: This represents the running agent, referencing both an agent and an environment.

The overview page states that Claude Managed Agents are designed to be stateful. Sessions can run for extended periods, and can be resumed after interruption. Conversation history, sandbox state, and output are all stored on the server. Anthropic runs the loop. User applications send events and receive results in a streaming format. The user's application executes custom tools, so they are not subject to the permission policies outlined in Section 4.4.

4.2 Versions, and Three Forms That Decide Which Version a Session Uses

An agent's version number starts at 1 and increments by 1 each time the agent is updated. If an update doesn't change the agent's configuration, a new version is not created. The API reference describes the agent associated with a session as a snapshot of the agent's version at the time the session was created.

When creating a session, the agent parameter can take three forms:

A string representing the agent's ID: This uses the latest version at the time of creation.
An object specifying the version (e.g., {"type": "agent", "id": ..., "version": ...}): This uses the specified version. This is useful for staged rollouts of new versions.
agent_with_overrides: This specifies the agent's ID and an optional version, and then allows you to override specific fields (model, system, tools, mcp_servers, or skills) solely for that session. The agent's underlying resources remain unchanged, and no new version is created.

The impact of updating an agent on existing, running sessions is described on the Permission policies page.

Running sessions keep the toolset configuration they were created with. Updates apply to sessions created afterward.

When an agent is archived, it becomes read-only and cannot be reverted. Existing sessions will continue to function, but new sessions will not be able to reference that agent.

Environments do not have versions. The Cloud environment setup page recommends that if you frequently update your environment, you should manually keep a record of changes to track which configuration each session is using. As Section 3.2 shows, the impact of updating an environment on running sessions is not found in the documentation.

4.3 What Can and Cannot Change During a Session

The Session operations page limits the agent settings that can be modified after a session is created, as follows:

Only the agent's `tools` and `mcp_servers` can change after a session is created.

Updates are performed by sending a request to POST /v1/sessions/{session_id}, including tools and mcp_servers in the agent field. The entire array is replaced. Even when adding a single tool, you must provide a complete list of all tools the session should have. The update applies only to that specific session and is not propagated back to the agent, and no new version of the agent is created. The session must be in the idle state. If the session is running, send a user.interrupt event by itself and wait for it to transition to the idle state. For the session.updated event, the Reference page states that updates apply on the next turn.

The same page also lists what cannot be changed. The model (including the fixed inference_geo setting), system, and skills cannot be modified during a session. To run these with different values, use agent_with_overrides when creating the session. According to the Using agent memory page, memory stores can also be attached only when the session is created. The API reference indicates that updating vault_ids is not currently supported, and any requests to do so will be rejected.

However, there is a way to add system instructions. According to the Session event stream page, the content of a system.message event is appended to the session's system context as a turn with the role: "system", without replacing the existing system prompt.

applies to the accompanying turn and all subsequent turns

The models that support system.message are: Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, and Claude Sonnet 5.5. In the Claude API's Messages API, system messages sent mid-conversation also follow the same format, using a message with role: "system". The mechanics and impact on caching are discussed in Mid-Conversation Changes in the Claude API.

The budget can also be changed during a session. This is described in Section 4.5.

4.4 Tool Permissions — `always_allow`, `always_ask`, and `auto`

The Permission policies page allows you to define what happens before a tool is called, using three different policies.

Policy	Description
`always_allow`	The tool is automatically executed without any confirmation.
`always_ask`	The session pauses and waits for user approval before execution.
`auto`	The server evaluates each call and either executes the tool, denies the call, or waits for user approval.

The default setting for the agent toolset is always_allow, while the default setting for the MCP toolset is always_ask. The auto policy was added in the release notes dated September 10, 2026. No toolset currently uses auto as its default setting. Policies can be configured for the entire toolset (default_config) or for individual tools (configs entries).

The auto policy evaluates the tool, the input for the call, and the session's content up to that point. Therefore, two calls to the same tool may be treated differently. Calls deemed safe by the server are executed in the same way as with always_allow. Calls deemed high-risk by the server will not be executed; the agent will receive an error result from the tool, and the session will continue. The user's client cannot override this denial. Calls on which the server reaches no determination will wait for approval, similar to always_ask.

The Permission policies page includes a warning that auto is not a human checkpoint. Calls deemed safe by the server may be executed before anyone can review them, and their effects may be irreversible. The same page recommends setting the always_ask policy for tools that require human review. Regardless of the policy selected, the agent.tool_use and agent.mcp_tool_use events will include the result of the permission evaluation as evaluated_permission (either "allow", "ask", or "deny"). The implications of maintaining an approval-pending state across process restarts are discussed in Section 6.5 of Agent Reliability Engineering Design Guide - Retries, Loop Detection, Timeout Budgets, and Human Escalation for AI Agents.

4.5 Budgets, Vaults, and Memory Stores

Budget: According to the Session budgets page, a session budget is an optional limit set when a session is created. The platform continuously calculates the cost of the session's usage based on the public list rate, and when that cost reaches the budget, it stops issuing new model requests. A session that reaches its budget will transition to an idle state with a budget_reached stop_reason. The session does not end, and its history and sandbox are preserved, just like other idle sessions. While a budget can only be set during session creation, it can be modified or removed at any time. Accepted updates will automatically resume any paused operations. Removal is a one-way action; once a budget is removed, it cannot be re-applied. This article does not discuss specific monetary values.

Vault: According to the Authenticate with vaults page, a vault can hold two types of credentials. environment_variable credentials are placed in the sandbox as placeholders. When the agent makes external requests, these placeholders are replaced with the actual values via egress. The agent does not see the original values. MCP credentials (mcp_oauth and static_bearer) are injected when the session connects to the MCP server for a specific URL. Vaults are passed during session creation using vault_ids. The same page states the following regarding credential refreshing:

Credentials are re-resolved periodically, both during a session and during the vault lifecycle.

The page continues, stating that this process allows for credential rotation, archiving, and deletion to be applied to running sessions without requiring a restart. Archiving a vault will cause future sessions that reference it to fail, but running sessions will continue to operate. environment_variable credentials are not yet supported in self-hosted sandboxes.

Memory stores: According to the Using agent memory page, a memory store is a workspace-scoped collection of documents. When attached to a session, it is mounted as a directory in the sandbox. The documentation also states that when calling a memory store, you should replace managed-agents-2026-04-01 with agent-memory-2026-07-22; sending both will result in a 400 error. The operation of attaching a memory store to a session occurs at the session's endpoint and therefore remains managed-agents-2026-04-01. A session can have up to eight memory stores attached, and these can only be attached during session creation. Writing to the mounted path will update the store, and these changes will be synchronized between sessions that share the same store.

4.6 Session States and How Long They Last

The Session operations page categorizes session status into four states: idle, running, rescheduling, and terminated. idle indicates that the agent is waiting for input, running signifies an active session, rescheduling means the system is automatically attempting recovery from a temporary error, and terminated means the session has ended.

A session that finishes its work goes `idle`, not `terminated`.

A session becomes terminated due to an unrecoverable error or during archiving. This definition differs from the API reference (Section 9).

According to the Session event stream page, conversation history remains until explicitly deleted. When a session enters the idle state, the sandbox is checkpointed, preserving the file system, installed packages, and files created by the agent. However, the sandbox state is only maintained for 30 days from its creation. This period does not extend with activity, and sessions resumed after 30 days will begin with a new sandbox. This page does not specifically mention self-hosted sandboxes.

4.7 Managing Resources as Files — `ant apply` and `claude-lock.json`

In the release notes dated September 3, 2026, ant apply was added to the ant CLI version 1.30.0. ant apply creates and updates agents, environments, skills, memory stores, and deployments based on files within a repository. The current ant apply documentation also includes support for vaults (requiring CLI version 1.34.0 or later for vault files). ant apply writes to claude-lock.json, and users commit this change. Subsequent executions of ant apply will update existing resources rather than creating new ones.

According to the Define your agent page, to modify an agent using the CLI, you need to edit the agent's file and then re-run ant apply. Any changes to the configuration will result in a new version. Therefore, updates to the agent via ant apply will not affect currently running sessions, as described in Section 4.2. The ant apply documentation itself does not mention any impact on running sessions. If you modify resources outside of the files (for example, in the Claude Console), the next execution of ant apply will present a plan and then refuse to apply the changes. Using the --force flag will overwrite any external modifications.

5. OpenAI Agents API

This section describes what the OpenAI Agents API takes on, following OpenAI's documentation. The OpenAI Agents API entered public beta on September 10, 2026. Requests require the OpenAI-Beta: agents=v1 header (which is automatically included by OpenAI's SDK). The Configuring Agents page indicates that updates to session settings are available in both the beta and GA API contracts.

5.1 The Codex Harness and Three Environment Types

The Architecture page describes the components of the OpenAI Agents API as follows:

Harness: The OpenAI-hosted Codex instance that runs the model and tool loop and maintains the agent’s session.

The Codex instance hosted by OpenAI handles loop and session management. User applications submit tasks, receive events, and interact with function tools.

The environment.type determines where tools are executed.

none: Used for agents that do not require their own compute or files. In this case, the built-in Bash and apply-patch tools, the workspace files, and the executor's MCP are not available.
openai_hosted: Used when script execution, file editing, or output generation is required. OpenAI creates and manages a sandbox for the session.
self_hosted: Used when access to the user's infrastructure, a private network, or custom software is necessary. The user's code initiates the environment and connects the executor to the session. The user is responsible for setup, reconnection, shutdown, and saving any desired files.

The Self-hosted sandboxes page lists ten providers as potential sandbox operators: Modal, Cloudflare, Vercel, Daytona, Blaxel, E2B, Runloop, DigitalOcean, AWS Lambda MicroVMs, and Oracle Cloud Infrastructure (OCI). Each provider's page assumes self-hosted sessions. According to the same page, OpenAI runs the harness, while users run their own executor (codex exec-server) within their chosen environment.

5.2 Copying at Creation, and Updating a Session

A versioning mechanism for the OpenAI Agents API's saved agents is not found in the documentation. The fields for the Agent object in the API reference (id, created_at, instructions, metadata, model, multi_agent, name, object, reasoning, service_tier, text, tools, and updated_at) do not include any fields that represent a version. The Configuring Agents page describes what happens when a saved agent is updated:

Saved-agent updates apply only to new sessions. Each session copies the saved configuration when you create it and keeps those settings for later turns.

During session creation, settings can be overridden specifically for that session. This override does not affect the saved agent, nor does it affect any other sessions.

Existing session settings can be updated using POST /v1/agents/sessions/{session_id}. The fields that can be modified are model, reasoning.effort, and service_tier. It is also possible to update metadata in the same request. The same page lists the fields that cannot be modified.

You cannot update `reasoning.summary`, `text`, `tools`, `instructions`, or `multi_agent` through this endpoint. Create a new session to change those settings.

The page also explains when these updates take effect. The new settings apply from the next turn, starting with the message sent after the update is complete. Messages sent before the update may still use the previous settings. Even if steering messages are sent during an ongoing turn, the settings will remain the previous ones. Sessions maintain the conversation history. If the selected model does not support the updated settings, the update will fail. Session updates do not affect the saved agent, nor do they affect any other sessions. Even if you update the saved agent later, that session will remain unchanged.

5.3 State, and the Lifetime of an OpenAI-Hosted Sandbox

The Agents API page describes sessions as durable instances of agents that undertake tasks and respond to input. According to the Run and continue sessions page, sessions maintain an agent's configuration, conversation history, and saved work. The Agents API page states that OpenAI manages sessions, orchestration, context compaction, and recovery.

OpenAI-hosted sandboxes may end before a session does. The OpenAI-hosted sandboxes page explains that connected sandboxes receive keep-alive signals, including between turns. If there is no activity and no keep-alive signal received for one hour, the sandbox may be deleted. This time period is not configurable. Files located under /workspace/outputs are published as immutable artifacts upon the completion of a turn and can be downloaded even after the sandbox expires. According to the Files and artifacts page, files in self-hosted environments, even if located under /workspace/outputs, are not published as artifacts.

5.4 Vaults — Substitution at a Proxy

According to the Vaults page, Vaults place credentials outside of agent instructions and configurations. For MCP connections that OpenAI makes, static_bearer or mcp_oauth are used, allowing OpenAI to authenticate with the MCP server. For API requests from the sandbox, environment_variable is used. The sandbox environment variables contain placeholders, which the network proxy replaces with actual values for requests to approved hosts. This method is limited to environments using openai_hosted.

This workflow requires an `openai_hosted` environment. It does not supply credentials to self-hosted environments or application-run function tools.

The same page describes what happens when the environment_variable credentials are substituted.

Create a new session to use the replacement. Updating the vault does not change the credential already configured in an existing sandbox.

This runs in the opposite direction from the vaults of Claude Managed Agents (see Section 3.5). The page does not specify what happens during a session when the MCP credentials (mcp_oauth, static_bearer) are updated. Even if stored credentials are deleted, the original token is not revoked with its provider, and running sessions do not stop. Regarding self-hosted environments, the Sandbox security page states that users should provide a trusted proxy or server to securely pass sensitive information from outside the sandbox.

5.5 Items Not Found in the Guide

On October 3, 2026, while reviewing the 24 pages of the Agents API guide and the API reference, the following four points were not found. This does not mean they are absent.

Tool-Specific Approval Settings: The term approv appeared 312 times in the guide, but 303 instances were on the Computer use page. The remaining 9 instances referred to approved hosts, the approval event for computer use, and descriptions of sample applications. The terms require_approval, requires_approval, and human-in-the-loop appeared zero times. The guide describes approval as a process where the browser requests user approval before navigating to a new origin (when using "computer use"). The values for required_action.type in webhooks are function_call, environment_connection, and computer_use_approval_request.
User-Defined Session Budgets: The term budget consistently referred to the error session_budget_exceeded. This error indicates that the session has reached its allocated budget, and suggests starting a new session to continue. No fields representing a budget were found in the session creation requests.
Memory: The term memor appeared only in reference to the container's CPU and memory capacity, and within code snippets. The terms remember and long-term appeared zero times.
Saved Agent Versions: The terms revision and rollback appeared zero times. The term version appeared 15 times, but it referred to versions of executors, packages, artifacts, plugins, and skills; it did not refer to versions of saved agents.

5.6 How It Differs from the Agents SDK and the Responses API

The OpenAI Agents page clarifies the differences between the Agents SDK and the Agents API, distinguishing them based on where the loops are executed. The Agents API runs a managed Codex harness, managing the underlying infrastructure for the agents. The Agents SDK, on the other hand, runs in the user's application, delegating deployment, storage, approval, and runtime integration to the user's application. The same page also states that Agents API sessions, Agents SDK sessions, Responses API conversations, and sandboxes are all distinct resources.

6. AWS — AgentCore Harness and Amazon Bedrock Managed Agents

This section discusses two AWS products: AgentCore Harness and Amazon Bedrock Managed Agents. Details regarding AgentCore Harness are covered in Amazon Bedrock AgentCore Harness. This article will only cover the key points relevant to its scope. A complete overview of AgentCore can be found at Amazon Bedrock AgentCore Master Index.

6.1 AgentCore Harness — Versions, Endpoints, and Per-Invocation Overrides

AWS provides the AgentCore Harness loop. The AgentCore harness vs. Runtime page states that, in the AgentCore Harness, the orchestration loop itself is provided by Strands Agents. Users declare models, system prompts, tools, memory, and limits as configurations. The harness operates in the AgentCore Runtime and utilizes a separate microVM for each session.

Configurations have versions. According to the AgentCore harness versioning and endpoints page, each time the harness is updated, a new version with a complete configuration is created, and that version does not change after creation. The DEFAULT endpoint automatically updates to point to the latest version with each update. Named endpoints are used to pin the harness to a specific version. According to the InvokeHarness API reference, calls are made specifying an endpoint name (a qualifier), and if no qualifier is provided, it defaults to DEFAULT. The harness versioning page states that the harness versioning mechanism is the same as that of the AgentCore Runtime. The AgentCore Runtime page states that requests to an endpoint are resolved to the version that endpoint points to.

Unlike Claude Managed Agents and the OpenAI Agents API, AgentCore Harness allows for per-invocation configuration overrides. According to the Models and instructions page, these overrides only apply to that specific invocation and do not affect the harness's underlying resources. The same page also states that even if the model provider is changed in the same session, the conversation will continue. Section 3.2 (Nine Fields Move Per Call, and Everything Else Makes a New Version) of Amazon Bedrock AgentCore Harness covers the nine items that can be overridden per invocation, as well as those that cannot. Section 6.5 (The Nine Items That Stay on Your Side) of the same article covers the nine responsibilities that stay on the user's side.

When the harness is updated, what happens to running sessions is not named on the harness pages, as described in Section 3.4. What they do name is skills: the Skills page states that a skill is retrieved once during the first call of a session, and that it is retrieved again whenever a new session begins.

6.2 Amazon Bedrock Managed Agents — The OpenAI Agents API Adapted for AWS

Bedrock Managed Agents were introduced in preview on September 29, 2026, as announced in What's New.

Developed jointly by AWS and OpenAI, Bedrock Managed Agents (BMA) is built on a customized version of OpenAI's Agents API engineered to be AWS-native and integrated with AWS resources.

The loop is run by OpenAI's Codex harness inside Amazon Bedrock. The Bedrock Managed Agents page in the AgentCore developer guide states that Bedrock Managed Agents runs OpenAI's Codex harness on AWS, and that this harness manages the loop between models and tools, maintains sessions, and compacts context as conversations lengthen. The OpenAI page dedicated to Bedrock Managed Agents also indicates that the harness and model inference run within Amazon Bedrock. The regions currently available in preview are US East (N. Virginia), US West (Oregon), and US East (Ohio).

You can choose from two environments to execute tools: self_hosted (utilizing the user's compute resources) and aws_bedrock_agentcore (the AgentCore Runtime). In both cases, the codex exec-server process connects the execution environment and the service. There is no equivalent option for an OpenAI-hosted sandbox.

The configuration process also differs from OpenAI's Agents API. The BMA preview REST API reference page limits its scope to operations related to the sessions, events, and items used in the preview examples. These operations consist of seven actions: creating, listing, retrieving, and deleting sessions; sending events; retrieving events; and listing items. Neither an operation to save agent configurations nor one to update session settings is in the list. However, the operation that lists sessions can be filtered by agent_id, and the response includes the agent field, which contains the agent's ID. The model, instructions, and tools are passed in the agent field of the session creation request. Regarding updates to the execution environment, the Troubleshooting page states that even if you update the Runtime definition, the existing session processes will not be replaced.

OpenAI's Bedrock Managed Agents page notes that while there may be common concepts, the API contracts and scope of functionality are not necessarily the same. The Bedrock user guide also states that the OpenAI-hosted Agents API and Bedrock Managed Agents do not necessarily expose the same features or change at the same time.

On April 28, 2026, the What's New announcement stated that OpenAI's models, Codex, and Managed Agents would be available on Amazon Bedrock as a limited preview. This information can be found in AWS History and Timeline regarding Amazon Bedrock.

6.3 The New AgentCore Runtime and Amazon Bedrock Agents Classic

As announced on September 18, 2026, the new AgentCore Runtime is now available. According to the AgentCore Runtime documentation, a platformVersion (either V1 or V2) is set for each agent runtime. If omitted when creating a runtime, it defaults to V1. V2 is currently available in five regions. The same documentation states that these V1 and V2 values are distinct from the runtime versions that record the configuration history. They are also distinct from the AgentCore Harness version numbers (V1, V2, V3, and so on). In the 14 harness pages this article read, it was unable to find information on which platformVersion an AgentCore Harness operates on (searches for platformVersion and platform version yielded no results).

Amazon Bedrock Agents have been renamed to Amazon Bedrock Agents Classic and have not been available to new customers since July 30, 2026. Existing customers can continue using them in maintenance mode, and there is no planned end-of-life date. The Bedrock user guide recommends AgentCore Harness as a migration option, unless there is a specific reason to own the loop yourself. Agents Classic will not be the subject of comparison in this article.

7. GKE Agent Substrate

This section outlines what the Agent Substrate is responsible for, and what it is not.

7.1 It Does Not Run a Loop

Agent Substrate's GitHub repository README describes Agent Substrate as follows:

It is not an SDK for building agents, but rather a system for running them at scale.

According to the README, Agent Substrate manages the lifecycle (creation and destruction, suspending and resuming) of actors (an agent's workload), assigns actors to workers, and routes incoming traffic to those actors. GKE documentation describes Agent Substrate as an open-source system that users can directly deploy to their GKE Standard clusters. Google provides deployment tools for GKE, specifically for Google Cloud customers who meet certain requirements, in the substrate-gke repository.

Therefore, the loop on Agent Substrate is run by the user's agent code. Model inference, tool permission checks, and budget management are not described as things Agent Substrate handles in any of the GKE documentation, the two blog posts, or the README. A Google Cloud blog post states that Agent Substrate works with any agent framework or harness, citing examples such as Claude Code, OpenClaw, and Hermes.

7.2 Suspend, Resume, and Snapshots

Agent Substrate takes on both the place where agents run and their state while they are suspended. According to GKE documentation, Agent Substrate suspends idle agents and takes snapshots of the agent's memory (RAM) and local files. When a suspended agent needs to act again, its state is restored to an available sandbox. Cloud Storage is required to store these snapshots.

However, not everything is preserved. The GKE documentation's limitations section notes that open network connections, such as database sessions or connections to MCP servers, are not maintained when an agent is suspended. It is the agent's code that is responsible for re-establishing connections to external services upon resume.

To isolate workloads, either gVisor or Cloud Hypervisor can be used. The installation includes a gVisor runtime for the worker. The difference between gVisor and a virtual machine is discussed in Section 5.3 (Two Shapes - A User-Space Kernel and a Virtual Machine per Pod) of Workload Isolation Levels on Amazon EKS.

7.3 Three Ways the Status Is Written, and the CNCF

Agent Substrate's availability status is described in three different ways across various documentation sources. The GKE documentation (Last updated 2026-10-02 UTC) states that evaluation and non-production use are available to all Google Cloud customers, while production support is offered through a private GA program with an allowlist. The GKE release notes from September 11, 2026, describe the same production support as a limited GA program. The Google Cloud blog post Agent Substrate available on GKE indicates that production GA support is available through an allowlist. This article will follow the description found in the GKE documentation. The GitHub README notes that Agent Substrate is prior to version 1.0, and that its API and behavior may still undergo significant changes. The blog post's page displays September 16, 2026, and its structured data gives a publication date of September 15, 2026.

Agent Substrate has been submitted to the CNCF sandbox. In the GitHub repository cncf/sandbox, issue #523 shows that the TOC vote passed on September 28, 2026. A comment from September 29, 2026, requests finalizing the Contribution Agreement, noting that this is required before formally onboarding Agent Substrate as a CNCF project. As of October 3, 2026, this issue carries the label contribution-agreement/unsigned. Meanwhile, the Agent Substrate page on the CNCF website (published October 2, 2026) states, Agent Substrate is at the Sandbox maturity level.

7.4 How It Differs from Agent Sandbox

GKE documentation states that Agent Substrate is built upon the functionality of Agent Sandbox and improves upon it by circumventing standard Kubernetes control plane bottlenecks. Standard Kubernetes deployments, including Agent Sandbox, allocate dedicated Pods for each agent's workload. Agent Substrate, however, decouples the agent's state from the Pod, storing snapshots of suspended agents in storage and restoring them to a shared worker when needed.

A Google Cloud blog post (May 2026) announced the general availability of GKE Agent Sandbox. The README file for the Agent Sandbox GitHub repository (kubernetes-sigs/agent-sandbox) describes Agent Sandbox as a sandbox orchestrator. Anthropic's Self-hosted sandboxes page lists GKE Agent Sandbox as one of the platform-specific guides. In other words, Google's Agent Sandbox can be used as a self-hosted sandbox for Claude Managed Agents, operating within Anthropic's loop.

8. What Stays on the Provider's Side Even with a Self-Hosted Sandbox

When you choose a self-hosted sandbox, the environment where the tools run shifts to the user's infrastructure. However, the loops and model inference remain on the provider's side. This section shows this with verbatim excerpts from the documentation.

8.1 Claude Managed Agents

The Self-hosted sandboxes page states in its first paragraph:

Self-hosted sandboxes keep the orchestration on Anthropic's side but move tool execution into infrastructure you control. The agent's files, processes, and network traffic stay in your environment.

The same page continues, noting that the input and output of the tools flow to Anthropic.

Tool inputs and outputs still flow to Anthropic's control plane, so the model can see results and determine what to do next.

What remains in the user's environment consists of the file system that the agents read and write to, the processes the agents launch, and the network the agents access. Conversely, the agents' skills and the contents of the memory store associated with each session are stored by Anthropic and copied to the sandbox for that session. Changes to files in the memory store are reflected back into the store. The web_search and web_fetch functions run on Anthropic's servers, whether using a cloud-based sandbox or a self-hosted one. The MCP connector connects to the MCP server from Anthropic's side. Files and GitHub repositories are not mounted within a self-hosted sandbox.

The Security model page states that the content of conversations and the output of tools pass through the user's worker and remain in the user's environment. This refers to a section listing the user's responsibilities, specifically regarding log retention. It means that the user is responsible for retaining, editing, and deleting any content that passes through their worker. As stated on the Self-hosted sandboxes page, the input and output of the tools flow to Anthropic's control plane.

8.2 OpenAI Agents API

The OpenAI Bedrock Managed Agents page states, immediately following a table comparing the OpenAI Agents API and Bedrock Managed Agents:

Choosing a self-hosted sandbox for the OpenAI Agents API changes where commands and tools run. Its managed harness and model inference still use the OpenAI service.

According to the Self-hosted sandboxes page, in a self-hosted environment, the codex exec-server handles shell commands, file reading and writing, and utilization of the local MCP server, as requested by the harness. The executor connects via WebSocket, receiving commands and returning results. The harness and model inference remain within OpenAI's services. The MCP connections page states that by default (connection_origin: "service"), OpenAI also makes the connection to a remote MCP server. The environment_variable in the vault is not provided to self-hosted environments (see Section 5.4).

8.3 Amazon Bedrock Managed Agents

With Bedrock Managed Agents, even if you choose the self_hosted option, the loop and model inference remain within Amazon Bedrock. The comparison table on the OpenAI Bedrock Managed Agents page lists the following for the "Agent loop," "Model inference," and "Execution environment" rows:

Area	OpenAI Agents API	Bedrock Managed Agents
Agent loop	Managed by OpenAI	Hosted in Amazon Bedrock
Model inference	OpenAI API	Amazon Bedrock
Execution environment	OpenAI-hosted sandbox, self-hosted sandbox, or no sandbox	AgentCore Runtime or self-hosted compute

This table represents three out of five rows in the overall comparison. The Bedrock FAQ, in its description of Bedrock Managed Agents, states that all model inference runs within Amazon Bedrock and that data does not leave AWS.

Within AgentCore Harness, the built-in shell and file operations run within a microVM for each session. Inline functions return calls to the user's code and are executed on the user's side. The option to configure an environment that executes tools on the user's infrastructure (equivalent to a self-hosted sandbox) was not found on the harness pages reviewed for this article. In Agent Substrate, the components and workers run in the user's GKE cluster, and snapshots are stored in Cloud Storage. The loop itself is the user's code.

8.4 Zero Data Retention

Neither Claude Managed Agents nor the OpenAI Agents API is currently eligible for Zero Data Retention (ZDR), and this remains true even when using a self-hosted sandbox. The overview page for Claude Managed Agents states that it is not currently eligible for ZDR or HIPAA Business Associate Agreement (BAA) coverage because it stores session state on the server. The table on the API and data retention page clarifies that this treatment applies to all features, including self-hosted sandboxes. The OpenAI Agents API page similarly states this.

Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible.

This article does not evaluate this fact. No description that names ZDR for Bedrock Managed Agents is found in the Bedrock user guide. The security section of the Bedrock FAQ states that, in general for Amazon Bedrock, user input and model output are not shared with the model provider. This does not specifically address Bedrock Managed Agents.

9. Where the Sources Disagree

This section lists eight instances where the documents presented in this article present conflicting information regarding the same product. This article presents both perspectives without deciding which is correct. The discrepancy in the definition of maxTokens for AgentCore Harness (Section 2.3) is covered in Section 3.4 of Amazon Bedrock AgentCore Harness and is not counted among these eight. The final item (number 9) does not represent a conflict but rather a note regarding how to interpret the information.

Agent Substrate Credential Injection: The Google Cloud blog post Agent Substrate available on GKE describes egress proxies that inject credentials in a location inaccessible to the agent. GKE documentation (last updated 2026-10-02 UTC) states that EgressPolicy rules are not supported, and lists Default deny rules, Hostname-based rules, and Credential injection among them. A document in the open-source repository's docs directory also explains credential injection via EgressPolicy.
Terminology for Production Support of Agent Substrate: There are three ways to refer to production support: a private GA program (as mentioned in GKE documentation), a limited GA program (in the September 11, 2026 release notes), and GA support available through an allowlist (as described in that blog post). (See Section 7.3).
Availability Status of AgentCore Harness: The What's New post from June 17, 2026, and the developer guide both state that it is generally available (GA). However, the AgentCore FAQ, as of October 3, 2026, describes it as The managed harness (preview). This discrepancy is also noted in Section 9 of Amazon Bedrock AgentCore Harness.
Memory for Bedrock Managed Agents: The user guide's Preview availability and limitations page states that there is no built-in, long-term memory integration. The Bedrock FAQ, however, states that memory persists across sessions, with each interaction building upon the previous ones.
Human Approval for Bedrock Managed Agents: The What's New post from September 29, 2026, mentions support for human approval before high-impact actions. No description of an approval feature is found in the user guide. The Security and IAM roles page calls for the application or tool implementation to enforce authorization and any required human review for actions with external effects.
Default Memory Settings for AgentCore Harness: The harness Memory page states that when creating a harness through a service's API, omitting the memory setting will result in the service providing managed memory. However, when creating a harness using the AgentCore CLI, memory is disabled by default. The Amazon Bedrock Agents Classic maintenance mode page, in its steps for migrating manually with the AgentCore CLI, states that memory is enabled by default.
Per-Invocation Overrides and Memory for AgentCore Harness: The beginning of the Models and instructions page describes defining a harness once with defaults for the model, system prompt, tools, memory, and execution limits, and says that any of these can be overridden on a single invocation. The nine items that the same page lists as overridable on an invocation, and the request fields in the InvokeHarness API reference, do not include memory; they do include the actor ID for memory operations (--actor-id on the page, actorId in the API reference), which overrides the one configured on the harness. The table in Section 2.2 follows the latter two.
terminated Status for Claude Managed Agents: The Session operations page states that sessions that have completed their work transition to an idle state, rather than terminated. The terminated status indicates an unrecoverable error or an archival process. The API reference's description of the status field defines terminated as a session that ended due to an error or completion.
Reading Note on Data Flow with a Self-Hosted Sandbox in Claude Managed Agents: The Self-hosted sandboxes page states that the tool's input and output are sent to Anthropic's control plane. The Security model page, however, states that the conversation content and tool output remain in the user's environment. The latter statement is in a section regarding responsibility for log retention (Section 8.1). The former is used as the basis for the data flow.

10. Frequently Asked Questions about Managed Agent Runtimes

Q1. If you use a managed agent runtime, do you no longer need to write the loop code?

For four of the five products in this article, that is correct. Claude Managed Agents, the OpenAI Agents API, AgentCore Harness, and Bedrock Managed Agents all run the loop on the provider's side. Agent Substrate is different. It's not an SDK for creating agents; it's a system for running agents at scale, and the loop is run by the user's agent code.

Q2. If you update the agent configuration, does it take effect in running sessions?

For Claude Managed Agents and the OpenAI Agents API, it does not. In Claude Managed Agents, updates create a new version, and running sessions retain their original configuration. With the OpenAI Agents API, sessions copy the configuration at their creation time, so updates to the saved agent only apply to new sessions. In AgentCore Harness, updates change the DEFAULT endpoint to point to the new version. Under the general rule on the Runtime page, requests are resolved to the version the endpoint points to. However, the harness pages do not name what happens to running sessions.

Q3. Can you change the model in the middle of a session?

Yes, it is possible with both the OpenAI Agents API and the AgentCore Harness. With the OpenAI Agents API, you can change model, reasoning.effort, and service_tier through a session update. These changes take effect from the next turn after the update is complete. With the AgentCore Harness, you can change the model on a per-call basis, and the conversation will continue. With Claude Managed Agents, the model cannot be changed during a session. To run a session with a model different from the agent's, use agent_with_overrides when creating the session.

Q4. With a self-hosted sandbox, do tool inputs and outputs stay away from the provider?

If you use a self-hosted sandbox, the input and output of tools will be passed to the provider.

In Claude Managed Agents, the input and output of tools are sent to Anthropic's control plane. With the OpenAI Agents API, the user's environment's executor receives commands via WebSocket and returns results, while the managed harness and model inference utilize OpenAI's services. A self-hosted sandbox only changes the location where the commands and tools are executed. In either product, choosing a self-hosted sandbox does not make it eligible for ZDR.

Q5. Can you use Claude Managed Agents on Amazon Bedrock?

No, you cannot. The Amazon Bedrock, Google Cloud, and Microsoft Foundry pages all list Claude Managed Agents as an unsupported feature. Claude Managed Agents is only available through the Claude API and the Claude Platform on AWS. On Claude Platform on AWS, a session can run autonomously, without user events, for a maximum of 6 hours before requiring re-authentication (sending a user role event), and a session on a self-hosted environment cannot attach memory stores, which differs from first-party Claude Managed Agents. All of this information is current as of October 3, 2026. The differences in functionality across platforms are also discussed in Section 7.3 of Anthropic Claude Model Migration Guide - Upgrading Prompts and Workloads Across Model Generations.

Q6. Does the OpenAI Agents API have a tool approval policy?

A setting for tool-level approval is not found in the Agents API guide and API reference read on October 3, 2026. This does not mean it is absent. The documentation mentions approval processes related to computer use, where users are prompted to approve before a browser navigates to a new origin. The OpenAI Agents page states that the Agents SDK allows user applications to control deployment, storage, approval, and runtime integration.

Q7. Are Amazon Bedrock Managed Agents and the OpenAI Agents API the same thing?

They are not the same. Bedrock Managed Agents are a customized version of OpenAI's Agents API, designed for AWS. The loop and model inference run within Amazon Bedrock, and the execution environment can be either AgentCore Runtime or the user's own compute resources. OpenAI's documentation states that the API contracts and the scope of features offered may not be identical. The Bedrock user guide states that the two do not necessarily expose the same features or change at the same time. As of October 3, 2026, Bedrock Managed Agents are in preview.

Q8. How do Agent Substrate and Agent Sandbox differ?

According to the GKE documentation, standard Kubernetes deployments, including Agent Sandbox, allocate a dedicated Pod for each agent's workload. Agent Substrate is built on top of Agent Sandbox's functionality, decoupling the agent's state from the Pod. It stores snapshots of suspended agents in storage and restores them to a shared worker when needed. The README for Agent Substrate states that it is not an SDK for creating agents. The README for Agent Sandbox describes it as a sandbox orchestrator.

11. Summary

This article lines up, in the same rows, what five products from four companies take on. Claude Managed Agents, OpenAI Agents API, AgentCore Harness, and Bedrock Managed Agents all run the loop on the provider's side. Agent Substrate, on the other hand, does not have a loop; it serves as a foundation for running, suspending, and restoring agents from snapshots.

The way these products handle configurations can be categorized into four approaches. Claude Managed Agents assigns a version to each agent and pins each session to the version at creation. OpenAI Agents API copies the agent's configuration at the time of session creation. AgentCore Harness resolves the version through the endpoint each call names (DEFAULT if omitted) and allows overriding settings on a per-call basis. Version resolution is governed by the general principles outlined on the Runtime page. In the Bedrock Managed Agents preview, the configuration is passed at the time of session creation.

When comparing Claude Managed Agents and OpenAI Agents API, two rows run in opposite directions. During a session, Claude Managed Agents allows modifications to the tools (specifically, tools and mcp_servers), while OpenAI Agents API allows modifications to the model (specifically, model, reasoning.effort, and service_tier). Replacing credentials in the form of environment variables (environment_variable) reaches running sessions with Claude Managed Agents, but requires a new session with OpenAI Agents API. Updating saved configurations only affects new sessions for both providers.

Even when choosing a self-hosted sandbox, the loop and model inference remain on the provider's side. With Claude Managed Agents, the input and output of the tools flow to Anthropic's control plane. With OpenAI Agents API, the harness and model inference utilize OpenAI's services. For Bedrock Managed Agents, regardless of the execution environment, the loop and model inference are contained within Amazon Bedrock.

Items not found in the documentation were marked as "not found." For OpenAI Agents API, this includes tool-level approval settings, user-defined session budgets, memory, the version of a saved agent, and what happens to running sessions when MCP credentials are updated. For Claude Managed Agents, it is what happens to running sessions when the environment is updated. For Bedrock Managed Agents, it includes saved agent configurations, versions, mid-session changes, and user-defined budgets. For AgentCore Harness, it includes which platformVersion the harness runs on. For Agent Substrate, it is a long-term memory store. Separately, there is an item for which the harness pages state only a general rule and do not name the subject of the row: what happens to running sessions when AgentCore Harness is updated. Many of these products are currently in beta or preview, and the availability statuses in this article reflect each company's documentation as of October 3, 2026.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi