Microsoft Foundry vs Amazon Bedrock AgentCore vs Gemini Enterprise Agent Platform

Components side by side

The three platforms have converged on the same parts list. Each offers a managed runtime for agent code, a declarative path for simpler agents, per-agent identity, managed memory, a gateway that governs tool calls over MCP, a policy layer, tracing and evaluation, and a registry of agents and tools. The differences are in packaging, defaults, and how tightly each part binds to the rest of its cloud.

Microsoft Foundry (formerly Azure AI Foundry) offers three agent types in Foundry Agent Service: prompt agents defined entirely by configuration, voice-based prompt agents (preview), and hosted agents, which run your own code in a per-session, VM-isolated sandbox with a persistent file system. Hosted agents and Toolboxes reached general availability in July 2026.

Amazon Bedrock AgentCore is a set of modular services that work together or independently: Runtime, Harness, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Evaluations, Optimization, Policy, Payments, and Registry. AgentCore went GA in October 2025. Policy and Evaluations reached GA in March 2026, the Harness in July 2026, and AWS Agent Registry in August 2026.

Gemini Enterprise Agent Platform is what Google calls "an evolution of Vertex AI." The rename took effect on April 22, 2026. Google groups the platform into Build (ADK, Agent Studio, Model Garden), Scale (Agent Runtime, Sessions, Memory Bank), Govern (Agent Registry, Agent Identity, Agent Gateway), and Optimize (evaluation, simulation, observability, prompt optimization).

Models offered

All three are multi-model, with a home-team default. Foundry's catalog centers on Azure OpenAI models and adds Claude, Grok, Llama, DeepSeek, Mistral, and Microsoft's own models. AgentCore Runtime accepts any model inside or outside Bedrock. Google's platform leads with Gemini and offers Claude, Llama, DeepSeek, Grok, and others through Model Garden.

Specifics that matter in practice. Foundry listed claude-opus-5 as generally available on July 24, 2026, and its Model Router's Global Standard deployment is available in 28 regions. Some Foundry features are tied to Azure OpenAI deployments: Memory requires compatible Azure OpenAI chat and embedding models. The AgentCore Harness supports Bedrock, OpenAI, Google Gemini, and any LiteLLM-compatible provider, and can switch providers mid-session. Google added Claude Opus 5.5 to Model Garden on September 22, 2026.

Frameworks supported

Each platform hosts any framework, and each favors its own. Foundry hosted agents accept Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or custom code, in Python and C#. AgentCore Runtime lists Strands Agents, LangGraph, CrewAI, LlamaIndex, Google ADK, and the OpenAI Agents SDK. Agent Runtime gives ADK full integration, managed templates to LangChain, LangGraph, AG2, and LlamaIndex, and a custom template path for CrewAI and others.

The favored framework is where integration runs deepest. The AgentCore Harness is powered by Strands Agents and exports to Strands code. Agent Runtime's ADK telemetry metrics require ADK 2.6.0 or later. Foundry's Toolbox client is built into Agent Framework as FoundryToolbox.

Identity

Every agent gets its own identity on all three platforms, anchored in each cloud's directory. Foundry gives every agent a Microsoft Entra agent identity at creation and supports OAuth On-Behalf-Of passthrough. AgentCore Identity works with existing providers such as Cognito, Okta, Entra ID, and Auth0. Google's Agent Identity issues a SPIFFE-based identity per agent.

Each has a distinctive feature. Foundry autopilots add an Entra agent user account, so an agent can hold its own mailbox, calendar, and Teams presence and act in Microsoft 365 as itself. AgentCore added On-Behalf-Of token exchange in April 2026 and a hosted Consent Portal in September 2026, where end users approve an agent's access to resources on their behalf. Google's Agent Identity cannot be impersonated, does not allow long-lived keys, and records both the agent and the user in audit logs when the agent acts for someone.

Memory and knowledge

Memory is managed on all three, but maturity differs. AgentCore Memory is GA with short-term, long-term, and episodic strategies, direct ingestion, and record time-to-live as of October 2026. Google's Sessions and Memory Bank are long-standing Agent Engine features under new names. Foundry Memory, which extracts user profile, chat summary, and procedural memories, is in preview.

For curated organizational knowledge, each points to a separate retrieval service: Foundry IQ on Azure AI Search, Amazon Bedrock Managed Knowledge Base (GA July 2026, with S3, SharePoint, Confluence, Google Drive, OneDrive, and web crawler connectors), and Google's RAG Engine, Vector Search, and Agent Search. All three treat knowledge as retrieval over indexed documents.

Tool gateway and MCP

Each platform puts a governed gateway between agents and tools, and MCP is the common protocol. Foundry Toolboxes curate tools once and expose them behind one managed MCP endpoint with centralized authentication and versioning. AgentCore Gateway turns APIs and Lambda functions into MCP tools and fronts existing MCP servers, A2A agents, and model providers. Agent Gateway governs ingress and egress for MCP, A2A, and other HTTP traffic.

Agent Gateway is default-deny: connections are blocked unless an IAM policy grants them, and it supports VPC Service Controls as of September 2026. It governs Gemini Enterprise only in egress mode. AgentCore Gateway can be made the only path to a Runtime, so callers cannot bypass it. Foundry Toolboxes reached GA in July 2026.

Policy and guardrails

AgentCore and Google enforce business rules on tool calls outside the agent's code. Foundry relies on identity, RBAC, and content guardrails. AgentCore Policy intercepts every Gateway request and evaluates it against Cedar policies, which can be authored in natural language. Google's Semantic Governance policies use an LLM to check tool calls against plain-language rules. Foundry applies Entra RBAC, allowed-tool lists, and guardrails against prompt injection.

AgentCore Policy is deterministic and reached GA in March 2026. It supports temporal conditions over a session's history, such as a running budget total, and Bedrock Guardrails as of July 2026. Google pairs IAM Unified Access Policies (GA August 31, 2026) with Model Armor for prompt and response screening, and Semantic Governance policies, which return allow or deny and are in preview. Foundry's integrated guardrails target unsafe outputs and cross-prompt injection. Microsoft places organization-wide policy for agents in Agent 365, licensed per user.

Human approval

All three offer the primitives for a person to approve an agent action. None ships an approval workflow bound to business rules. Foundry's MCP tool can be set to require_approval, which returns an approval request your application must answer. AgentCore Policy can require that an approval was granted earlier in the session. ADK Tool Confirmation pauses a tool call for a yes or no, or for structured input.

The details decide how much a team builds. Foundry long-running hosted agents can suspend for days and survive container restarts while waiting for a reply, in preview. AgentCore Gateway passes MCP elicitation through to the client, and Harness lifecycle hooks can call a Lambda function that allows or denies a tool call. ADK Tool Confirmation is marked experimental, and Google's docs note it does not support the managed session service. On every platform, the team still builds the approver directory, thresholds, routing, and the screen where a reviewer decides.

Observability and evaluation

Evaluation has become a first-class service on all three. AgentCore Evaluations ships 13 built-in evaluators, custom LLM or code-based evaluators, batch evaluation, and A/B testing with live traffic splits. Foundry offers tracing into Application Insights, cloud evaluations, synthetic datasets, and an agent optimizer. Google offers multi-turn autoraters, online evaluation, simulated conversations, a Unified Trace Viewer, and prompt optimization.

AgentCore observability is billed through Amazon CloudWatch and accepts OpenTelemetry from agents running anywhere. Foundry injects an Application Insights connection string into every hosted agent. Google added Cloud Trace integration for Agent Gateway in preview in September 2026.

Registry

Each platform now catalogs agents and tools, and each catalog lives in its own cloud. AWS Agent Registry went GA in August 2026 with auto-detection of Runtimes and Gateways across AWS Organizations accounts, customer managed keys, and cross-account sharing. Google's Agent Registry catalogs agents, tools, and MCP servers, and Agent Gateway reads it to enforce policy. Foundry publishes agents to the Entra Agent Registry, and Agent 365 inventories them.

Agent 365 reaches furthest across vendors. Microsoft describes it as "the control plane to observe, secure, and govern AI agents," and states it governs agents regardless of the tools or frameworks used to build them, including partner agents. It costs $15 per user per month, or is included in Microsoft 365 E7 at $99 per user per month.

Pricing model

All three bill by consumption, in different units. AgentCore prices each service separately. Foundry bills model tokens and tool usage per call, plus container compute for hosted agents. Google consolidated runtime, sessions, and memory into three SKUs in 2026. Model tokens are billed separately on every platform.

AgentCore lists no separate charge for the Harness; you pay for the services it uses. Google's runtime offers a free tier. The Microsoft Agent 365 control plane is a per-user license on top of consumption.

Regions and sovereignty

Footprints are broad and roughly comparable; sovereign options differ. Foundry Agent Service runs in 30 Azure regions, plus Azure Government (US Gov Virginia and US Gov Arizona) with a subset of agent types and tools. AgentCore Runtime runs in 21 commercial regions plus AWS GovCloud (US-West). Agent Runtime runs in 23 Google Cloud regions, with us and eu multi-regional endpoints.

Feature coverage is narrower than the headline count. AWS Agent Registry is in five regions and the AgentCore Harness in sixteen of the twenty-two. Google's Memory Bank and Agent Gateway each run in 20 regions. Foundry Memory runs in 19 regions and does not support virtual network integration. For data residency, Foundry's standard setup keeps agent state in your own Cosmos DB, Storage, and AI Search resources, and Google states that agent locations provide data-at-rest residency for code, sessions, and memories.

When each wins

The platform that matches your existing cloud almost always wins, because identity, networking, data, and procurement already live there. Beyond that, three questions separate them.

Which identity provider runs your workforce? If it is Entra ID and people work in Teams and Microsoft 365, Foundry and Agent 365 extend what you already govern. AgentCore Identity federates with Entra ID and Okta, which matters if your agents run on AWS but your people sign in elsewhere.

Where does your data sit? Agents call data repeatedly, and egress, latency, and perimeter controls follow the data. BigQuery estates favor Google. S3, Aurora, and Redshift estates favor AWS. Fabric, SharePoint, and Azure SQL estates favor Microsoft.

How modular do you want to be? AgentCore is the most à la carte: teams adopt Gateway or Policy without Runtime, and AgentCore reports quality for agents running on Lambda, EKS, or outside AWS. Foundry is the most integrated with an employee suite. Google's platform is the most opinionated around one framework, ADK, and one employee app, Gemini Enterprise. On October 8, 2026, Google also announced the Gemini agent, a "universal agent for work" for the Gemini Enterprise app and Workspace.

What all three leave to you

All three platforms run, identify, connect, and observe agents. None of them builds the business application those agents serve. That layer sits above the runtime, and on every hyperscaler it remains the customer's work.

In practice, the application layer includes:

• Pages and users. The screens where people do the work, who may see them, and the page context an agent receives about what a person is looking at.
• Typed operations. The business actions the application can perform, declared once, with the same authorization check whether a page, a copilot, an API caller, or a schedule triggers them.
• Approval policies bound to business actions. Thresholds over typed arguments, named approver groups, and a frozen record of exactly what was approved, revalidated before it runs. The platforms provide the pause. The rule, the routing, and the reviewer's screen are application work.
• Evidence-backed context. Company knowledge with provenance, classification, and change control, so a run can show which facts it relied on. Memory and document retrieval are inputs to this, not the whole of it.
• Versioned outputs. Results that people and agents revise as numbered versions, with stale writes refused and authorship recorded.
• A release lifecycle for the application. Compiling the application's configuration into an immutable version, activating it with an audit record, and rolling back.

Teams either build this layer on top of the runtime or adopt an application platform for it. Agentic application platforms such as Pyrana sit above the hyperscaler layer and call models, agents, and tools hosted on it. The head-to-head pages cover each pairing: Pyrana vs Microsoft Foundry, Pyrana vs Amazon Bedrock AgentCore, and Pyrana vs Gemini Enterprise Agent Platform. For the layer distinctions in general, see agent framework vs runtime vs platform.