Amazon Bedrock Managed Agents: Pick the Compute Boundary First

AWS released Amazon Bedrock Managed Agents, powered by OpenAI in public preview on September 29, 2026. It is an AWS-native customization of OpenAI's Agents API. The launch is relevant to teams that want OpenAI models inside an AWS control plane, but it does not remove the operator's hardest choice: where commands and tools actually run.

The service manages the conversation and model interaction. Your compute runs the commands, local tools and MCP servers. That boundary determines which files, credentials, network destinations and operating-system permissions the agent can reach.

The verdict: choose the host you can actually govern

The BMA overview documents two execution environments:

Self-hosted is the smaller first experiment when you already own a safely isolated host. AgentCore Runtime is the more integrated AWS path, but it is not “serverless agent execution” in the sense of having nothing to operate. The documented example creates a Runtime, VPC with private subnets, NAT gateway, versioned S3 buckets, S3 Files mounts and session storage. Those resources can incur charges until removed.

Do not choose from the feature list. Choose from the failure you are prepared to own.

What BMA manages, and what it leaves with you

A BMA session binds a model, instructions, tools, IAM role and execution environment. Turns can contain reasoning, tool calls and generated output. Durable items preserve conversation output, while a streamed event feed reports progress.

That sounds like one managed unit. Operationally it is several:

1. The service-managed session retains conversation state.
2. The execution environment holds the workspace, processes and local tools.
3. Customer-owned stores hold files, skills and outputs.
4. External systems hold any effects produced by tools.

These lifecycles do not collapse into one. AWS explicitly notes that deleting a BMA session does not delete files on a self-hosted host or in your own S3 buckets. A cancel request does not undo a tool action that already completed. An idle session does not prove that every command succeeded.

The practical rule is to preserve three receipts for every consequential turn:

• a submission record with your own operation ID and the BMA session ID;
• durable BMA items and terminal events tied to the turn ID;
• an authoritative read from the system the tool changed.

The sessions and results documentation says a successful submission can return an empty body. That is acceptance, not completion. After an ambiguous network failure, inspect session activity before resubmitting. If the agent wrote to a CRM, repository or ticket system, reconcile that system separately before any retry.

Self-hosted compute: the leaner pilot, if the host is already a product

The self-hosted tutorial connects a local or remote host to a BMA session through codex exec-server. The host needs outbound HTTPS and WebSocket connectivity, and the exec-server process must remain running while the session uses it.

This is a good evaluation path when the team already has:

• an isolated, disposable workspace for each session or test run;
• a restricted OS identity with no deployment credentials;
• an outbound allowlist and inspected DNS/proxy path;
• pinned executables, skills, MCP servers and dependencies;
• process supervision, health checks and restart rules;
• a reset and deletion procedure for the workspace.

If those controls do not exist, “self-hosted” means the preview has inherited an informal workstation. That is not a smaller risk surface. It is merely an undocumented one.

AWS notes that a session ID alone does not grant environment access because registration and the WebSocket handshake use SigV4. Good. Still test the negative cases: wrong role, wrong Region, expired temporary credential, missing session token, denied model and a process that reconnects after a network break. Identity authentication is only one layer; commands still run with whatever the host can reach.

AgentCore Runtime: more managed activation, more infrastructure to reconcile

The AgentCore Runtime tutorial packages the exec server into an ARM64 Runtime. BMA activates it for work. The example uses AgentCore session storage at /mnt/workspace, mounts skills through S3 Files and synchronizes generated files from /mnt/output to an outputs bucket.

This path fits teams that want the runtime, storage and network boundary expressed as AWS resources. It also creates new acceptance cases:

• S3 Files synchronization is asynchronous, so a completed agent write can precede S3 API visibility.
• Maximum compute lifetime still applies while a turn is busy.
• Replacement compute does not preserve running processes or sockets.
• Session storage and S3-backed files have different lifecycles.
• The example's NAT gateway, storage and networking can cost money even when no turn is running.

Your test must therefore cross a compute replacement, not merely complete one happy-path turn. Write a file, read it back inside the workspace, wait for the customer-owned S3 copy, replace compute, recover the session and prove which state survived. If the result is business-critical, the S3 readback or another authoritative store should be the terminal evidence, not a “file written” message from the agent.

Separate the four identities

The security documentation describes distinct identities for deployment, API calls, the session and the execution environment. Keep them separate in the pilot:

The client needs iam:PassRole for the exact session role. The session role should restrict inference to the approved model and, for AgentCore, the approved Runtime and endpoint ARNs. The execution identity needs only the files, network destinations and tools required for this one workflow.

AWS's launch announcement says each agent uses its own IAM role, supports human approval before consequential actions and records supported API activity with CloudTrail. Those are useful primitives. They are not a complete authorization design. Put non-negotiable action policy in the application or tool implementation, bind an approval to the exact proposed action and read the resulting external state afterward.

A release gate for the preview pilot

The pilot should stop unless every row has retained evidence:

I encoded the plan shape in a dependency-free validator and exercised 15 synthetic cases. It accepts complete self-hosted and AgentCore pilot plans, and rejects missing identity, egress, result, reconciliation, cost, cleanup, supervision or storage-sync evidence. That proves the validator's branches, not BMA's security or reliability.

const errors = validatePlan({
  compute_boundary: "agentcore_runtime",
  roles: {
    deployment: "deployment-role",
    client: "bma-client-role",
    session: "bma-session-role",
    execution: "agentcore-runtime-role"
  },
  evidence: {
    workspace_isolation: "workspace-test-v1",
    egress_policy: "allowlist-v1",
    durable_items_readback: "items-fixture.json",
    side_effect_reconciliation: "external-readback.json",
    storage_sync_probe: "s3-readback-v1",
    idle_resource_cost: "cost-sheet-v1",
    cleanup_proof: "destroy-receipt-v1"
  },
  release_decision: "preview_pilot_only"
});

The release decision stays preview_pilot_only until the service leaves preview and the team repeats compatibility, security, recovery and cost tests against the production surface.

The implementation decision

For most teams evaluating BMA this week, start with self-hosted compute only if an isolated host already has mature runtime controls. That is the shortest route to learning the session API without provisioning the whole AgentCore example.

Choose AgentCore Runtime when the question is specifically whether AWS-managed activation, session storage and customer-owned S3-backed artifacts fit your production architecture. Budget time for its VPC, NAT, roles, container, storage synchronization, compute replacement and teardown. Do not call it the “managed” choice and skip those tests.

Either way, keep the first workflow read-only or reversible. One representative job, one named owner, one restricted data set, one denied-action suite and one authoritative result readback will teach you more than a broad demo with no release contract.

If you need to decide whether this preview belongs in a production agent architecture, DVNC's Agentic Readiness Audit turns one workflow into an explicit compute, authority, evidence, cost and stop decision before a build begins.