Which Agent Platform? Bedrock Managed Agents, AgentCore Harness, or Runtime

TL;DR: Amazon Bedrock Managed Agents, powered by OpenAI, went into preview on September 29, and it is easy to read the launch as a choice between two products: Managed Agents or AgentCore. Read together with the AgentCore docs, it is one of three options, separated by who runs the agent loop. Managed Agents runs OpenAI’s Codex harness with OpenAI models. The AgentCore harness runs a managed loop built on Strands Agents with any model provider. AgentCore Runtime hosts a loop you write yourself. Managed Agents can use AgentCore Runtime as its execution environment, and the harness runs inside Runtime. Managed Agents is still a preview with clear limits (OpenAI models only, text input, three US Regions, API only), so test those against your workload first. In a small test both ran the same shell task. They differed in where the command ran, what got created by default, and which OpenAI models the Region offered.

In June I wrote about OpenAI’s models arriving on Amazon Bedrock, and about the small surprise that a Claude agent and a GPT agent in the same account talked to Bedrock through two different APIs [18]. Since September 29 there’s a next step: Amazon Bedrock Managed Agents, powered by OpenAI, in preview [1]. AWS and OpenAI built it jointly on a customized version of OpenAI’s Agents API, and it runs agents for OpenAI models inside AWS, with the IAM roles and governance controls teams already use.

If you want to run an agent on AWS now, the obvious question is Managed Agents or AgentCore. Read together, the Managed Agents user guide and the AgentCore developer guide describe three options, and which one fits depends on how much of the agent you want to own.

This post is the comparison I wanted while reading: what each option is, the same small task run on Managed Agents and on the AgentCore harness, a side-by-side table where every row comes from the current docs, three example workloads, and what I would test before committing. All of it reflects the docs as of the publish date.

Who runs the agent loop

Every agent has an orchestration loop. It sends the conversation to a model, the model asks for a tool, something runs the tool, the result goes back to the model, and the loop repeats until the task is done. Around that loop sit the things that make it production-ready: somewhere tools can run safely, state between turns, identity for the agent and for the user it acts for, and traces of what happened. The AgentCore docs call the loop plus that infrastructure the agent harness [8].

On AWS that loop can now belong to OpenAI’s Codex harness, operated by AWS as Bedrock Managed Agents, to the AgentCore harness that AWS builds on the open-source Strands Agents framework, or to your own code, in any framework, hosted on AgentCore Runtime.

Bedrock Managed Agents: OpenAI’s Codex harness, operated by AWS

The AgentCore docs describe Bedrock Managed Agents as running “the OpenAI Codex harness on AWS” [7]. The harness runs the loop between model and tools, keeps the session, and compacts context as the conversation grows. Model calls stay in Managed Agents, which invokes the OpenAI model on Bedrock under the session role, so the execution environment only runs the commands the agent sends. When the agent needs to run a command or touch files, the service sends that work to an execution environment you provide [2] [7].

You can run that environment as the Codex exec server on your own host, which suits local development, or let Managed Agents invoke an AgentCore Runtime in your account, so each session gets its own microVM, an execution role you control and optional VPC access [2] [7]. The product page calls AgentCore the default compute environment for Managed Agents [17].

You work with it through sessions. A session names a model, instructions, tools, an IAM role and an execution environment. You submit messages as events, read durable items (messages, reasoning summaries, command executions, MCP tool calls), and stream progress as server-sent events [2]. Skills are directories with a SKILL.md file that the agent discovers in the execution environment, and tools come from STDIO MCP servers running there [5].

A session involves three identities: the caller, a session role that the service assumes for inference and for activating the Runtime, and the identity the execution environment runs as. The docs recommend a separate role for each [4]. The launch post adds that supported API activity is recorded in AWS CloudTrail [1].

The preview limits page [3] lists these:

Models are BMA-supported OpenAI models available in your Region and account [3].
The documented session input is text.
Subagents and programmatic tool calling (code mode) are not supported.
There is no built-in long-term memory. The conversation lives in the session and files live in the execution environment, with separate lifecycles.
Cross-Region inference profiles are not supported, and there is no customer-managed KMS key setting for service-managed session data.
You use it through APIs and the supplied examples. The procedures don’t use the console.
The endpoints are in US East (N. Virginia), US West (Oregon) and US East (Ohio).

During the preview there’s no extra charge beyond the AWS resources your agents consume, and pricing can change at general availability [1]. Model inference is charged separately [2]. The preview APIs can also change before general availability [2]. Before you deploy the example, note that the AgentCore Runtime variant creates a VPC with a NAT gateway, and a deployed stack keeps charging while no turn is running [2].

AgentCore harness: a managed loop for any model

The AgentCore harness is also a managed loop, and it’s easy to miss next to the Managed Agents launch. You declare the model, system prompt, tools, skills, memory and limits as configuration, and AgentCore runs the loop for you. The docs say it is powered by Strands Agents, and it is generally available [8].

The main difference from Managed Agents is model choice. Unlike Managed Agents, the harness works with models from Amazon Bedrock, OpenAI, Google Gemini and any LiteLLM-compatible provider, and it can switch providers between turns of the same session without losing context [8] [10]. OpenAI models can be called through Bedrock’s Mantle endpoint with the harness’s execution role, so no OpenAI API key is needed on that path [10]. If you specify nothing, you get Claude Sonnet 4.6 on Bedrock [10].

Each harness session is stateful and runs in its own microVM with a filesystem and shell, because the harness runs inside AgentCore Runtime. CloudTrail even records harness operations under the Runtime resource type [8] [9]. It connects to AgentCore Memory for short-term and long-term memory, to AgentCore Gateway and remote MCP servers for tools, and to the built-in browser and code interpreter. Traces flow into AgentCore Observability automatically [8] [9]. For human approval, the docs use inline functions, tools that execute in your code, so the harness pauses, hands the call back to you, and continues when you return a result [11].

There’s no separate charge for the harness. You pay for the AgentCore capabilities it uses [8].

The harness also has limits that come with a managed loop. According to the comparison grid, you can’t choose the agent framework, there’s no bidirectional streaming, and graph or workflow-style patterns are out [9]. When configuration stops being enough, you can export a harness to Strands code and run that on AgentCore Runtime [8].

AgentCore Runtime: you write the loop

AgentCore Runtime is a serverless host for agent code. You bring an agent written in any framework, or none, wrap it with the AgentCore SDK entry point, package it as an ARM64 container and deploy it [9]. The docs list CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK and Strands Agents as examples, and any foundation model in or outside Amazon Bedrock [12]. Runtime supports MCP, A2A and multi-agent workloads, and every session gets its own isolated microVM. Billing is per second for the CPU and memory a microVM session consumes [12] [15].

Runtime gives you the infrastructure (isolation, scaling, sessions, auth and observability plumbing), but the loop, and every call to Memory, Gateway, Identity or the built-in tools, is code you write and maintain [9]. That trade pays off when you already have agents in a framework, or when the work is a graph rather than a loop.

AgentCore Gateway is also where Policy in AgentCore applies. Policy intercepts tool calls going through a gateway and evaluates each one against Cedar policies before the tool runs [14]. If you need deterministic rules on tool calls, that tells you which path to take, since harness and Runtime agents can route tools through Gateway [9]. The Managed Agents preview documents STDIO MCP servers inside the execution environment and says to enforce authorization and any required human review in the application or tool implementation [4] [5].

The earlier Bedrock Agents service, now called Bedrock Agents Classic, is no longer open to new customers, and its documentation points to AgentCore [16].

How they stack

Managed Agents can run its tools on AgentCore Runtime, the harness runs inside Runtime, and your own code is deployed to Runtime. When Managed Agents uses the Runtime environment, the session microVM, the execution role and the optional VPC attachment are the same building block in all three cases. The self-hosted path has none of them.

Diagram: Bedrock Managed Agents runs its tools on AgentCore Runtime or on your own host; the AgentCore harness runs inside AgentCore Runtime; your own agent code is deployed to AgentCore Runtime. — Where each option’s loop and tools run

Picking Managed Agents doesn’t keep you away from AgentCore; its execution environment can be an AgentCore Runtime, which the product page calls the default [17]. And the harness can call OpenAI models through Mantle [10], so picking it doesn’t rule those out either. You’d then be running an OpenAI model inside a Strands-based loop. The Codex harness itself, with its exec server, its context compaction and its skills format, is what Managed Agents adds on top [7]. And you can change your mind later, from harness to Runtime, through the Strands export [8].

The same small task on both

I wanted to see the difference, so on October 13 I gave Managed Agents and the AgentCore harness the same small job: run uname -sm and nproc, write both results to report.txt, and say what was written. Then, in a second turn, recall the CPU count without running anything.

For Managed Agents I used the self-hosted path from the user guide in US East (N. Virginia): a session role whose only permission is bedrock-mantle:CreateInference, a session on openai.gpt-5.6-luna, and the Codex exec server (Codex CLI 0.154.0) attached from a Linux x86-64 machine [2] [21]. The agent ran one shell command on that machine, { uname -sm; nproc; } > report.txt && cat report.txt, and the file appeared in the workspace directory with Linux x86_64 and 8. The session items showed the command, its working directory, exit code and output next to the answer. The second turn answered 8 from the session history, with no command. Then I deleted the session. A GET on it returned 404, and report.txt was still on my machine, as the docs say it would be [6].

For the harness I used Frankfurt and created it with nothing but a name and an execution role. The response filled in the rest. The model was global.anthropic.claude-sonnet-4-6, with a sliding window of 150 messages. The response also set a 15-minute idle timeout and an eight-hour maximum session lifetime. It also created an AgentCore Runtime named after the harness. Because I hadn’t passed a memory configuration, the service also provisioned a managed AgentCore Memory resource, which is the documented API default [22]. The harness was ready about two minutes later. The same task took three tool calls (two shell calls and one file_operations create) and about seven seconds, and it came back with Linux aarch64 and 2. So the session microVM runs on ARM64. (That fits the ARM64 containers Runtime hosts [9].)

For the second turn I switched the same session to openai.gpt-oss-120b through the Mantle endpoint, and it answered 2 from the context the Claude turn had left behind [10]. The Mantle model list in Frankfurt showed only the open-weight gpt-oss models from OpenAI that day, while N. Virginia also listed GPT-5.5, so “OpenAI models through the harness” depends on the Region. I also hit a problem switching back. When I set the session back to the default Claude model, the call failed with a validation error about a missing thinking signature in an earlier message. A fresh session was fine. If your design depends on switching models mid-session, test the whole round trip, including the switch back.

The last test was human approval. I gave the harness an inline function called request_approval and asked it to delete report.txt, with approval first. The stream stopped with stopReason: tool_use and handed the call to my code [11]. I sent back “DENIED”. The agent said it would leave the file alone, and an ls in the next turn still showed report.txt.

Deleting the harness removed its Runtime and, by default, its managed memory [22]. The two IAM roles and the Runtime log group are yours to clean up.

Side by side

Every row below comes from the docs listed in the Sources, read on October 13, 2026. Managed Agents is a preview, and details can change before the publish date and after it.

	Bedrock Managed Agents (preview)	AgentCore harness	AgentCore Runtime
Who runs the loop	OpenAI Codex harness, operated by AWS [7]	AgentCore, built on Strands Agents [8]	Your code [9]
Status	Public preview [1]	Generally available [8]	No preview notice in the docs [12]
Models	BMA-supported OpenAI models [3]	Bedrock, OpenAI, Gemini, LiteLLM-compatible, switchable mid-session [10]	Any model, in or outside Bedrock [12]
Agent framework	Codex harness only [7]	None to choose [9]	Any framework [12]
Where tools run	Your host or AgentCore Runtime [2]	Session microVM with shell and filesystem [8]	Session microVM [12]
State and memory	Session conversation, no built-in long-term memory [3]	AgentCore Memory, short and long term [8]	AgentCore Memory, called from your code [9]
Tools	STDIO MCP servers in the environment, filesystem skills [5]	Gateway, remote MCP, browser, code interpreter, inline functions, skills [8] [9]	Anything your code calls, MCP and A2A [12]
Identity	Separate caller, session role and environment identity [4]	Execution role, inbound IAM or OAuth, outbound token vault [9]	Execution role, inbound IAM or OAuth, outbound via your code [9]
Human review	In your application or tool implementation [4]	Inline functions pause the loop [11]	Your code [9]
Policy on tool calls	Not documented for the preview	Via Gateway [9] [14]	Via Gateway [14]
Observability	CloudTrail for supported API activity [1]	Traces, logs and metrics in CloudWatch, automatic [8]	Observability plumbing, instrumentation is yours [9]
Input	Text [3]	Messages per invocation, no bidirectional streaming [9] [10]	Your protocol, including bidirectional streaming [9]
Regions	3 US Regions [3]	16 Regions including Frankfurt [13]	22 Regions listed for microVMs [13]
Pricing	No extra charge in preview, may change at GA [1]	No separate charge, pay for capabilities used [8]	Per-second CPU and memory for microVMs [15]

A note on the identity row: the three identities in Managed Agents look like extra setup, but they map well onto how delegated authority should work anyway, with the caller, the agent and the place commands run each holding only what they need. I wrote about that pattern in a post on agent authorization [19].

Example workloads

Decision path: if you need your own framework, a graph workflow or bidirectional streaming, use AgentCore Runtime. Otherwise, if OpenAI models, a US Region and preview APIs are acceptable and you want the Codex loop, use Bedrock Managed Agents; if not, use the AgentCore harness. — A first cut at the decision, before the details in the table

Take a team that wants an agent that investigates a codebase or works through a pile of documents and writes files as output. It has standardized on OpenAI models and builds in a US Region. The Managed Agents docs describe that kind of work as its target [2]. The Codex loop, context compaction and the skills format come ready-made, and the AgentCore Runtime environment gives each session an isolated workspace in the team’s own account [7]. They should plan for the preview limits and keep the example’s always-on networking costs in mind [2] [3].

A platform team in Europe wants a research assistant that remembers users across sessions, reaches internal systems through governed tools, and lets them compare models from more than one provider. The harness covers that in configuration, with AgentCore Memory scoped per user, Gateway with Policy in front of the tools, model overrides per invocation, and availability in Frankfurt [8] [9] [13] [14].

If you already run a LangGraph workflow with branches and a supervisor, plus a voice front end that needs bidirectional streaming, neither managed loop supports that shape [9]. Runtime keeps your framework and orchestration; you add the SDK entry point and the container packaging [9]. You add Memory, Gateway or Identity where you need them [12]. If you’re moving an MCP server along the same path, I walked through the hosting steps from local to AWS earlier this year [20].

What I would check before choosing

Which models your account can use with Managed Agents in your Region. The docs warn that a model listed in the endpoint’s catalog may still not work with Managed Agents [3] [21]. For the harness, check which OpenAI models the Mantle endpoint lists in your Region. In Frankfurt it was the gpt-oss family when I looked.
Try switching models inside one harness session in both directions, with the models you plan to mix.
Decide whether text-only input, no subagents and no built-in long-term memory are acceptable for the first release of your agent [3].
Where your data needs to live. Managed Agents is in three US Regions today, while the harness and Runtime are in most commercial Regions, including in Europe [3] [13].
Human approval and tool authorization need a home. With Managed Agents, plan it in your application or tool code [4]. With the harness or Runtime, you can use inline functions or Gateway with Policy [11] [14].
Commands and MCP tools run with whatever access the execution environment has, so the docs recommend a dedicated workspace and a restricted operating-system identity [4].
A session leaves things behind. Deleting a Managed Agents session doesn’t delete files in your buckets or on your host, and cancelling a turn doesn’t undo tool side effects that already happened [4] [6].
Some things keep running when nobody is using them, such as the NAT gateway in the Managed Agents AgentCore example [2], and some get created for you, such as the managed memory a harness gets when you create it through the API without a memory setting [22].
Check what the execution role needs. The harness docs include a sample policy with an AgentCore Memory statement. For the Mantle model call my execution role also needed bedrock-mantle:CallWithBearerToken, which the API error named.
Think about how you’d move later. Harness to Runtime has a documented export to Strands code [8]. Managed Agents uses its own session API on the bedrock-mantle endpoint [2] [3], so I’d expect a move between Managed Agents and the other two to mean rewriting the client side.

The launch invites a two-column table. The three-column version is more useful, because the deciding question is who should own the loop: OpenAI’s harness, an AWS-managed harness, or your own code. Harness to Runtime has a documented export path to Strands code [8]. Moving to or from Managed Agents still means rewriting the client.

If you’re evaluating Managed Agents in the preview, which of the limits above matters most for your workload?

Sources

[1] Amazon Bedrock Managed Agents, powered by OpenAI, is now available in preview — AWS What’s New, 2026-09-29
[2] Amazon Bedrock Managed Agents, powered by OpenAI (preview) — Amazon Bedrock User Guide
[3] Preview availability and limitations — Amazon Bedrock User Guide
[4] Security and IAM roles — Amazon Bedrock User Guide
[5] Add skills and tools — Amazon Bedrock User Guide
[6] Work with sessions, events, and results — Amazon Bedrock User Guide
[7] Get started with Amazon Bedrock Managed Agents (with OpenAI) on AgentCore Runtime — Amazon Bedrock AgentCore Developer Guide
[8] AgentCore harness — Amazon Bedrock AgentCore Developer Guide
[9] AgentCore harness vs. Runtime — Amazon Bedrock AgentCore Developer Guide
[10] Models and instructions — Amazon Bedrock AgentCore Developer Guide
[11] Tools — Amazon Bedrock AgentCore Developer Guide
[12] What is Amazon Bedrock AgentCore? — Amazon Bedrock AgentCore Developer Guide
[13] Supported AWS Regions — Amazon Bedrock AgentCore Developer Guide
[14] Policy in Amazon Bedrock AgentCore — Amazon Bedrock AgentCore Developer Guide
[15] Amazon Bedrock AgentCore pricing — AWS
[16] Supported Regions for Amazon Bedrock Agents — Amazon Bedrock User Guide (Bedrock Agents Classic note)
[17] Amazon Bedrock Managed Agents, powered by OpenAI — AWS product page
[18] Welcome to the Family: I Sat GPT-5.5 and Claude Opus Down on Bedrock — my post, June 2026
[19] Foundations of Agent Authorization — my post, September 2026
[20] MCP Strategies on AWS, Part 3: Hosting, from Local to AWS — my post, June 2026
[21] Set up permissions and prerequisites — Amazon Bedrock User Guide
[22] Memory — Amazon Bedrock AgentCore Developer Guide (harness managed memory)