Cloud Agent Platforms

Building an AI agent is one problem. Running it in production is a different one entirely. The gap between a prototype that works on your laptop and an enterprise-grade agent handling thousands of requests per day is filled with infrastructure decisions: model hosting, tool orchestration, guardrails enforcement, memory management, identity controls, and observability. If you are still getting oriented on what agentic AI is and how it differs from traditional AI, start there before diving into platform selection. Cloud platforms exist to close that gap.

AWS, Google Cloud, and Microsoft Azure have each built distinct agentic AI platforms reflecting fundamentally different philosophies. Amazon Bedrock takes a managed-service approach where agents are configured rather than coded, with guardrails and multi-agent orchestration built into the platform. Google's Agent Development Kit (ADK) leads with an open-source, framework-agnostic developer experience optimized for Gemini but compatible with any model. Azure AI Foundry Agent Service converges Semantic Kernel and AutoGen into a unified runtime that connects natively to the Microsoft 365 ecosystem.

The right choice depends less on raw feature counts and more on your existing cloud investment, your team's technical profile, and where your enterprise data already lives. A company running its stack on AWS with data in S3 and DynamoDB has a materially different optimal path than one embedded in Microsoft 365 with SharePoint and Teams. This article maps each platform's architecture, strengths, and tradeoffs so you can make that decision with full context. For the latest platform announcements, see the AI News Hub.

Amazon Bedrock is AWS's fully managed service for building generative AI applications. Bedrock Agents extend this with a managed orchestration layer that lets you define agents through the console or API without writing orchestration code yourself. The core mental model: you declare what an agent should do and connect it to the tools and knowledge it needs. Bedrock handles the reasoning loop, prompt management, and execution.

The architecture has four primary building blocks. Action Groups define what an agent can do by connecting to AWS Lambda functions via OpenAPI schemas. When the agent decides via tool calling it needs to call an external system, check a database, or trigger a workflow, it routes through an action group. Knowledge Bases provide the agent's memory of facts via Retrieval Augmented Generation (RAG). You point a knowledge base at documents in S3, and Bedrock handles chunking, embedding, and vector storage with semantic search plus optional reranking. Guardrails enforce safety boundaries. Memory gives agents session persistence and long-term context retention across conversations.

Multi-agent collaboration, now generally available, is where Bedrock's managed approach shows its strength. A supervisor agent orchestrates specialized collaborator agents, each with their own action groups, knowledge bases, and guardrails. Bedrock offers two modes: supervisor mode, where the supervisor analyzes requests, decomposes them into subtasks, and coordinates collaborators; and supervisor with routing mode, which routes simple requests directly to the right collaborator while falling back to full orchestration for complex queries. Each collaborator agent runs in parallel with non-overlapping responsibilities.

Bedrock Guardrails deserves specific attention. The six safeguard policies cover content moderation, topic classification, PII handling, prompt attack detection, and hallucination reduction via Automated Reasoning checks. AWS provides multiple safeguard policies designed to filter harmful content through its Bedrock Guardrails service. PII handling supports three modes: block the content entirely, anonymize it by masking detected PII, or pass it through while returning detection metadata. You can configure guardrails at the agent level, meaning each collaborator in a multi-agent system can have its own safety boundary appropriate to its domain.

Best for: Teams already invested in AWS infrastructure who want a managed, configuration-driven approach. Bedrock's strength is operational simplicity. You trade flexibility for a platform that handles orchestration, memory, and safety without requiring you to build those layers yourself. The deep integration with Lambda, S3, DynamoDB, and Step Functions means agent tools can leverage your existing AWS services directly.

Google's approach to agent infrastructure splits into two complementary layers. The Agent Development Kit (ADK) is an open-source framework for building agents, while Vertex AI Agent Builder provides the managed cloud runtime for deploying them. ADK is designed to make "agent development feel more like software development," and the Python SDK reached its stable 1.0 release in 2025 with Java and Go support following shortly after.

ADK supports three categories of agents. LLM Agents use language models for dynamic routing and decision-making. Workflow Agents provide predictable execution through sequential, parallel, and loop patterns. Custom Agents allow developers to build entirely bespoke implementations. The framework is model-agnostic by design: while optimized for Gemini, ADK works with Claude, Vertex AI hosted LLMs, and open-source models through Ollama, vLLM, and LiteLLM connectors.

What sets Google's platform apart is the Agent-to-Agent (A2A) protocol. This open standard enables agents to communicate and collaborate regardless of which framework or vendor built them. Agents advertise their capabilities via "Agent Cards" (digital business cards) and establish secure, dynamic collaboration. A2A is framework-agnostic by specification: agents built with ADK, LangGraph, CrewAI, or any other framework can interoperate. Version 0.2 of the protocol added stateless interaction support and standardized authentication schemes based on OpenAPI-like patterns.

The deployment story is flexible. Vertex AI Agent Engine provides a fully managed runtime with built-in testing, release management, and global-scale reliability. But you're not locked in: ADK agents can also deploy to Cloud Run containers, Google Kubernetes Engine, or entirely custom infrastructure. Google's ADK documentation demonstrates basic agent creation in under 100 lines of Python, though production deployments require additional infrastructure.

State management received significant attention in recent releases. ADK now supports native failure recovery (restoring agent state automatically), human-in-the-loop pausing at any point in execution, and persistent session memory. Grounding capabilities connect agents to Google Search and Vertex AI Search for real-time information retrieval.

Best for: Developer teams that value framework flexibility and open standards. ADK's model-agnostic design and the A2A protocol make it the strongest choice for organizations building multi-vendor agent ecosystems or planning to avoid lock-in. The Gemini optimization gives a performance edge if you're using Google's models, but the ability to swap in Claude or Llama without rewriting agent logic is a genuine differentiator. Strong fit for teams already on GCP or those building agents that need to interoperate across organizational boundaries.

Microsoft's agent strategy is the broadest of the three hyperscalers, spanning developer SDKs, low-code platforms, and end-user products. Azure AI Foundry Agent Service, now generally available, is the production runtime. The Microsoft Agent Framework is the open-source SDK layer. And Copilot Studio provides the low-code experience for business users. Understanding how these three pieces fit together is essential to evaluating the Azure option.

The Microsoft Agent Framework converges two previously separate projects: Semantic Kernel, Microsoft's enterprise-grade orchestration SDK, and AutoGen, a research-origin multi-agent framework. The result is a single API surface for defining, chaining, and managing both single-agent and multi-agent workflows. Semantic Kernel provides the modular, production-ready architecture (plugins, planners, memory connectors), while AutoGen contributes dynamic orchestration patterns including the Magentic One multi-agent pattern. Production-ready SDKs ship across Python, JavaScript, Java, and .NET.

Foundry Agent Service runs on top of this framework with enterprise-grade additions. Connected Agents enable point-to-point interactions where agents call other agents as tools for specialized tasks. Multi-Agent Workflows coordinate long-running, stateful processes with automated error handling and recovery. The tool ecosystem is deep: over 1,400 Azure Logic Apps workflows are available for agent automation, plus native SharePoint integration, Microsoft Fabric connectors, and Bing Search. Third-party integrations from partners including LexisNexis, Morningstar, and Celonis provide domain-specific capabilities.

The Copilot Studio angle is where Microsoft differentiates most sharply. While AWS and Google focus primarily on developers, Copilot Studio puts agent creation in the hands of business users with a visual, low-code interface. Agents built in Copilot Studio can be published directly to Teams and Microsoft 365 Copilot with one click. For organizations already deep in the Microsoft ecosystem, this removes significant deployment friction. It also means the same agent can be authored visually in Copilot Studio or programmatically via the Agent Framework SDK, and deployed through the same Foundry Agent Service runtime.

Observability is a notable strength. Microsoft contributed OpenTelemetry instrumentation that provides unified tracing across not just their own frameworks but also LangChain, LangGraph, and OpenAI Agents SDK. Combined with Azure Monitor integration and built-in evaluation metrics for tool accuracy and task adherence, the monitoring story is more mature than what AWS or Google currently offer natively.

Best for: Enterprises embedded in the Microsoft ecosystem. If your organization runs on Microsoft 365, SharePoint, and Teams, the native integrations create a path of least resistance that the other platforms cannot replicate. The dual-track approach (Copilot Studio for business users, Agent Framework for developers) also makes Azure the strongest choice for organizations that need both technical and citizen-developer agent creation. The Semantic Kernel + AutoGen convergence gives production-grade multi-agent orchestration with the widest SDK language support across the three platforms.

Feature lists are necessary but insufficient. The table below maps each platform across the dimensions that matter most for enterprise agent deployment. Use it as a reference, not a verdict. The "best" platform depends on context that no comparison table can capture: your existing cloud spend, your team's language preferences, your compliance requirements, and where your data lives.

Choosing a cloud agent platform is a downstream consequence of two upstream decisions: where your data lives and what your team knows. If you're starting from scratch with no cloud commitment, the technical comparison matters most. If you're an enterprise with years of investment in one cloud provider, the switching costs almost certainly outweigh any feature delta between platforms. Here's the decision logic distilled. Teams looking to build or validate cloud platform expertise should explore relevant IT certifications across AWS, Google Cloud, and Azure.

A few patterns cut across all three platforms. Start with a single agent before going multi-agent. Every platform supports multi-agent orchestration, but the complexity jump is significant. Get one agent working reliably with the right tools and guardrails before introducing a supervisor. Guardrails are not optional. All three platforms provide safety mechanisms, but they're only as good as the threat model informing their configuration (track emerging threats on the Security News Hub). Test with production-representative load. Agent behavior under high concurrency is materially different from single-request testing, especially for multi-agent systems where coordination overhead scales non-linearly.

The multi-cloud question for agents is different from the multi-cloud question for compute. With VMs and containers, workloads are reasonably portable. With agents, portability depends on how tightly your agent's tools, knowledge, and orchestration logic are coupled to a specific platform.

Bedrock agents are the most tightly coupled. Action Groups connect to Lambda, Knowledge Bases live in S3, and the orchestration logic runs on Bedrock's managed runtime. Moving a Bedrock agent to another cloud means rewriting tool integrations, migrating knowledge stores, and rebuilding the orchestration layer. This isn't inherently bad; it's the tradeoff for a fully managed experience.

Google ADK offers the most portability by design. As an open-source framework, ADK agents can run on any infrastructure: GCP, AWS, Azure, or on-premises. The A2A protocol extends this to agent-level interoperability. You could theoretically have an ADK-built agent on GCP collaborating with a LangGraph agent on AWS and a Semantic Kernel agent on Azure, all communicating through A2A. The practical reality is more nuanced (authentication, latency, debugging), but the architectural possibility is real.

Azure sits in the middle. The Microsoft Agent Framework (Semantic Kernel + AutoGen) is open-source and runs anywhere. But the value of Azure's agent offering comes from its integrations with Microsoft 365, SharePoint, and Copilot Studio. Those integrations don't travel. An enterprise using Foundry Agent Service for its Teams integration won't easily replicate that on GCP.

The pragmatic recommendation: pick the cloud where your data and team already live, then use open standards at the tool integration layer to preserve optionality. Running agents multi-cloud from day one adds complexity that rarely pays off early. Running tools that are accessible across clouds via MCP or OpenAPI is a more realistic and valuable form of portability.

To figure out exactly which architecture decisions fit your specific context, try our Agent Blueprint Quest. It walks through eight layers of architecture decisions, including cloud platform and deployment, and generates a personalized deployment blueprint based on your constraints.

Agent Observability: The Missing Production Layer

Choosing a cloud platform and framework gets your agent to deployment. Keeping it running reliably requires observability tooling purpose-built for agentic workloads. Traditional APM tools track request latency and error rates. Agent observability tracks reasoning chains, tool call sequences, token costs, and decision quality across multi-step workflows that may span minutes and dozens of LLM calls.

Four platforms lead the agent observability space, each with a distinct positioning:

The practical recommendation: if you're using LangGraph, start with LangSmith for frictionless tracing. If you need vendor-neutral observability or self-hosting, Langfuse is the strongest open-source option. For enterprise scale with dedicated support, evaluate Arize AX. For teams prioritizing evaluation-driven development, Braintrust's CI/CD integration catches regressions before they reach production. Whichever you choose, instrument from day one. Debugging a multi-step agent failure without trace data is like debugging a distributed system without logs.