On 29 September 2026, AWS opened the public preview of Amazon Bedrock Managed Agents, powered by OpenAI (BMA). It was developed jointly by AWS and OpenAI and is built on a customised version of OpenAI’s Agents API that has been engineered to be AWS-native. The promise is simple: build agents optimised for OpenAI models that run entirely inside AWS, with the IAM identities, permissions, and governance controls you already use (AWS What’s New, 29 Sep 2026). For teams that wanted OpenAI’s agent experience without sending workloads outside their AWS boundary, this is one of the most significant AI launches of the year. This guide covers what BMA is, how it works, what the preview can and cannot do, and how to pilot it safely.
What Are Amazon Bedrock Managed Agents?
BMA is a managed service for running stateful, multi-step agents with OpenAI models on Amazon Bedrock. You create a session, give it instructions and an execution environment, and submit messages. The service manages the conversation and model interactions, while tools execute on compute that you provide (Amazon Bedrock User Guide).
AWS says BMA handles how the model preserves state, selects and uses tools, executes code, and coordinates work across multiple steps and decisions. Durable sessions keep messages, tool calls, and intermediate results, so you can come back later, add new information, and continue from where the agent left off. AWS’s product page describes the combination as OpenAI models plus the Codex harness plus Amazon Bedrock AgentCore (Amazon Bedrock Managed Agents).
The launch caps a partnership that started with a limited preview on 28 April 2026, when AWS brought OpenAI models, Codex, and Managed Agents to Bedrock and confirmed that OpenAI model usage can count toward existing AWS cloud commitments (AWS What’s New, 28 Apr 2026).
How BMA Works: The Core Building Blocks
The documentation defines a small set of components you need to understand before writing any code:
- Session: a stateful conversation with an agent. It specifies a model, instructions, tools, an IAM role, and an execution environment.
- Turn: the work done in response to one submitted message, including reasoning, tool calls, and output.
- Execution environment: customer-provided compute where commands and local tools run, either your own host or Amazon Bedrock AgentCore Runtime.
- Exec server: the
codex exec-serverprocess that connects your environment to BMA through an outbound connection. - Items and events: items hold durable conversation output, and the event stream reports progress as work happens.
- Session role: the IAM role BMA assumes for model inference and, when configured, AgentCore Runtime activation.
One detail matters for data governance: the service-managed conversation and the files in your execution environment have separate lifecycles. Deleting a BMA session does not delete files stored in your own S3 buckets or on your own host (AWS docs).
Self-hosted compute vs. AgentCore Runtime
| Option | What you provide | Best for |
|---|---|---|
| Self-hosted compute | A host, workspace, network access, and a running exec server | Reusing an existing dev machine, container, or compute environment |
| AgentCore Runtime | An AgentCore Runtime containing the exec server and its adapter | Managed runtime sessions and configurable storage in your AWS account |
AWS supplies an example bundle for both. The self-hosted CDK app creates IAM roles but not a host, while the AgentCore CDK app creates a Runtime, storage, and networking, including a NAT gateway that keeps billing even when no turn is running. Clean up the example stacks when you finish testing.
Skills and MCP Tools
BMA separates instructions from actions. A skill is a directory containing a SKILL.md file, placed under a path listed in the session’s environment.capability_directories. Skills are plain filesystem content, so you can bake them into a container image, mount them from storage, or keep them on a host. Tools come from STDIO MCP servers running in the same environment, and you restrict which tools the agent may call with an allow-list (Add skills and tools).
In practice, this lets you encode a runbook such as “triage a failed deployment” as a skill, then give the agent a narrowly scoped MCP tool that reads CloudWatch logs, without handing it broad shell access.
What the Preview Does Not Do Yet
Before you plan a production rollout, read the preview boundaries carefully (Preview availability and limitations):
- Regions: only US East (N. Virginia), US West (Oregon), and US East (Ohio), through regional
bedrock-mantleendpoints. It does not use thebedrock-runtimeendpoint. - No subagents and no programmatic tool calling (code mode).
- No built-in long-term memory. Sessions keep context, but memory shared across sessions needs your own datastore.
- Text-only input on the documented session surface.
- No cross-Region inference profiles and no customer-managed KMS key setting for service-managed session data.
- No console workflow. Everything runs through APIs and the example deployments.
For teams in India or the UAE, the Region list is the big one. Workloads with strict data-residency requirements should wait or keep BMA limited to non-sensitive pilots until more Regions arrive.
Security: Design It In From Day One
Each agent runs with its own IAM role and records supported API activity in AWS CloudTrail. AWS’s launch note also says BMA supports human approval before consequential actions. The security guide is explicit about where that control lives, though: for actions with external effects, enforce authorisation and any required human review in your application or tool implementation. It also says to treat instructions from documents, websites, and tool responses as untrusted input (Security and IAM roles).
A practical baseline:
- Run the exec server in a dedicated workspace under a restricted operating-system user.
- Scope the session role to model inference only. Give each tool its own least-privilege credentials.
- Keep deployment credentials out of the runtime entirely.
- Put an approval gate in front of anything that writes, deletes, deploys, or sends.
- Stream CloudTrail events into your SIEM and alert on unexpected
bedrock-mantleactivity.
If your organisation doesn’t have this guardrail layer yet, our security, governance and compliance services can help you set it up before agents touch production systems.
A 30-Day Pilot Plan
- Week 1: Pick one bounded use case. Codebase investigation, document processing, or report generation all match the multi-step tasks AWS highlights.
- Week 2: Deploy the self-hosted example in a sandbox account in
us-east-1. Create a session withPOST /openai/v1/agents/sessions, signed with SigV4 for thebedrock-mantleservice, and confirm which OpenAI models your account can see through/v1/models. - Week 3: Add one skill and one MCP tool with an explicit tool allow-list. Measure task success, turn count, and token spend.
- Week 4: Decide. If results hold, move to AgentCore Runtime for managed sessions and plan for general-availability pricing, which AWS says may change from the preview.
Pricing
During the preview there is no additional charge for BMA itself. You pay for model inference and the AWS resources your agents use, and AWS notes that pricing is subject to change at general availability (AWS What’s New). Watch the hidden costs too: NAT gateways, storage, and idle compute from example stacks add up quickly.
Frequently Asked Questions
How is BMA different from Amazon Bedrock AgentCore?
AgentCore is the general-purpose agent infrastructure layer for any framework and model. BMA is an opinionated, managed agent experience optimised for OpenAI models and the Codex harness, and it can use AgentCore Runtime as its execution environment. For a deeper look at AgentCore, see our AgentCore guide.
Can I copy my existing OpenAI Agents API code?
Not directly. AWS warns that OpenAI-hosted Agents APIs and BMA don’t necessarily expose the same features or change at the same time, and unsupported fields can cause validation errors (BMA REST API reference).
Does my data leave AWS?
AWS states that the agent runtime and model inference stay inside AWS, and tools run on compute you control. You still need to decide what data the agent can reach.
Is BMA ready for production?
It’s a public preview, and APIs can change. Use it for pilots and internal tools now, and plan production rollouts around general availability.
Build Your First OpenAI Agent on AWS
Shanav is an AWS Advanced Tier Partner with offices in Jaipur and the UAE. We help teams pick the right agent platform, design least-privilege guardrails, and move pilots into production. Explore our AWS generative AI solutions, or talk to our AWS experts about piloting Bedrock Managed Agents in your environment.