In 2024, building an AI agent mostly meant picking a framework, wiring it to a model API and running it in a container. By late 2026, each major cloud provider offers a managed platform that handles the hard production parts: isolated runtimes, memory, identity, tool gateways, observability and governance. Amazon Bedrock AgentCore reached general availability in October 2025, Microsoft announced general availability of its next-generation Foundry Agent Service in March 2026, and Google introduced the Gemini Enterprise Agent Platform at Google Cloud Next in April 2026 as the evolution of Vertex AI.
For platform leaders, the question is no longer whether managed agent infrastructure exists, but which one to adopt, how far to commit, and how to stay portable. This guide compares the three platforms at the level that matters for architecture decisions, then offers a structured way to choose.
Why Managed Agent Platforms Emerged
Agents differ from chat assistants in ways that stress traditional application infrastructure. They run long, multi-step tasks; they call tools and APIs on behalf of users; they need memory across sessions; and they make decisions that must be auditable. Teams that built agents on general-purpose compute discovered they were reinventing the same components repeatedly:
- Session isolation so that one user’s agent cannot see another’s context or credentials.
- Long-running execution beyond the limits of typical serverless functions.
- Memory services that extract and consolidate useful facts rather than replaying entire histories.
- Identity and delegated authorization so that agents can act for a user, or as themselves, with least privilege.
- Tool gateways that expose enterprise APIs to agents securely, increasingly through the Model Context Protocol (MCP).
- Observability that traces each reasoning step, tool call and model invocation.
- Governance over which agents exist, who owns them and what they can access.
Managed platforms package these components so that teams can focus on agent logic. The trade-off, as always with managed services, is dependence on a provider’s design choices.
The Three Platforms at a Glance
Amazon Bedrock AgentCore
AWS announced AgentCore general availability on October 13, 2025. According to the announcement, it comprises a Runtime with execution windows of up to eight hours, complete session isolation and support for the Agent-to-Agent (A2A) protocol; Memory with a self-managed option for controlling extraction and consolidation; a Gateway that connects to existing MCP servers and converts APIs and Lambda functions into agent tools, with IAM and OAuth authorization; Identity with secure token vaulting and OAuth integration so agents can act for users or independently; and Observability built on CloudWatch and compatible with OpenTelemetry. AWS supports VPC, PrivateLink, CloudFormation and tagging across the services. Notably, AWS positions AgentCore as framework- and model-agnostic, naming CrewAI, LangGraph, LlamaIndex, Google ADK and the OpenAI Agents SDK, and stating that it works with models in or outside Bedrock.
Microsoft Foundry Agent Service
Microsoft announced general availability of the next-generation Foundry Agent Service in March 2026, describing a redesigned API format and runtime experience intended to help teams move agents from prototype to production, with a message of being secure by design and observable by default. Industry analysts at Directions on Microsoft describe it as a managed control plane for building, deploying and operating agents with life-cycle management, security boundaries and observability, integrated with Microsoft’s identity and AI services, and note that Agent 365 complements it with governance, inventory and compliance across environments. For organizations standardized on Microsoft 365, Entra and Azure, this integration is the main draw.
Google Gemini Enterprise Agent Platform
Google announced the Gemini Enterprise Agent Platform on April 22, 2026, calling it its new developer platform and the evolution of Vertex AI. Google groups capabilities into build (the Agent Development Kit with a graph-based framework and MCP support, plus a low-code Agent Studio), scale (Agent Runtime with agent-to-agent orchestration, plus Memory Bank and Memory Profiles), govern (Agent Identity with a unique cryptographic ID per agent, Agent Gateway for controlling agent interactions with data, and Model Armor against prompt injection, tool poisoning and data leakage) and optimize (Agent Simulation for pre-deployment stress testing and Agent Observability). It supports both A2A and MCP.
Comparing the Platforms on What Matters
Feature lists converge quickly in this market, so compare on architectural characteristics that are harder to change.
Openness and portability
All three now support MCP for tools and A2A for agent interoperability, which reduces lock-in at the protocol level. AgentCore stands out in its explicit support for third-party frameworks and external models. Google’s ADK and Microsoft’s SDKs are open in various ways, but each platform naturally works best with its own models and tooling. Evaluate how much of your agent code would need rewriting to move platforms, and keep business logic in framework-neutral modules where possible.
Identity and access model
Identity is where agents meet enterprise security. AWS relies on IAM plus OAuth with a token vault. Google assigns cryptographic agent identities and routes interactions through a gateway. Microsoft builds on Entra and its broader identity and compliance stack. The best fit is usually the platform that aligns with your existing identity provider and security tooling, because duplicating identity governance across clouds is costly and error-prone.
Runtime characteristics
Look at maximum execution duration, isolation guarantees, cold-start behavior, scaling limits and network controls such as private connectivity. AWS documents eight-hour execution windows and session isolation; check current limits and regional availability for each platform against your workloads, since these change frequently.
Memory
All three provide managed memory. Differences lie in how much control you have over extraction, retention and deletion, and how memory data is stored and governed. For regulated use cases, verify retention controls and the ability to honor deletion requests.
Governance and safety
Google bundles guardrails such as Model Armor and simulation into the platform. Microsoft pairs Foundry with Agent 365 for organization-wide agent governance. AWS provides building blocks in AgentCore and surrounding AWS services. Consider where your agent inventory, policy enforcement and audit trails will live, especially if you run agents across more than one cloud.
Ecosystem gravity
Agents need data and tools. If most of your enterprise data sits in one cloud’s warehouses and lakes, and most users live in one productivity suite, the platform closest to both will usually minimize integration work, latency and egress costs.
Protocols such as MCP and A2A have made agent platforms more interchangeable at the edges. The real lock-in now lives in identity, data gravity and operational tooling, so choose with those in mind.
A Structured Selection Process
- Inventory candidate use cases. List the first five to ten agent use cases with their data sources, tools, users, risk level and expected volume.
- Map your gravity. Identify where the relevant data, identity provider, productivity suite and existing AI workloads already live.
- Define non-negotiables. Data residency, private networking, regulatory requirements, model choice and audit needs.
- Score each platform. Use weighted criteria: integration fit, security and identity, runtime fit, governance, portability, cost model and team skills.
- Run a proof of value. Build the same representative agent on the top one or two platforms. Measure development effort, latency, reliability, observability quality and cost per completed task.
- Decide the operating model. Choose a primary platform, define when exceptions are allowed and how cross-platform agents will be governed.
- Plan for portability. Standardize on MCP for tools, A2A for agent collaboration, OpenTelemetry for traces, and keep prompts, policies and evaluation suites in version control outside any single platform.
What to Measure in a Proof of Value
A proof of value is only useful if it produces comparable evidence. Build one representative agent, with real tools and realistic data, on each shortlisted platform and capture the same measurements:
- Task success rate: the share of evaluation tasks completed correctly, judged against a fixed test set of 50 to 200 realistic requests with expected outcomes.
- Latency: median and 95th percentile time to complete a task, including tool calls and any human approval steps.
- Cost per completed task: all platform meters plus model tokens, divided by successful tasks rather than attempts.
- Developer effort: engineering days to reach a working, secured, observable agent, and the volume of platform-specific code written.
- Failure behavior: how the agent and platform handle tool timeouts, permission denials, malformed responses and model errors.
- Observability depth: whether a reviewer can reconstruct exactly what the agent did and why from traces alone.
- Security posture: results of a basic red-team exercise covering prompt injection through retrieved content, tool misuse and data exfiltration attempts.
Keep the evaluation set and harness in your own repository so that the same tests can be re-run when models, platforms or prompts change. That harness often outlives the platform decision itself and becomes the backbone of ongoing quality assurance.
Cost Considerations
Agent platform costs combine several meters: runtime compute, memory storage and operations, gateway calls, observability data and, usually largest, model tokens. Agentic workloads can consume far more tokens than simple chat because of planning, tool descriptions and retries. When comparing platforms, model cost per completed business task rather than per request, and include the cost of logs and traces, which grow quickly at scale. Also check whether platform charges apply when agents call models from other providers.
Hypothetical Example: A Multi-Cloud Insurer Chooses a Primary Platform
Consider a hypothetical insurer whose claims data and core systems run on AWS, while employees use Microsoft 365 and Entra ID. The first agent use cases are claims triage, policy document Q&A for brokers and an internal IT helpdesk agent.
Scoring shows that claims triage, which is data-heavy and calls internal APIs, fits AgentCore well because the data and services already sit in AWS and Gateway can expose existing Lambda functions as tools. The IT helpdesk agent, which lives inside Teams and acts on Microsoft 365 resources, fits Foundry better. The insurer chooses AgentCore as the primary platform for line-of-business agents and allows Foundry for productivity-suite agents. It standardizes on MCP for tools, A2A for cross-agent calls and OpenTelemetry traces exported to a central observability stack, and it maintains a single agent register that records every agent, owner, platform, data access and risk tier regardless of where it runs. In this illustration, the insurer gains the benefits of managed platforms without fragmenting governance.
Pitfalls to Avoid
- Choosing on demo quality. Demos highlight the happy path. Test failure handling, long-running tasks, permission errors and observability.
- Ignoring identity design. Agents with broad service credentials are a major risk. Design delegated, least-privilege access from the start.
- Letting every team pick its own platform. Freedom without a register and common standards leads to shadow agents and duplicated effort.
- Skipping evaluation. Without task-level evaluation suites, you cannot compare platforms or detect regressions after model updates.
- Assuming feature parity is stable. These platforms change monthly. Re-check capabilities and limits before major commitments.
Outlook: 2027 and Beyond
Expect continued convergence on protocols, with MCP and A2A becoming baseline expectations and cross-cloud agent collaboration more common. Differentiation will shift toward governance at scale, cost efficiency, evaluation and simulation tools, and integration with each provider’s data and productivity ecosystems. Organization-wide agent registries and control planes that span platforms are likely to become a distinct layer, whether provided by hyperscalers, independent vendors or built in-house. Regulation, including the EU AI Act’s obligations for high-risk systems that the AI Omnibus has pushed into late 2027 and 2028, will add pressure for traceability and documentation, favoring platforms with strong audit capabilities.
Selection Checklist
- Have we mapped data, identity and productivity-suite gravity for our first use cases?
- Do candidate platforms meet residency, networking and compliance requirements in our regions?
- Have we built the same agent on at least two platforms and measured cost per task?
- Is agent identity designed for delegation and least privilege?
- Are tools exposed through MCP and agent-to-agent calls through A2A where possible?
- Do traces flow into a central observability stack using OpenTelemetry?
- Is there one agent register covering every platform?
Conclusion
Managed agent platforms from AWS, Microsoft and Google have removed much of the undifferentiated heavy lifting from production agents. Each has a coherent design: AgentCore emphasizes openness to frameworks and models, Foundry emphasizes integration with Microsoft’s identity and productivity ecosystem, and Gemini Enterprise Agent Platform emphasizes an end-to-end build, scale, govern and optimize lifecycle. The right choice depends less on feature checklists than on where your data, identities and users already live. Pick a primary platform, standardize on open protocols and telemetry, and govern every agent in one register. That combination gives you speed today and options tomorrow.
How Hanoi Technology Can Help
Hanoi Technology helps teams evaluate managed agent platforms, run proofs of value and build portable, well-governed agent architectures on AWS, Azure and Google Cloud.