Home› Blog› AWS Daily Intelligence #43 - The third agent runti…
AWS Daily Intelligence AWS

AWS Daily Intelligence #43 - The third agent runtime, and the first one is closed

Verified against current vendor documentation on 30 September 2026. Pricing, limits and API behaviour were checked against the official docs on that date. Cloud services change fast — if you are reading this much later, treat the specifics as a starting point and re-check the linked sources.

Executive summary

AWS has put Amazon Bedrock Managed Agents into preview: “built on a customized version of OpenAI's Agents API engineered to be AWS-native and integrated with AWS resources.” It “manages how the model preserves state, selects and uses tools, executes code, and coordinates work across multiple steps and decisions.”

Preview in three Regions — “US East (N. Virginia), US West (Oregon), and US East (Ohio)” — and “no additional charge for BMA beyond the underlying AWS resources your agents consume” while it lasts.

The announcement is not the story. Going to look at where this sits alongside what already exists turns up a notice at the top of the Bedrock Agents documentation: “Amazon Bedrock Agents (now Amazon Bedrock Agents Classic) is no longer open to new customers.”

So there are three ways to run an agent in Bedrock, one of them is closed, and the newest overlaps a module of the one AWS recommends.

What changed

Bedrock Agents became Bedrock Agents Classic and stopped accepting new customers. The notice is unambiguous and it comes with an escape route: “For capabilities similar to Bedrock Agents Classic, explore Amazon Bedrock AgentCore. Existing customers can continue to use the service as normal.” There is a dedicated “Amazon Bedrock Agents Classic maintenance mode” page.

If you built on Bedrock Agents, nothing breaks. If you were about to, you cannot.

AgentCore is the recommended replacement, and it is much larger than what it replaces. It is “an agentic platform for building, deploying, and operating highly effective agents securely at scale using any framework and foundation model”, and it ships thirteen modular services: Harness, Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy and Registry.

And now BMA. A preview managed agent runtime built on OpenAI's Agents API.

Architecture

Diagram: the three ways to run an agent in Amazon Bedrock as of the Bedrock Managed Agents preview, and how they relate. On the left, Amazon Bedrock Agents, now renamed Amazon Bedrock Agents Classic, which is no longer open to new customers; existing customers can continue to use the service as normal, and AWS publishes a maintenance mode page for it. Its original proposition was that you do not have to provision capacity, manage infrastructure or write custom code, because Bedrock manages prompt engineering, memory, monitoring, encryption, user permissions and API invocation. In the centre, Amazon Bedrock AgentCore, which AWS recommends instead: an agentic platform for building, deploying and operating agents at scale using any framework and any foundation model, working with open-source frameworks including CrewAI, LangGraph, LlamaIndex and Strands Agents. It comprises thirteen modular services usable together or independently, namely Harness, Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy and Registry. Two of these matter for the comparison. AgentCore Harness is a managed agent loop invoked with a single API call where you specify a model, system prompt and tools inline, with Harness handling orchestration, tool execution, memory management and response generation, each session running in an isolated microVM with filesystem and shell access, and it works with Amazon Bedrock, OpenAI, Google Gemini and any OpenAI-compatible provider. AgentCore Runtime is a serverless runtime with true session isolation that already supports the OpenAI Agents SDK among other frameworks, plus protocols including MCP and A2A. On the right, the new Bedrock Managed Agents preview, built on a customized version of OpenAI's Agents API engineered to be AWS-native, which manages state, tool selection and use, code execution and multi-step coordination, available in preview in only three Regions being North Virginia, Oregon and Ohio, at no additional charge beyond underlying resources during preview with pricing subject to change at general availability. A closing panel records the overlap question: AgentCore Harness is already a managed agent loop that already works with OpenAI, and AgentCore Runtime already supports the OpenAI Agents SDK, so the new preview duplicates capability that is already generally available, and the documentation does not say when to choose which.
Three runtimes. The oldest is closed, the middle one is recommended, and the newest overlaps a module of the middle one.

The overlap is the part worth sitting with, and it is visible in the AgentCore service table rather than in any announcement.

AgentCore Harness is described as “a managed agent loop that lets you define and invoke AI agents with a single API call. Specify a model, system prompt, and tools inline. Harness handles orchestration, tool execution, memory management, and response generation.”

That is the same job description BMA was announced with. And Harness is not Bedrock-only: “AgentCore Harness works with Amazon Bedrock, OpenAI, Google Gemini, and any OpenAI-compatible model provider.”

AgentCore Runtime closes the gap further. It “works with custom frameworks and any open-source framework, including CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, and Strands Agents” — so running OpenAI's agent framework on AWS was already possible before this preview.

So what is BMA actually adding?

On the published evidence: a managed version of OpenAI's Agents API rather than a runtime you deploy it onto. Harness is AWS's own loop that can call OpenAI models; Runtime hosts OpenAI's SDK as your code. BMA is “a customized version of OpenAI's Agents API” operated by AWS. That is a real distinction — the agent loop's semantics come from OpenAI rather than from AWS — and it is the sort of distinction that matters a great deal if you are porting an existing OpenAI Agents application, and not at all if you are starting fresh. What the documentation does not do is tell you when to pick which, and with BMA's own documentation page not yet published, that guidance does not exist anywhere I can cite.

What Harness gives sessions is unusual and worth noting

“Each session runs in an isolated microVM with filesystem and shell access, supporting use cases like code generation, data analysis, and deep research.”

Filesystem and shell access inside an isolated microVM is a meaningful capability and a meaningful security boundary. It is also the boundary that yesterday's Firecracker out-of-bounds write (CVE-2026-5747) was about, which is a useful reminder that microVM isolation is a real control with a real patch cadence rather than an abstraction.

Business value

For anyone with an existing OpenAI Agents application, BMA is the shortest path onto AWS: the agent semantics are the ones your code already assumes, and state, tools and multi-step coordination are managed.

For everyone else, the value announced today is smaller than the value already sitting in AgentCore. The thirteen modules cover things BMA's announcement does not mention at all — Policy, which provides “deterministic control” using “Dogwood, which is compatible with Cedar” and “intercept[s] every tool call before execution”; Evaluations; Registry; Payments.

That Policy module is the one I would look at first regardless of which runtime wins. Intercepting every tool call before execution is the control that #64 found missing from Guardrails, which evaluates prompts and responses rather than actions.

Security considerations

Read the AgentCore data statement before either. “AgentCore may use and store your content to improve your service experience or performance. Such improvements would be for your use of AgentCore and not for other customers.” That is a narrower statement than it first reads — improvements accrue to you, not to a shared model — but it is still content retention, and it belongs in a review rather than in a footnote.

A preview is not a place for regulated data. Three Regions, pricing “subject to change at general availability”, and no published documentation page yet. Preview terms generally differ from GA terms on exactly the points a compliance team cares about.

An agent built on a third-party Agents API is a dependency on that API's semantics. BMA is “a customized version” of OpenAI's, which means its behaviour tracks decisions made outside AWS. For an agent that takes actions, behavioural changes are not cosmetic.

Cost considerations

“During preview, there is no additional charge for BMA beyond the underlying AWS resources your agents consume.” You still pay for the model invocations, the tools, the storage — and those are the costs that #62 showed are easy to underestimate, because quota and spend are different currencies.

“Pricing is subject to change at general availability” is the sentence to plan around. Anything piloted free in preview needs a cost model built before GA, not after.

AgentCore, by contrast, has published terms: “flexible, consumption-based pricing with no upfront commitments or minimum fees.”

Operational considerations

Check which runtime you are already on. If it is Bedrock Agents, you are on Classic and in maintenance mode. Nothing breaks, but no new capability is coming, and the migration target is AgentCore rather than BMA.

Three Regions is the practical constraint on BMA. N. Virginia, Oregon, Ohio — all US. Anyone with data residency requirements outside the US cannot evaluate this yet.

AgentCore's modularity cuts both ways. Thirteen services “that you can use together or independently” is genuine flexibility and thirteen things to understand, price and secure. Starting with Runtime plus Gateway plus Observability is a reasonable subset; adopting all thirteen because they exist is not.

Both paths lean on MCP. Gateway converts “APIs, Lambda functions, and existing services into Model Context Protocol (MCP)-compatible tools”, Runtime supports “MCP and A2A”, and BMA connects tools “via Model Context Protocol servers”. Tool definitions written for MCP are the portable asset here, whichever runtime you end up on.

Tradeoffs

Familiar semantics against AWS-native design. BMA gives you OpenAI's agent model on AWS infrastructure. AgentCore gives you AWS's own, which is model-agnostic by design.

Managed loop against composable modules. Harness and BMA both hide the loop; Runtime exposes it so you bring your own framework. The hidden loop is faster to start and harder to reason about when it misbehaves.

Preview against documented. BMA is free right now and has no documentation page. AgentCore has published pricing, thirteen documented modules, and no pricing cliff ahead of it.

Implementation guidance

If you are starting today, start on AgentCore. It is the documented, GA, recommended path, and it already supports OpenAI models and the OpenAI Agents SDK if that is what you want.

Evaluate BMA only if you are porting an existing OpenAI Agents application, in a US Region, with non-sensitive data. That is the case it is plausibly best at.

Write tools as MCP servers. It is the one asset that survives a change of runtime, and all three paths consume it.

Look at AgentCore Policy early. Intercepting tool calls before execution is a control that is far harder to retrofit than to adopt.

If you are on Bedrock Agents Classic, read the maintenance mode page now. Not because anything breaks, but because the migration is on somebody's roadmap whether or not it is written down.

Best practices

Treat a preview's pricing as unknown, not as zero. The announcement says so explicitly.

Adopt AgentCore modules on demand, not on inventory. Thirteen services is a catalogue, not a checklist.

Keep the agent's action surface narrower than its knowledge surface. Reading widely is recoverable; acting wrongly often is not.

Who should act on this

Everyone building agents on AWS should at least register that Bedrock Agents is now Classic and closed to new customers — that is the actionable fact of the day, and it is not in any announcement.

Try BMA if you have an OpenAI Agents codebase, a US Region and a non-production use case. Otherwise AgentCore is the path, and the sequence worth starting with is Runtime, Gateway, Observability, then Policy. Wait on BMA if you need published documentation, non-US Regions, or a price you can plan against.

Key takeaways

  • Bedrock Managed Agents is in preview, "built on a customized version of OpenAI's Agents API".
  • Preview in three Regions: N. Virginia, Oregon, Ohio. All US.
  • No extra charge during preview, and pricing is subject to change at GA.
  • Amazon Bedrock Agents is now Bedrock Agents Classic and is closed to new customers. Existing customers continue as normal.
  • AWS directs new work to AgentCore, which ships thirteen modular services.
  • AgentCore Harness is already a managed agent loop invoked with a single API call — and already works with OpenAI and any OpenAI-compatible provider.
  • AgentCore Runtime already supports the OpenAI Agents SDK, so running OpenAI agents on AWS predates this preview.
  • Harness sessions run in an isolated microVM with filesystem and shell access.
  • AgentCore Policy intercepts every tool call before execution, using Dogwood, compatible with Cedar.
  • AgentCore has published consumption-based pricing with no minimums; BMA does not yet.
  • AgentCore "may use and store your content to improve your service experience" — for your use, not other customers'.
  • All three paths consume MCP, which makes tool definitions the portable asset.

Comments

How was your experience?
Your feedback helps improve this site.
PoorExcellent