Managed Agents Comparison: Bedrock, Claude, OpenAI. Pick Failover First.
A managed agents comparison of Bedrock AgentCore, Claude Managed Agents, and the OpenAI Agents API on state, tool schemas, evidence, kill switch, and residency.
Go deeper. Build your own.
Three vendors will now rent you the loop. The demos will show subagents, compaction, and a dashboard with a green dot, and all three demos will be good. None of them will show you minute 20 of a 40-minute job on the day the loop dies, the terms change, or your data-classification review moves a workload out of the region the vendor supports. That is the only managed agents comparison that matters, and it is the one you have to run yourself.
The move is a matrix with five rows: state portability, tool schemas, evidence export, kill switch, residency and retention. Fill it from what each vendor has put in writing, not from what the sales engineer says on the call. Score each cell 0 to 2, treat a zero in rows 1, 4, and 5 as disqualifying for the primary slot, then write the route table (primary, fallback, local) and run one trial cut before you sign anything.
What InfoWorld put in one paragraph on September 11: three vendors rent the loop
OpenAI’s Agents API entered public beta on September 10, 2026: “Build and run cloud agents with the Codex harness, fully managed by OpenAI,” with OpenAI managing “sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment” (OpenAI; Agents API docs). InfoWorld’s Anirban Ghoshal covered it on September 11 and did the category math in one paragraph: “This is a crowded category. Anthropic’s Claude Managed Agents has been in public beta since April. AWS also offers Amazon Bedrock AgentCore, whose managed harness became generally available in June and does the same category of work, meaning the loop, tool execution, context, state, and recovery, while letting you use any model and switch providers mid-session without losing context” (InfoWorld). He also names Microsoft’s Foundry Agent Service and LangGraph.
Screenshot: InfoWorld, “OpenAI launches managed Agents API to simplify enterprise AI agent development” (Sep 11, 2026), captured Sep 13, 2026.
Two more lines from the same piece belong on the first page of your evaluation. “Lock-in is the biggest concern. If OpenAI provides the model, context management, tools, orchestration, and execution environment, moving to another platform becomes harder.” And: “That dependency could also weaken an enterprise’s negotiating position on pricing and terms.” The AgentCore description, including “switch providers mid-session without losing context,” is InfoWorld’s characterization, not a claim this article verified in AWS documentation. Put it on the trial checklist rather than in the score.
Why feature bingo is the wrong managed agents comparison
When the product was a chat window, you compared answers. Agents act, and a managed agent may act in a vendor-hosted or customer-hosted environment under a loop the vendor operates. The comparison that matters is what happens at minute 20 of a job when the loop stops, when the bill changes shape, or when the work has to move. Every one of those is a failover question, and none of them appears on a feature grid.
The open-versus-suite argument for gateways is already written and applies here without changes: a suite is fine as long as the exit is priced before the entry. This piece is the pricing exercise.
The managed agents comparison matrix: five rows, filled from written docs
Two rules before the rows. First, a cell is filled only from something the vendor wrote down, or from a test you ran; a verbal assurance scores zero until it is in the contract. Second, a blank is your homework, not the vendor’s failure. As of September 13, the material verified for this article is OpenAI’s launch post and docs, AWS’s September 8 blog on AgentCore evaluation, and InfoWorld’s coverage; Anthropic’s Claude Managed Agents column is almost entirely homework, which says nothing about the product and everything about what a buyer has to go and read.
Row 1: state portability, or can a session leave mid-job
The test is blunt. Export a running session’s state (events, compaction summary, working files) and resume it on a harness the vendor does not own. Score 0 if nothing in writing describes export; 1 if events are readable through the API but resume-elsewhere is undocumented; 2 if export and resume-elsewhere are documented and you did it in the trial.
What is in writing today: OpenAI defines a Session as “a durable instance of an agent that works on tasks” and Events as “the inputs sent to an agent and output produced during a session,” and lists “resuming a session where it left off” among the things it manages. The overview documents resume inside the service but does not describe exporting a live session into another harness, so score the documented path as 1 until a trial proves a 2. AgentCore’s “switch providers mid-session without losing context” is about changing the model provider inside AgentCore, per InfoWorld, not about leaving AgentCore; keep the two ideas apart when you score. Leave Claude Managed Agents blank until its current documentation or your trial establishes an export and resume path.
Screenshot: OpenAI Developers, Agents API overview (primitives, pricing, sandbox lines), captured Sep 13, 2026.
Row 2: tool schemas, or do your tools travel
Tools are the easiest row to get right and the easiest to lose by accident. If a tool exists as an MCP server you host, any harness that speaks MCP can call it tomorrow; if it exists as a vendor-native tool definition inside the vendor’s console, it exists in one place (Model Context Protocol). OpenAI’s docs say agents “connect to MCP servers” and define the Agent as including “the MCP servers available to the agent,” so the portable path is documented there. Leave AgentCore and Claude Managed Agents blank until current vendor documentation or the trial establishes MCP support for the product you would buy.
Score 2 when every tool in the job is an MCP server under your control, 1 when a minority is vendor-native, 0 when the job depends on a vendor-native tool with no MCP equivalent. Keep the inventory as a file, because the drift happens one convenient console click at a time.
# tools.yaml (illustrative): the row-2 inventory, diffed in CI
job: payments-schema-refactor
tools:
- { name: git-ro, kind: mcp, host: ours, portable: true }
- { name: ci-status, kind: mcp, host: ours, portable: true }
- { name: web-fetch, kind: vendor-native, portable: false, equivalent: mcp://fetch-proxy }
score_row2: 1
Row 3: evidence export, or what you can take home and when
Evidence is the trace of tool calls, the approvals, the costs, and the eval results, in a format you can store and replay without the vendor’s console. AWS has the most in writing here: its September 8 pattern deploys an agent to AgentCore Runtime, waits for READY (invoking earlier returns a 424), runs a fixed prompt set, and reads traces that land through OTel with 30 to 90 seconds of latency, then scores them with the Evaluate API’s built-in evaluators such as GoalSuccessRate, ToolSelectionAccuracy, and Harmfulness (AWS). OTel traces are the portable shape; the blog’s own caveats (single-session sessionSpans, integer timestamps, judge variance) are the first entries in your export runbook. For OpenAI, leave export format and retention blank until the trial produces written answers.
| Evidence item | Must exist before you sign | Score 2 looks like |
|---|---|---|
| Tool-call trace | Per-call record with args hash, result status, timestamp | OTel or JSONL you can pull continuously, not a console view |
| Approvals | Who approved which action id, and when it expires | Written to your ledger at decision time |
| Cost | Tokens, tools, and container time per session | Per-session numbers, not a monthly invoice line |
| Eval results | Scores per prompt per run | An API you can call from CI, as in the AWS pattern |
The export ritual for a vendor-hosted harness is its own runbook, and the reason you want it is replay: an incident review with no trace is a meeting, not a review.
Row 4: kill switch, from your side, in one command
A kill switch is not a button in the vendor’s console. It is a command you can run from your side that stops the loop, revokes the credential, freezes the sandbox, and proves it stopped, when the console is the thing that is down. Score 2 only if you executed it in the trial and an in-flight tool call did not complete afterward.
None of the three vendors’ material verified for this article documents a session-level stop in those terms, so every column starts at homework. AWS’s blog tears the eval runtime down with cdk destroy --force, which removes the deployment rather than stopping a session; useful, and different. The discipline for the local half of the switch, the one that has to work when nothing else does, is restricted mode as fleet policy. I have yet to regret a kill switch, and I have regretted every one I assumed existed.
Row 5: residency and retention, the row that ends conversations
This row can zero a column in one sentence. OpenAI’s docs say the Agents API “currently supports data residency only in the United States” and “does not support Zero Data Retention (ZDR),” including when you use a self-hosted sandbox (Agents API docs). If a workload requires ZDR or non-US residency, that column scores 0 for that workload today, whatever the rest of the matrix says. For AgentCore and Claude Managed Agents, leave the cell blank until current vendor terms establish regions and retention for the workload.
Credit where it is due: a written “no” is worth more to a buyer than an unwritten “probably.” OpenAI put the limit in the docs, which is exactly the kind of cell this matrix rewards.
Illustrative. The cells rate what could be verified in writing on September 13, 2026, not product quality. A light cell is the buyer’s homework.
Scoring the matrix and writing the route table
Score each row 0 to 2 per vendor. A zero in row 1, 4, or 5 removes that vendor from the primary slot for that workload; a vendor that fails row 4 on paper can still be a fallback for work you can afford to abandon mid-flight. The fallback must not share a zero with the primary on the same row, or you have one failure mode with two invoices.
| Row | Weight | Disqualifying at 0 | Trial evidence that earns a 2 |
|---|---|---|---|
| 1. State portability | High | Yes | Session resumed on another harness from exported state |
| 2. Tool schemas | Medium | No | Every job tool is an MCP server you host |
| 3. Evidence export | Medium | No | Trace, approvals, cost pulled continuously to your store |
| 4. Kill switch | High | Yes | Stopped from your side; in-flight call did not complete |
| 5. Residency / retention | High | Yes | Written terms match the workload’s classification |
Then the route table. For each dependency the vendor supplies, write the primary, the fallback, and the local column, which is always yours and is the one you rehearse. The rehearsal itself, the minute-20 cut and the three resume routes, is written up for the OpenAI Agents API and works unchanged for the other two.
Primary, fallback, local, per dependency. The local column is the part of the system you own regardless of which vendor wins the matrix.
# routes.yaml (illustrative): the matrix result, one block per workload
workload: payments-schema-refactor
primary: { vendor: <winner>, rows: [2, 1, 2, 1, 2], disqualified: false }
fallback: { vendor: <runner-up>, rows: [1, 2, 1, 1, 2], shares_zero_with_primary: false }
local:
{
loop: codex-exec-or-claude-code-on-runner,
sandbox: docker-golden-image,
evidence: jsonl-on-disk,
}
triggers: { no_events_for: 10m, recoveries_in_a_row: 2, terms_or_residency_change: local-first }
The trial script, before the contract
Book the trial for a morning and run the same task on each vendor. The task is a 40-minute refactor with a test suite that goes green at the end; the script is the same every time.
- Start the job with the events mirror on and the tool inventory from row 2 checked in.
- At minute 20, export everything the vendor lets you export. Time it. Note what is missing against the row-3 table.
- Kill the session from your side: revoke the credential first, then stop the session, then drop the sandbox. Record whether the in-flight tool call completed.
- Resume from the export on a harness you own. Record minutes to the first useful tool call and what state was lost.
- Ask for the residency and retention terms in writing, for this workload’s classification, and file the reply next to the matrix.
Fill the matrix from the trial, not from the demo. If two vendors tie, the tiebreaker is the one whose written docs already answered the most rows before you asked, because that vendor will keep answering after you sign.
What breaks after you sign, and how you’ll know
The terms move. InfoWorld’s line about negotiating position describes a failure mode you meet at renewal: a new container rate, or a new retention clause, arrives with the invoice. Signal: the renewal email. Fix: the fallback lane was priced at signing, so the conversation starts from a number.
Vendor-native tools creep in. Someone adds a console tool because it was one click. Signal: tools.yaml diff in CI shows a vendor-native entry with no equivalent. Fix: the CI check fails the change until an MCP equivalent exists.
The export job rots. The continuous export fails silently and nobody notices until the incident. Signal: a daily count of exported sessions that no longer matches sessions started. Fix: alert on the difference, not on the export job’s exit code.
Residency drifts. A new workload class lands on the primary because the matrix was scored for the old one. Signal: the classification review, weeks later. Fix: the routes.yaml block is per workload; a new class gets a new block before it runs.
The mid-session switch changes the agent. A provider switch inside a managed harness, where offered, changes tool-call habits and prompt behavior even when context is preserved. Signal: golden-task pass rate drops after the switch while single-step tasks hold. Fix: the eval parity check from the provider-cutoff drill and a regression gate in CI that fails the build when the agent, not the code, regressed.
Buy the loop, own the exit: the operating layer under three vendors
A managed harness is a good buy when the exit is priced first. The matrix, the route table, and the trial cut are operating-layer infrastructure, not a smarter prompt: they sit beneath whichever vendor wins and stay when the vendor changes. That is the argument the command center makes for the fleet on your desk and agentic ops makes for the practice: the harness does the work, the operating layer keeps the evidence, the meter, and the kill switch, and the layer is yours in every column of the matrix.
Three vendors renting the loop is good news, on one condition. Pick the one whose written docs answer the most rows, keep the local column warm, and let the crowded category work for you at renewal.
FAQ: managed agents comparison
Which managed agent platform should an enterprise choose?
The one whose written docs fill the most rows of a failover matrix: state portability, tool schemas, evidence export, kill switch, and residency. Score each row 0 to 2 from documentation and a trial cut, disqualify any vendor with a zero on state, kill switch, or residency, and keep a fallback without those zeros.
Can Amazon Bedrock AgentCore switch model providers mid-session?
InfoWorld’s September 11 coverage characterizes AgentCore as letting you “use any model and switch providers mid-session without losing context.” That is InfoWorld’s description; confirm it in AWS’s own documentation, and note that switching providers inside AgentCore is a different question from moving a session out of AgentCore.
Does the OpenAI Agents API support Zero Data Retention?
No, at launch. OpenAI’s docs state that the Agents API “does not support Zero Data Retention (ZDR)” and “currently supports data residency only in the United States.” For workloads that require ZDR or non-US residency, the residency row of the matrix scores zero today, regardless of the other rows.
Sources
- InfoWorld, “OpenAI launches managed Agents API to simplify enterprise AI agent development” (Anirban Ghoshal, September 11, 2026)
- OpenAI, “Introducing the Agents API” (September 10, 2026)
- OpenAI Developers, Agents API overview (primitives, pricing, residency and ZDR limits)
- AWS Machine Learning Blog, “Automated agent evaluation with Amazon Bedrock AgentCore and GitHub Actions” (September 8, 2026)
- Model Context Protocol
