On September 29, AWS put Amazon Bedrock Managed Agents (BMA, powered by OpenAI) into public preview. One sentence sums it up:

The OpenAI agent harness, delivered as an AWS-native runtime.

After the era of selling model APIs comes the era of bundling agent runtime + identity + execution environment + durable state + governance. BMA is AWS's entry in that bundle market — a joint AWS-OpenAI effort, highlighted again in the October 5 AWS weekly roundup.

Architecture: what runs where?

Six building blocks:

Session      Stateful conversation: model, instructions,
             tools, IAM role, execution environment
Turn         Work for one message (reasoning + tool calls + output)
Exec env     Customer-provided compute (self-hosted or AgentCore)
Exec server  codex exec-server process, outbound connection to BMA
Items        Durable conversation output (messages, commands, MCP calls)
Session role IAM role BMA assumes (inference + runtime activation)

Drawn as a flow:

My app
 │ create session (model, instructions, role, environment)
 ▼
BMA (bedrock-mantle endpoint)
 │ model inference + conversation state + context compaction
 │ ← the Codex harness runs the loop
 ▼
Execution environment (my host or AgentCore microVM)
   runs commands, file work, MCP tools
   → outputs persist durably as Items

Readers of our own-loop-vs-API comparison will recognize the shift: teams used to build that loop, state, and compaction themselves. BMA takes the harness managed and leaves execution on customer compute. Model calls stay inside Bedrock while the container runs only agent-sent commands, as the official AWS architecture diagram shows.

BMA architecture diagram. Signed API requests from my app reach BMA, which runs inference on the Bedrock-hosted OpenAI model while tool requests and results flow to and from my execution environment

Source: AWS official docs, "Amazon Bedrock Managed Agents, powered by OpenAI (preview)" architecture diagram.

Execution environments: self-hosted vs AgentCore

Option You provide Fits when
Self-hosted Host, workspace, network, exec server You want existing dev machines or containers
AgentCore Runtime Runtime containing the exec server You need per-session microVMs and managed storage

On AgentCore, each session gets its own microVM under an execution role you control, with VPC access to private resources. Skills are discovered from capability directories (up to 32 paths), and MCP connects via environment-based STDIO servers.

The permission model is the product's real face. Each agent gets its own IAM role, session roles pass through iam:PassRole, model calls narrow to bedrock-mantle:CreateInference, API activity lands in CloudTrail, and consequential actions can require human approval. Agent authority speaks the same language as AWS governance — IAM, CloudTrail, VPC.

Pricing: no extra BMA charge during preview beyond inference and resource consumption. Subject to change at GA.

Preview limits: what does not work yet

The docs' limits table is refreshingly honest — required reading before adopting:

Supported    session CRUD, text message submit + turn cancel,
             durable items reads, event streaming,
             command execution, file-based skills, STDIO MCP
Unsupported  Subagents: not supported
Input        documented surface is text-centric
             (no programmatic tool calling / code mode)
Memory       no long-term memory integration
             (session data and workspace files live separately)
Security     no customer-managed KMS key option
Console      API- and example-driven (no console flow)
Endpoint     bedrock-mantle only (not bedrock-runtime)
Regions      us-east-1, us-west-2, us-east-2

The two biggest lines: no subagents and text-centric input. Teams planning multi-agent division of labor should treat BMA as the place for one agent's long job, with the division of labor designed in a separate layer like our subagent orchestration guide.

CodeBridge mini lab: own loop vs BMA

Take the briefing's action literally. If your team is on AWS, run the same job both ways and compare:

Criterion              Own agent loop       BMA
------------------------------------------------
Loop ownership         my code              Codex harness (managed)
Conversation state     my storage (DB)      session + durable items
Context compaction     hand-built           built into harness
Execution              my servers           self-hosted or AgentCore
Permissions            app-managed          IAM roles, PassRole, CloudTrail
Skills/MCP             hand-wired           capability dirs, STDIO MCP
Subagents              buildable            unsupported (preview)
Long-term memory       design it            none (files kept separate)
Observability          instrument it        event stream + items
Cost                   all my infra         usage-based (preview)

The verdict criterion is single: which side costs less in total ownership once IAM, observability, and state are all counted. Framed as an operations-burden question rather than a model-quality question, the answer comes fast.

Conclusion: when the harness becomes infrastructure, governance is the differentiator

BMA's bet, in short:

Past:   teams that pick model APIs well win
Now:    teams that build agent loops well win
Next:   teams working on infrastructure that bundles
        loop, identity, execution, state, and audit win

What survives model swaps is permissions, records, and state. BMA bundles those leftovers in AWS's language. If you plan to take agents to production on AWS, run one small repo-investigation job as a BMA session during this preview and check whether items and events satisfy your audit needs. If they do, throw away loop code and focus on governance. That is exactly why clouds absorb harnesses.

Further reading

References

Go deeper with a course

To build harness, loop, and state persistence by hand first and then compare against managed options, practice assembling agent execution structures step by step — exactly like this article's comparison table.