Amazon Bedrock AgentCore vs Microsoft Foundry Agent Service vs Google Agent Engine

Building an AI agent prototype takes an afternoon. Running one reliably for thousands of concurrent enterprise users, with real identity, memory that persists correctly, tool access that doesn’t leak permissions, and observability that catches failures before customers do, is a different problem entirely, and it’s the specific problem Amazon Bedrock AgentCore, Microsoft Foundry Agent Service, and Google’s agent platform all exist to solve. This sits one architectural layer above the foundation-model decision covered in our Bedrock vs Foundry vs Gemini Enterprise vs OCI comparison, agent infrastructure runs on top of whichever model platform you’ve already chosen, not instead of it. Comparing these three isn’t a simple AWS-vs-Azure-vs-Google exercise, because they’re not architected the same way: AgentCore is a modular set of separately adoptable services, Foundry Agent Service splits cleanly into configuration-driven and code-first paths, and Google’s platform has been reorganized substantially in 2026 under new branding most existing comparisons haven’t caught up with yet. This article covers what each platform actually manages for you, what your team still has to build, and how to evaluate them against your organization’s real requirements.

Quick Answer

Amazon Bedrock AgentCore, Microsoft Foundry Agent Service, and Google’s Gemini Enterprise Agent Platform all provide managed infrastructure for production AI agents, but they differ meaningfully in architecture, development model, identity, memory, tooling, and cloud ecosystem alignment. AgentCore is the most modular, separate Runtime, Memory, Gateway, and Identity services you adopt independently. Foundry Agent Service offers the clearest split between low-code (Prompt agents) and full-control (Hosted agents) paths. Google’s platform is the most consolidated, folding agent building, model access, and governance into one unified environment following its 2026 rebrand from Vertex AI. None is universally best, the right choice depends on your existing cloud ecosystem, identity requirements, and how much infrastructure your team wants to own directly.

Comparison Table

Several capabilities above are in public preview as of mid-2026 (noted where applicable), verify current GA status directly before architecting around any specific feature.

Amazon Bedrock AgentCore

AgentCore is best understood as a modular collection of managed capabilities, not a single agent builder, AWS deliberately built it so teams can adopt Runtime, Memory, Gateway, and Identity independently rather than all-or-nothing. It reached general availability in late 2025 and has shipped major capability waves through mid-2026, which matters practically: this is an actively evolving platform, not a static one you evaluate once.

Runtime evolved substantially in 2026, moving beyond ephemeral microVM sessions to persistent Runtime Instances on EC2, enabling much longer-running sessions suited to sustained workloads rather than short-lived interactions. Memory provides semantic, episodic, and procedural memory types as a managed service, removing the need for teams to build their own extraction and retrieval logic from scratch. Gateway turns existing APIs and Lambda functions into managed tools agents can call, and gained MCP Sessions support in 2026, stateful, per-user sessions with configurable timeouts, plus temporal policies and rate limiting that evaluate authorization across a sequence of actions rather than just one isolated call. Identity is built specifically for non-human, automated workloads, supporting OAuth 2.0, AWS SigV4, and now direct references to existing AWS Secrets Manager secrets, so credential governance stays under your existing policies rather than a separate system. Browser and Code Interpreter round out the suite, giving agents managed, isolated environments for web interaction and code execution, Browser specifically gained OS-level interaction capabilities in April 2026, reflecting AWS’s stated intent to support real enterprise environments, not just sandbox demos.

What AgentCore manages, and what you still build: AWS manages the runtime infrastructure, memory persistence, tool gateway, and identity layer. Your team still designs the actual agent logic, decides which memory types and retention policies fit your use case, and builds the business-specific tool integrations Gateway exposes.

Microsoft Foundry Agent Service

Foundry Agent Service’s defining structure is the split between two genuinely different agent types. Prompt agents are authored through the portal or SDKs, with Foundry running them entirely, no compute, containers, or packaging decisions required, at the cost of less low-level control. Hosted agents, which reached public preview April 22, 2026 with expected general availability by early July 2026, let you bring your own code and framework, packaged and run inside Foundry’s managed infrastructure: every session gets its own hypervisor-isolated sandbox with a persistent filesystem, genuine hardware-level isolation, not just process separation, plus predictable cold starts and scale-to-zero economics when idle.

Around both agent types, Toolboxes (public preview) provide one governed endpoint for tools, skills, MCP clients, and enterprise data integrations, with Tool Search helping the platform surface only the relevant subset of tools for a given task rather than exposing everything to the model at once. Foundry IQ provides SLA-backed knowledge retrieval without custom indexing work, covered in more depth in our companion piece on Bedrock Knowledge Bases, Azure AI Search, and Foundry IQ. Voice Live unifies speech recognition, text-to-speech, and turn detection into one API, generally available for prompt agents. The model catalog spans nearly 2,000 options, including Microsoft, OpenAI, Anthropic, and Meta models, and the platform is explicitly framework-agnostic, LangGraph, Semantic Kernel, AutoGen, CrewAI, and Claude Agent SDK investments all carry forward rather than being locked out.

A newer category, Foundry autopilot agents (preview), gets its own Entra Agent ID, productivity license, email, calendar, and Teams presence, designed specifically for shared spaces like group chats rather than one-on-one interactions, a genuinely different pattern than either AgentCore or Google’s approach currently offers as a named category.

What Foundry manages, and what you still build: Microsoft manages the sandbox runtime, identity issuance, and tool governance layer. Your team still chooses between the Prompt or Hosted path based on how much control you actually need, and builds the agent logic itself, Foundry doesn’t write your business logic, it runs it reliably once written.

Google Agent Engine (Now Part of Gemini Enterprise Agent Platform)

Precision matters most here. At Google Cloud Next 2026 on April 22, Google rebranded Vertex AI entirely into the Gemini Enterprise Agent Platform, not an addition alongside Vertex AI, a replacement of it. Google’s own materials state plainly that “going forward, all Vertex AI services and roadmap evolutions will be delivered exclusively through Agent Platform.” What was previously discussed as “Agent Engine” now operates as Agent Runtime, paired with Memory Bank for persistent state, Google specifically designed this to solve what it calls “institutional amnesia,” letting agents maintain context across days rather than losing it when a session ends.

Development happens through two paths mirroring the low-code/code-first split seen elsewhere in this comparison: Agent Studio, a low-code visual interface for building and testing agents in natural language, and the Agent Development Kit (ADK), now supporting “sub-agents”, a primary agent delegating specialized tasks to others within a graph-based framework. The Model Garden now spans over 200 models, notably including third-party options like Anthropic’s Claude alongside Google’s own Gemini family, a real signal Google is competing on platform breadth, not just its own models. Tool connectivity runs through managed MCP servers, with Apigee serving as an API-to-agent bridge, and the Agent2Agent (A2A) protocol, Google’s own cross-platform agent communication standard, is already reported in production use at over 150 organizations, a genuinely specific adoption figure most competing platforms haven’t published an equivalent for yet.

What Google’s platform manages, and what you still build: Google manages the unified runtime, memory persistence, and model access layer across its expanded catalog. Your team still designs the actual agent workflows and decides how deeply to invest in Google-specific tooling (Agent Studio, ADK-native patterns) versus a more portable, framework-based approach.

AgentCore vs. Foundry Agent Service

The core architectural difference is modularity versus a defined dual-path structure. AgentCore lets you adopt Memory, Gateway, or Identity independently, which suits teams that want to integrate agent infrastructure piece by piece into an existing AWS environment. Foundry’s Prompt-vs-Hosted split is more prescriptive but arguably clearer for teams deciding upfront how much control they actually need — a business analyst building a Prompt agent and an engineering team building a Hosted agent are having genuinely different conversations, by design. On identity, AgentCore Identity’s non-human-workload focus and direct Secrets Manager integration suit AWS-native credential governance; Foundry’s Entra Agent ID (particularly for autopilot agents) suits organizations already standardized on Microsoft identity infrastructure. Both now support MCP and A2A, so protocol-level interoperability isn’t a meaningful differentiator between them anymore.

AgentCore vs. Google Agent Runtime

AWS and Google take different views on agent memory specifically: AgentCore’s three distinct memory types (semantic, episodic, procedural) give more granular control over what gets remembered and how; Google’s Memory Bank is positioned more simply around multi-day persistence as a single capability. On tooling, AgentCore Gateway’s approach of turning existing APIs and Lambda functions into agent tools fits teams with substantial existing AWS service investment; Google’s Apigee-based API-to-agent bridge serves a similar purpose within the Google Cloud ecosystem specifically. Google’s reported 150+ organization production adoption of A2A is a genuinely useful data point if cross-platform agent communication is a real requirement, AWS hasn’t published an equivalent adoption figure for AgentCore’s A2A support.

Foundry Agent Service vs. Google Agent Runtime

Both platforms offer a clear low-code/code-first split (Prompt agents vs. Hosted agents; Agent Studio vs. ADK), making this the closest architectural match of the three pairings. The meaningful difference is breadth of model access versus enterprise workspace integration: Google’s Model Garden spans 200+ models with notable third-party inclusion (Anthropic’s Claude), while Foundry’s strength leans toward deep Microsoft 365 and Teams integration, autopilot agents with their own Entra identity and Teams presence are a genuinely distinct pattern Google’s platform doesn’t currently offer an equivalent for. Framework flexibility is comparable on both sides.

Multi-Agent Systems

All three platforms now support multi-agent patterns, but through different mechanisms worth understanding rather than treating as interchangeable checkboxes. AgentCore relies on Gateway’s tool-routing and A2A support at the runtime level, giving teams flexibility to architect multi-agent coordination themselves. Foundry’s autopilot agents and native sub-agent delegation offer a more structured, platform-defined pattern, particularly suited to workflows happening inside shared enterprise spaces like Teams. Google’s ADK-native sub-agents combined with A2A’s cross-platform reach make it the strongest option specifically when agents need to communicate across different platforms or vendors, not just within one ecosystem, the 150+ organization production figure is real evidence this pattern works at scale, not just in Google’s own documentation. No platform here dominates multi-agent architecture universally; the right fit depends on whether your coordination needs are internal-only or genuinely cross-platform.

Security Comparison

Each platform ties agent identity into its parent cloud’s existing identity system rather than inventing something separate: AWS IAM and AgentCore Identity (with direct Secrets Manager integration), Microsoft Entra ID and RBAC (extended to Entra Agent ID for autopilot agents specifically), and Google Cloud IAM with service accounts. This isn’t a “which is more secure” ranking, it’s a “which is already your organization’s source of truth” question, and the practical answer is almost always whichever identity system already governs the rest of your infrastructure. Governance tooling differs in maturity and framing: AgentCore’s temporal policies evaluate authorization across a sequence of actions rather than single calls; Foundry’s ASSERT and Agent Control Specification formalize evaluation and control as named, documented processes; Google’s governance lives inside the unified Agent Platform console alongside build and scale tooling. This identity layer is necessary but not sufficient on its own, it connects directly to the broader security and compliance discipline your infrastructure needs regardless of which agent platform sits on top of it, and to the separate question of content safety and prompt injection defense that governs what an agent actually says and does once it’s running.

Observability and Evaluation

Observability matters more as agents gain more autonomy, because failure modes get subtler, a tool call returning quietly wrong data is a different debugging problem than an outright crash a basic log file catches. All three platforms have invested here in 2026 specifically: AgentCore’s Observability and Evaluations integrate with its Gateway and Runtime directly; Foundry’s Agent Optimizer runs a closed loop, evaluate, generate candidates, rank, deploy, turning production failures into ranked, reviewable improvements rather than just alerts; Google’s evaluation tooling sits inside the same unified console handling build and governance. This is the same continuous monitoring discipline that matters for any production system, an agent platform’s built-in observability tooling is a real starting point, not a substitute for actually watching what’s happening in your specific deployment. None of the three treats basic logging as sufficient on its own anymore, that’s a genuine, shared 2026 shift across all three ecosystems, not a differentiator between them.

Developer Experience

The low-code-versus-code-first spectrum runs consistently across all three platforms, just under different names: Foundry’s Prompt agents, Google’s Agent Studio, and (to a lesser extent) AgentCore’s managed-harness path all reduce infrastructure decisions for teams wanting speed. Foundry’s Hosted agents, Google’s ADK, and AgentCore’s full framework flexibility all serve teams wanting maximum control at the cost of more setup responsibility. No single platform is “easier” in the abstract, the right fit depends on whether your team already has framework experience and wants to keep it, or is starting fresh and can pick whichever platform’s opinionated defaults fit best.

Enterprise Use Cases

Customer service agents benefit from persistent memory across long conversations, AgentCore Memory’s episodic type, Foundry’s session/user memory, and Google’s Memory Bank all address this directly. Internal enterprise assistants and IT automation suit Foundry’s autopilot agents specifically well, given their native Teams and Microsoft 365 presence. DevOps and infrastructure agents, monitoring and remediating systems overnight, map directly to Foundry’s Routines (scheduled agent runs) and similar scheduling patterns on the other platforms. Financial services and healthcare workflows need the identity and governance depth all three now offer, though the specific compliance evidence each platform’s tooling produces differs and should be evaluated against your actual regulatory requirements directly, not assumed equivalent, fintech-specific compliance and HIPAA-compliant infrastructure both sit underneath the agent platform layer as separate, necessary requirements. Cross-platform, multi-vendor agent coordination is where Google’s A2A production adoption at 150+ organizations is the most concrete, currently available evidence of real-world scale.

Cost and Total Cost of Ownership

None of the three platforms publish pricing simple enough to responsibly reduce to a single number here, and this article won’t invent one. Real cost drivers span model usage, agent runtime hours, memory storage, tool/API calls, networking, observability data volume, and critically, engineering time. A more modular platform like AgentCore can mean lower platform fees but more integration engineering; a more consolidated platform can mean higher platform cost but less assembly work. Total cost of ownership has to include the cost of your team’s time configuring, governing, and maintaining whichever platform you choose, not just the metered service charges, which is why comparing sticker prices alone is close to meaningless without factoring in your team’s actual capacity and existing expertise.

How to Choose an AI Agent Platform

1. Which cloud already hosts your infrastructure? Cross-cloud agent deployment adds real integration cost regardless of platform quality.
2. Which identity system already governs your organization? AWS IAM, Entra ID, or Google Cloud IAM, matching your existing source of truth beats any feature comparison.
3. Do you need modular adoption or a defined structure? AgentCore for piece-by-piece integration; Foundry’s Prompt/Hosted split or Google’s Studio/ADK split for clearer upfront structure.
4. What are your framework commitments already? All three support major frameworks, but verify your specific stack’s current support level directly.
5. How deep are your memory requirements? Granular memory types (AgentCore) versus simpler persistent state (Google) versus TTL-controlled session memory (Foundry) suit different use cases.
6. Do you need cross-platform agent communication? Google’s A2A production adoption is currently the most evidenced option if this matters.
7. What’s your team’s actual engineering capacity? More modular platforms trade lower fees for more integration work; more consolidated platforms trade the reverse.
8. What does compliance actually require, not just permit? Verify each platform’s specific evidence and audit trail capabilities against your actual regulatory obligations, not a general assumption of parity.

Choosing and Building on the Right Platform

Evaluating these three platforms is a genuinely different task from choosing a conversational chatbot tool, covered separately in our Amazon Lex vs Copilot Studio vs Google Conversational Agents comparison, agent platforms are the production infrastructure layer, not the chat interface itself. If you’re weighing these platforms for a real deployment, our AI software development work spans all three clouds, building the actual agent logic these platforms are built to run, reach out if you want a second opinion grounded in real implementation experience rather than a vendor pitch.

Frequently Asked Questions

What is Amazon Bedrock AgentCore? 

A modular collection of AWS managed services, Runtime, Memory, Gateway, Identity, Browser, and Code Interpreter, for building and operating production AI agents, designed to be adopted independently rather than as one all-in-one product.

What is Microsoft Foundry Agent Service? 

Microsoft’s agent platform offering two distinct paths: Prompt agents (configuration-driven, Foundry-run) and Hosted agents (bring your own code, run in a hypervisor-isolated managed sandbox), alongside shared tooling like Toolboxes and Foundry IQ.

What is Google Agent Engine now called? 

Google rebranded Vertex AI into the Gemini Enterprise Agent Platform at Cloud Next 2026, with the component previously discussed as “Agent Engine” now operating as Agent Runtime, paired with Memory Bank for persistent state.

What’s the difference between AgentCore and Foundry Agent Service? 

AgentCore is more modular, letting teams adopt individual services independently. Foundry Agent Service has a more defined structure split between low-code Prompt agents and full-control Hosted agents, with the choice made explicitly upfront.

Is Google Agent Engine the same as Vertex AI Agent Engine? 

Yes, Vertex AI Agent Engine was the prior name. Following the April 2026 rebrand, it operates as Agent Runtime within the Gemini Enterprise Agent Platform, the successor to Vertex AI as a whole.

How do AgentCore, Foundry Agent Service, and Google Agent Runtime compare overall? 

All three provide managed infrastructure for production agents but differ in architecture: AgentCore is modular, Foundry offers a defined dual-path structure, and Google’s platform is the most consolidated following its 2026 reorganization.

Which platform supports multi-agent systems best? 

All three support multi-agent patterns through different mechanisms, Gateway/A2A for AgentCore, native sub-agent delegation for Foundry, and ADK sub-agents plus A2A for Google, which has the most concrete published production adoption figure (150+ organizations).

How do the platforms handle AI agent security? 

Each ties into its parent cloud’s existing identity system, AWS IAM/AgentCore Identity, Microsoft Entra ID/RBAC, Google Cloud IAM, rather than a separate system, so the practical choice usually follows whichever identity system already governs your organization.

How do the platforms handle AI agent observability? 

All three added meaningful observability and evaluation tooling in 2026, AgentCore Observability, Foundry’s Agent Optimizer closed-loop system, and Google’s integrated console tooling, reflecting a shared industry shift toward treating basic logging as insufficient for autonomous agents.

How should an enterprise choose an AI agent platform? 

Start with existing cloud infrastructure and identity systems, not a feature checklist, then weigh modularity versus structure, framework commitments, memory depth, and actual engineering capacity against total cost of ownership rather than headline pricing.