Two Control Planes, Nine Axes, and the Third Column This Article Refuses to Print

Microsoft Foundry and Amazon Bedrock AgentCore converged on the same substrate shape from opposite directions. They diverge on identity and on how they authorize actions. Google's column is blank on purpose, and that blank is the most copyable thing here.

The relief of not being sold a scoreboard, followed by the sharper relief of watching a technical guide say 'I do not know this one' out loud. Microsoft Foundry and Amazon Bedrock AgentCore converged on the same substrate shape from opposite directions.

In this article: You will get a nine-axis comparison of Microsoft Foundry and Amazon Bedrock AgentCore where every row carries a provenance label and a vintage, an explanation of why two vendors independently landed on the same seven-part decomposition, the two places they genuinely diverge, one widely repeated asymmetry that is simply false, and the eight questions to ask about any third platform instead of trusting a column someone invented. By the end you will be able to run this evaluation yourself, including the part where you decline to answer.

A reader arriving from a Bedrock AgentCore series wants this comparison first, and usually wants it as a scoreboard. It is not one.

Two of these platforms are documented well enough here to compare honestly. The third is not, and printing a column for it anyway would be the single most damaging thing this article could do, because an unverified column sitting next to two sourced ones starts to look sourced.

The answer to "which one" was never going to come from a feature count anyway. It comes from where your identity already lives, where your data already sits, and what your compliance reviewer already signed. Everything below is in service of those three questions.

One extra label, and one abstention

Every Foundry claim in this series is checked against reference/foundry-hyperscaler/, a local mirror of Microsoft Learn pulled on September 19, 2026. A claim carries no label when that check passed cleanly. This comparison needs one label the rest of the series does not, because it draws on two sources of very different quality and one source that does not exist.

[AGENT-CORE-GUIDE: <file>, July 2026] is the new label, and it is weaker on purpose. It means the claim comes from a twelve-part Bedrock AgentCore guide in this same repository, which carries its own provenance labels and its own research ledger. Treat it as a dated secondary source rather than as a doc mirror. It dates from July 2026, which puts it roughly eight weeks behind the Foundry material, and eight weeks is long enough for a preview to reach general availability on either platform. The AgentCore guide documents five of its own claims that expired inside six weeks of research. Read every AgentCore row below as "true in July 2026, re-check before you quote it."

The Google column has no label, because it has no source. Nothing in this repository documents Google's agent platform, and inventing a competitor's feature from memory is exactly the failure mode provenance labels exist to prevent. A later section says what is checkable and what to go ask.

Two vendors, one decomposition

Read the two guides back to back, and the striking thing is not the feature overlap. It is the decomposition.

Both platforms sell a hosting contract that runs your container and isolates each session in its own virtual machine. Both sell a registry that puts every tool behind one MCP endpoint with centralized credentials. Both sell a memory service that extracts facts from conversations asynchronously. Both sell a per-agent identity distinct from the infrastructure identity that pulls your image. Both sell OpenTelemetry traces you did not instrument and a panel of LLM judges you did not write.

Neither sells a context manager. Neither sells the verdict.

Two vendors reaching the same seven-part split from different starting points is evidence that the split is real. It is not evidence that the products substitute for each other, because the same shape assembled on different foundations behaves differently at the seams. The seams are the rest of this article.

The table: nine axes, two grounded columns

Everything in the Foundry column is mirror-confirmed. Everything in the AgentCore column is from the July 2026 guide.

Axis	Microsoft Foundry	Amazon Bedrock AgentCore
Hosting runtime	Per-session VM-isolated sandbox with a persistent $HOME and /files, compute following the session rather than the request, idle timeout configurable from 2 through 60 minutes with a 15-minute default, and permanent deletion after 30 days of inactivity	Session-isolated microVM with isolated CPU, memory, and filesystem, ARM64 required, terminating after 15 minutes of inactivity or at an 8-hour maximum lease [AGENT-CORE-GUIDE: part-02-first-hosted-loop-claude-agent-sdk.md, July 2026]
Container contract	Listen on port 8088, return 200 OK from GET /readiness, and serve at least one of POST /responses or POST /invocations	Listen on 0.0.0.0:8080, serve POST /invocations with JSON in and JSON or SSE out, and answer GET /ping with Healthy or HealthyBusy [AGENT-CORE-GUIDE: part-02-first-hosted-loop-claude-agent-sdk.md, July 2026]
Protocol surface	Four declared protocols: Responses (OpenAI-compatible, platform-managed conversation), Invocations, Invocations over WebSocket, and Activity, plus A2A for delegation	One invocation route plus a WebSocket route registered by BedrockAgentCoreApp, and serve_a2a to publish an agent card [AGENT-CORE-GUIDE: part-04-runtime-contract-streaming-sessions.md, July 2026]
Tool and capability registry	Toolbox: tools defined once and exposed through a single MCP-compatible endpoint with centralized credential management, tool search, skills, versioning, and guardrails applied at the toolbox level	Gateway: APIs, Lambda functions, MCP servers, and Knowledge Bases behind one MCP endpoint with configurable inbound and outbound auth [AGENT-CORE-GUIDE: part-05-gateway-capability-registry.md, July 2026]
Memory and state	Four distinct services with four lifetimes: conversation, session, state store, and Memory, which is in public preview and carries preview licensing terms	Memory: short-term events keyed by actor, session, and branch, plus long-term semantic, summary, user-preference, and episodic strategies, with extraction running on AWS compute [AGENT-CORE-GUIDE: part-08-memory-across-sessions.md, July 2026]
Identity	A Microsoft Entra ID agent identity per agent, provisioned from a blueprint, exchanged automatically for scoped downstream tokens, and assignable in Azure RBAC as a service principal	Workload identity plus the requires_access_token, requires_api_key, and requires_iam_access_token decorators, injecting credentials into the tool function at call time and caching provider tokens in a vault [AGENT-CORE-GUIDE: part-09-identity-per-user-auth.md, July 2026]
Action authorization	Guardrails at four intervention points (user input, model output, and in preview tool calls and tool responses), plus Azure RBAC and Azure Policy on the resources	Policy: natural-language rules compiled to Cedar, running in log or enforce mode, generally available March 3, 2026 [AGENT-CORE-GUIDE: part-12-deploying-hardening-threat-model.md, July 2026]
Observability and evaluation	OpenTelemetry spans into your own Application Insights, silently off until someone connects it, plus agent evaluators, the AI Red Teaming Agent, and the agent optimizer	OpenTelemetry auto-instrumented when hosted in Runtime, requiring CloudWatch Transaction Search enabled once per account, plus thirteen built-in judges scoring 0 to 1 at tool-call, trace, and session level [AGENT-CORE-GUIDE: part-10-observability-evaluation.md, July 2026]
Bring your own framework	Framework-agnostic adapter packages that implement the whole contract, with two fully documented tracks: Microsoft Agent Framework and LangGraph with DeepAgents	A Starlette server that calls your async function and does not inspect it, with LangGraph, Strands, CrewAI, and Autogen named as first-class [AGENT-CORE-GUIDE: part-01-hyperscaler-as-harness-substrate.md, July 2026]
Fleet governance	Foundry Control Plane, in preview, plus Microsoft Agent 365, Microsoft Purview, Microsoft Defender, and Entra access reviews over an agent inventory	No aggregation layer named in the guide. Fleet governance is infrastructure as code plus IAM, with each worker provisioned deliberately because nothing is inherited [AGENT-CORE-GUIDE: part-12-deploying-hardening-threat-model.md, July 2026]

Nine rows, and most of them are detail. Two of them decide real adoptions.

Where they actually diverge: identity

The identity row decides more migrations than any other, and the reason is not the mechanism.

Both mechanisms are good. The AgentCore decorator is the cleanest piece of mechanical enforcement in either platform, because the model cannot leak a token it never held [AGENT-CORE-GUIDE: part-09-identity-per-user-auth.md, July 2026]. Foundry's token exchange does the same work at a different layer, running a multi-step OAuth 2.0 exchange between Agent Service, Microsoft Entra ID, and the downstream resource, with the developer never handling a token. Neither is meaningfully harder to wire than the other.

The difference is where the chain terminates.

A Foundry agent identity is a service principal in the same directory that already holds your employees, your groups, your conditional access policies, and your access reviews. Assigning an Azure RBAC role to an agent is the same operation your platform team already performs for a human, with the same audit trail and the same review cadence.

Read that as a conditional advantage rather than as a feature win. If your organization already runs on Entra, the Foundry identity story is free, because the expensive part was paid for years ago. If it does not, the same story is a directory migration wearing a feature's clothes, and the self-contained AgentCore workload identity is the smaller commitment. The claim that Foundry is furthest ahead on enterprise identity is true, and it is true for a reason that has almost nothing to do with agents.

Where they diverge for a less obvious reason: the vocabulary of state

Foundry names four state services and insists you keep them apart. A conversation is a durable message record. A session is a compute lease with a persistent filesystem. A state store is a durable key-value partition you address by a name you choose. Memory is LLM-extracted long-term knowledge. Merging any two of them in your head designs the wrong isolation model.

AgentCore names two, and warns about the same collision from the other side. Its Memory service covers short-term events and long-term strategies, and its guide spends a chapter on the fact that the AgentCore session is a microVM lease while the framework session is conversation state, joined only by an identifier you thread between them [AGENT-CORE-GUIDE: part-04-runtime-contract-streaming-sessions.md, July 2026].

Same failure, two vocabularies. The platform that names four services makes the distinction harder to ignore and the documentation harder to skim. The platform that names two makes the first hour easier and the third month more surprising. Neither one saves you from choosing a partition key.

One thing is identical on both, and it is the part that matters. Extraction is managed. Trust is not. The Foundry security-risks section describes memory written from model-processed content as a prompt-injection write path into trusted context, and the AgentCore guide says the same thing in different words: the extraction strategy is not a validator, and a managed memory service that faithfully persists a lie is working as designed [AGENT-CORE-GUIDE: part-08-memory-across-sessions.md, July 2026]. Two platforms, one residual responsibility, and it is yours on both.

Two asymmetries worth checking before you repeat them

Both of these circulate in comparison decks. One of them is wrong.

The managed browser is not an asymmetry. AgentCore ships a Browser that provisions a real Chromium instance in its own microVM driven by Playwright [AGENT-CORE-GUIDE: part-07-governed-browser.md, July 2026], and it is frequently cited as something Foundry lacks. Foundry ships one too. The Browser Automation tool creates isolated Playwright sessions for navigation and form filling, and it is in preview. What differs is the constraints, not the capability: Foundry browser automation does not work behind network isolation at all, and AgentCore browser sessions auto-expire after one hour [AGENT-CORE-GUIDE: part-07-governed-browser.md, July 2026]. Compare the constraints. Do not print the capability gap, because it is not there.

Action authorization is an asymmetry, and a narrower one than it sounds. AgentCore Policy takes rules written in natural language, compiles them to Cedar, and runs them in log or enforce mode against agent actions [AGENT-CORE-GUIDE: part-12-deploying-hardening-threat-model.md, July 2026]. Nothing in the Foundry mirror compiles rules into an authorization language for agent actions. The nearest Foundry analogs do a different job: guardrails screen content at intervention points, and Azure RBAC and Azure Policy authorize against resources rather than against a specific tool invocation under a specific condition. Content screening and action authorization are not substitutes, and a design review that treats them as equivalent will find the gap later, at the tool boundary.

Be precise about what Policy is worth before you weight it. The AgentCore guide is blunt on the same point the Foundry material makes about evaluators: Policy enforces your rules, and nobody at AWS knows that a discount over 40 percent needs a director's approval at your company. A managed Cedar engine is a real piece of harness. It is not a policy.

And one claim this article declines to state. Foundry Memory is in public preview, confirmed, with preview licensing terms and documented quotas [PERISHABLE: preview, checked September 2026]. A comparison you will see sets that against Google's Memory Bank being generally available. The Foundry half of that sentence is verified here. The Google half is not verifiable from anything in this repository, so the sentence does not appear in the table. Go check it yourself before you put it in a slide, and check the Foundry half again too, because preview status is the most perishable fact in this entire comparison.

The third control plane, and why it gets questions instead of a column

Google's platform is absent from the table because printing an unverified column next to two sourced ones would make the unverified one look sourced.

What is checkable comes from a live documentation lookup on September 18, 2026, rather than from the mirror. Google's agent platform documentation now resolves under docs.cloud.google.com/gemini-enterprise-agent-platform/, and Google presents Gemini Enterprise Agent Platform as the evolution of Vertex AI. The pages under that path cover creating an Agent Engine instance through client.agent_engines.create, a Sessions service consumed through VertexAiSessionService, a Memory Bank configured as a memory_bank_config under an agent engine's context_spec and consumed through VertexAiMemoryBankService, and the Agent Development Kit as the documented authoring path. Those are API shapes visible in Google's own current samples, and they say roughly what the first three rows of the table would say: there is a hosted runtime, there is a session service, and there is a managed long-term memory service.

Everything else is unknown from here, including the parts a reader most needs. Treat the following as an evaluation checklist rather than as a summary of gaps, because an absence in this repository is not an absence in the product.

• The name. Confirm which product you are actually buying. A platform that repositioned itself in September 2026 is a platform whose documentation, console navigation, and support articles disagree with each other for a while.
• The hosting contract. Which port, which health probe, which request and response shape, and whether the isolation boundary is per session or per request.
• Session and memory lifetimes. How long a session lives, what happens to its filesystem, whether memory is generally available, and what the quotas are.
• The tool registry. Whether there is one governed endpoint with centralized credentials, or whether tool auth stays per agent.
• Identity. Whether an agent gets its own directory principal, how per-user delegation works, and what the audit log names.
• Action authorization. Whether there is an equivalent of Cedar-compiled action policy, content screening at intervention points, or both.
• Observability and evaluation. Whether tracing is on by default or silently off, and whether evaluators ship with the platform.
• Fleet governance. Whether an aggregation layer exists over many agents, and whether it joins the identity directory.

If you already run on Google Cloud, that list is a morning's work against current documentation, and the result will be more accurate than anything written here could be. What this article can tell you is that the eight questions are the right eight, because they are the axes on which the two platforms it can compare actually differ.

How to choose, which is not a score

The temptation with a comparison like this is to total the columns. Resist it. The totals decide nothing, and three earlier questions decide everything.

Where does your identity live? This is the first question and usually the last one. Entra plus Azure RBAC makes the Foundry identity and governance story nearly free, and makes every other platform's a parallel directory to maintain. IAM plus an AWS organization makes the AgentCore story the free one. The agent platform that matches your directory saves you the one piece of work in this entire comparison that no vendor can sell you a shortcut for.

Where does your data already sit? Agents are mostly retrieval, and retrieval is mostly latency, egress, and a data-residency argument. The internal research archive, the knowledge base, and the vector store your agent reads are probably all in one cloud already. Moving the agent to the data is cheaper than moving the data to the agent, every time.

What has your compliance reviewer already signed? A platform your organization holds an authority to operate for is months ahead of a technically superior platform that needs a new one. The feature-availability table is the real compliance boundary, and the approval you already hold is a feature.

In production: when the three answers point at the same cloud, stop evaluating and start building. When they point at different clouds, the tiebreaker is the one your security team will have to operate at 3 a.m., not the one with the longer service list.

Two things this article will not do. It will not name a winner, because the research behind it refused to and was right to refuse. And it will not tell you the choice is reversible. Your container image and your framework code are portable on both platforms, because the adapter is a thin protocol shell in each case. The managed conversation store, the memory, and the registry configuration are not portable on either.

Do this today

• Re-date every row before you reuse it. Anything labeled July 2026 is a secondary source that has had time to go stale; confirm it against current AWS documentation before it lands in a slide.
• Answer the identity question first, in writing. Name the directory your organization already runs on, then note what a parallel directory would cost to operate, not to set up.
• Delete the managed browser from your comparison deck's gap list. Replace it with the two constraints that actually differ: network isolation on one side, a one-hour session expiry on the other.
• Check whether your design assumes content screening is action authorization. If a rule of yours says "this tool, under this condition, only with approval," find out which layer is actually enforcing it.
• Take the eight questions to whatever third platform you are considering and answer them against live documentation in one morning. Treat any answer you cannot source as unanswered.

What none of them sells

Seventeen parts and four appendices, one research desk, and one sentence that has not moved: the loop is yours, the substrate is theirs.

The substrate got good. Two hyperscalers, working independently, converged on a per-session isolated sandbox, a governed tool registry with credential injection, a managed memory service with asynchronous extraction, a per-agent identity, auto-instrumented traces, and a panel of judges. Ten years ago each of those was a quarter of engineering. Today each is a configuration decision and a bill, and there has never been a medal for hand-rolling a credential-injecting tool gateway.

Look down the residual column on either platform and the list is identical. The entitlement model. The partition key. The write-time validator that decides what should never be remembered. The tool description that determines whether the model can tell two tools apart. The golden set and the judge calibration. The stopping conditions. The threat model. Microsoft will sell you an identity per agent and a pane that inventories your whole estate. Amazon will sell you a Cedar engine and thirteen judges. Google will sell you something this article declines to describe. None of the three can tell you what your agent should never be allowed to do, because none of them knows your business, and the part of this work that requires knowing your business is the part that was always the actual engineering.

Learn the components, because the components are stable. Rent whatever the platform is selling this quarter, because the SKUs are not. Then spend everything you saved on the judgment, and date every fact you rely on, including the ones in that table.

---

This is Appendix D of "Azure Microsoft Foundry: Deploy your Harness to the Hyperscaler Control Plane," a seventeen-part guide (plus four appendices) to keeping your agentic loop and renting the substrate on Microsoft Foundry.