AI Agent Orchestration Platforms: AWS vs Google Cloud vs Microsoft

Building an AI agent is becoming relatively easy.

Running hundreds or thousands of AI agents securely inside an enterprise is not.

As organisations move from conversational AI experiments towards production agentic AI, a new infrastructure layer is becoming increasingly important: the AI agent orchestration platform.

An enterprise agent needs more than access to a large language model. It may need memory, tools, authentication, identity, workflow state, secure code execution, human approval, tracing, evaluation, policy enforcement and communication with other agents.

AWS, Google Cloud and Microsoft are all assembling platforms to provide this infrastructure. Their services are converging in some areas, but the architecture, maturity and language differ.

This article sits within my wider Agentic AI reading path, which connects architecture choices to production readiness and governance.

This comparison looks at:

• Amazon Bedrock AgentCore
• Vertex AI Agent Builder and Agent Engine
• Microsoft Foundry Agent Service

The names and release states in this market change quickly. The comparison reflects provider documentation available on 19 September 2026, and access can still vary by region, model and feature.

AI agent framework versus orchestration platform

Before comparing the cloud providers, it is important to separate two concepts.

An AI agent framework helps developers write the logic of an agent. Examples include LangGraph, OpenAI Agents SDK, Google Agent Development Kit, Microsoft Agent Framework, CrewAI and Strands Agents.

An AI agent orchestration platform provides much of the infrastructure needed to operate those agents in production. That can include:

• managed agent runtimes
• session management and persistent memory
• tool gateways
• authentication and agent identity
• multi-agent communication
• security policies
• tracing and observability
• evaluation, scaling and governance

The framework shapes how the agent is programmed. The platform shapes where and how it operates.

That distinction matters because orchestration is not one standard feature. It can mean a supervisor delegating to specialist agents, a deterministic workflow coordinating model calls, a runtime hosting long-running work, or a gateway controlling tool access.

AWS, Google Cloud and Microsoft at a glance

The useful conclusion is not that the platforms are identical. It is that each provider is moving towards infrastructure that can host agents built with more than one framework or model.

Amazon Bedrock AgentCore

AWS describes Amazon Bedrock AgentCore as a set of services for deploying and operating agents built with different frameworks and models.

It is not one monolithic agent builder. Its value is the collection of infrastructure components around agent code.

AgentCore Runtime

AgentCore Runtime provides managed, serverless infrastructure for hosting agent workloads. Developers can bring their own orchestration logic rather than rewriting applications around one AWS-specific abstraction.

That separation is useful. The framework remains responsible for reasoning and control flow, while AWS provides operational infrastructure around it.

AgentCore Memory

AgentCore Memory separates immediate conversational context from information retained across sessions. That makes memory an explicit architectural decision rather than an unbounded transcript attached to a model call.

Enterprises still need to decide what should be remembered, for how long and under whose authority. A managed memory service does not remove the privacy, retention and data-quality questions.

AgentCore Gateway and identity

AgentCore Gateway can expose APIs and Lambda functions as MCP-compatible tools. It provides a controlled route through which agents reach enterprise systems.

Instead of every AI team creating its own integration mechanism, an organisation can establish a governed tool layer with authentication and policy controls. AgentCore Identity complements that layer by helping agents use workload identities and delegated user access.

This does not mean every Bedrock agent automatically supports MCP or every external agent can communicate through A2A. Those capabilities depend on the gateway, framework and integration being configured.

Bedrock Agents and multi-agent collaboration

Amazon Bedrock Agents remains a distinct managed capability for model reasoning, action groups and knowledge bases. Its multi-agent collaboration uses a supervisor agent to delegate to collaborator Bedrock agents.

That is useful, but it is not the same as an unrestricted cross-platform agent network. Teams should distinguish Bedrock's native supervisor pattern from protocol-level interoperability.

Where AWS is strongest

AWS feels particularly infrastructure-led. AgentCore is modular and deliberately framework-neutral. A team can use managed runtime, gateway, memory or observability while retaining control over how its agent reasons.

That is attractive for engineering teams that want architectural control, particularly when their systems and operational practices already sit on AWS.

Google Cloud: Vertex AI Agent Builder and Agent Engine

Google Cloud's naming needs care. Vertex AI Agent Builder is the broader set of development and enterprise capabilities. Agent Engine is the managed runtime for deploying and scaling agents.

Treating those names as interchangeable makes the architecture harder to understand.

Agent Development Kit

Google's open-source Agent Development Kit, or ADK, supports deterministic workflows, dynamic routing and multi-agent composition. Specialist agents can sit beneath a parent agent or transfer control according to defined patterns.

ADK receives the deepest Google integration, but Agent Engine can also host supported third-party frameworks and custom containers. Exact support varies, so framework compatibility should be checked against the current runtime documentation rather than assumed.

Agent Engine, sessions and memory

Agent Engine provides managed deployment, scaling, sessions, memory and observability. Google treats agents as stateful workloads rather than assuming every interaction begins and ends with one HTTP request.

Sessions maintain interactions and temporary state. Memory Bank can retain selected information across sessions. This distinction becomes important as agents develop longer working relationships with users and systems.

MCP and A2A

Google originated the Agent2Agent protocol, now under Linux Foundation governance. A2A addresses agent discovery, task exchange and communication across compatible systems.

MCP solves a different problem. It provides a common way for models and agents to reach tools and context servers. ADK documents MCP tool integration, but support still depends on the agent and runtime configuration.

Google's direction is explicitly agent-native, but protocol support should not be confused with automatic interoperability. An A2A endpoint still needs identity, policy, observability and a clear trust boundary.

Where Google Cloud is strongest

Google's combination of ADK, Agent Engine, sessions, memory and A2A describes a platform designed for ecosystems of specialised agents.

It is especially compelling for teams that want agent-to-agent interoperability to be an early architectural concern, rather than an integration added after individual agents reach production.

Microsoft Foundry Agent Service

Microsoft's approach combines a development framework with a managed service.

Microsoft Agent Framework provides agent and workflow orchestration patterns. Microsoft Foundry Agent Service provides managed infrastructure for building and operating agents.

These are connected, but they are not the same product.

Prompt, hosted and workflow agents

Foundry supports prompt agents as a managed route for declarative agents. Hosted agents run developer-controlled code in managed infrastructure, while workflow agents coordinate multi-step processes.

Microsoft documentation applies different availability labels and limitations to these agent types. Hosted and workflow capabilities should therefore be evaluated as preview services where the current product documentation says so, rather than treating the entire portfolio as generally available.

Agent Framework orchestration

Microsoft Agent Framework provides explicit patterns for sequential and concurrent execution, agent hand-offs, group conversations and manager-led orchestration. Its workflow model supports state, checkpointing, resuming and human approval.

That matters because not every multi-agent problem should use dynamic model planning. A defined workflow can provide clearer control where the process, authority and failure path are already known.

Foundry's connected-agents capability also allows one managed agent to call another. As with AWS, this is a specific delegation mechanism rather than proof of universal cross-platform orchestration.

Identity, tools and MCP

Microsoft's strongest architectural advantage is its connection to the existing enterprise identity ecosystem. Agents can use Microsoft Entra identities and role-based access controls to reach approved resources.

Foundry supports built-in and custom tools, including MCP servers. A2A integration is separate and remains dependent on the relevant service, SDK and release state.

For organisations already invested in Microsoft 365, Azure, Entra and Teams, this can simplify the path from an agent to a governed enterprise workflow.

What is really different?

At first glance, all three platforms appear remarkably similar. They are converging on a common set of layers:

Agent → Model → Memory → Tools → Identity → Policy → Observability

The difference is emphasis.

AWS is modular and infrastructure-led. It suits teams that want to retain framework and model choices while using managed operational components.

Google Cloud has the most explicit focus on agent-native interoperability. ADK and A2A make multi-agent composition and cross-system communication central to the story.

Microsoft connects agent infrastructure closely to enterprise identity, Microsoft 365 and Azure. Agent Framework also provides explicit workflow patterns for processes that need more control than open-ended planning.

None of those strengths removes the need to test a service's exact release state, regional availability and limitations against the intended workload.

MCP and A2A may matter more than cloud selection

Two open protocols are becoming significant:

• MCP, the Model Context Protocol, helps agents access tools and context.
• A2A, the Agent2Agent protocol, helps compatible agents discover capabilities and exchange tasks.

They are complementary, not interchangeable.

This creates an important possibility. An enterprise may eventually operate agents built with different frameworks, running on different infrastructure and using different models, while communicating through common protocols.

Open protocol support reduces some integration friction, but it does not create a trust model. Teams still need to decide which agent can discover another, which tasks it can delegate, what data can cross the boundary and who remains accountable.

Do you need an AI agent orchestration platform?

Not necessarily.

If you are building one relatively simple assistant, a complete orchestration platform may create unnecessary complexity. The argument becomes stronger when you have:

• multiple production agents and development teams
• agents accessing sensitive systems
• persistent memory or long-running workflows
• human approval requirements
• multiple model providers
• regulated data and audit requirements
• agent-to-agent communication

At that point, runtime, identity, governance and observability become architecture problems in their own right.

This is consistent with my broader view that autonomy should be treated as delegated authority, not as a feature to maximise. A platform can provide a runtime and identity. It cannot decide what authority an agent should receive.

My approach to enterprise agentic AI

I would avoid starting an agentic AI project by asking, “Should we use AWS, Google or Microsoft?”

I would start with the architecture:

1. What decisions can the agent make?
2. What systems can it access?
3. What actions can it perform?
4. What information can it remember?
5. When does a human need to approve an action?
6. How will its behaviour be traced and evaluated?
7. How will agents and tools authenticate to each other?
8. Do agents need to communicate across platforms?

Then decide which parts of the stack should be managed services and which should remain application code.

That decision may lead naturally towards AgentCore, Agent Engine or Foundry Agent Service. It may lead to a combination. It may also show that a controlled workflow is enough.

The important principle is to avoid allowing the cloud platform, model or framework to become the architecture itself. Across technology delivery and product development, the enduring work is defining boundaries, ownership, evidence and operational control.

The emerging agentic AI technology stack

I increasingly see enterprise agentic AI settling into distinct layers:

1. Models: Gemini, Claude, OpenAI, Amazon Nova, Llama and others.
2. Agent frameworks: LangGraph, OpenAI Agents SDK, ADK, Microsoft Agent Framework, Strands, CrewAI and others.
3. Agent protocols: MCP for tools and context; A2A for agent communication.
4. Agent infrastructure: runtime, sessions, memory, gateways and identity.
5. Enterprise systems: CRM, ERP, databases, contact centres, APIs and business applications.
6. Governance and observability: security, policies, approvals, tracing, evaluation and audit.

This is why I believe AI agent orchestration platforms will become an important part of enterprise technology architecture.

The competition between AWS, Google Cloud and Microsoft is not simply about who has the best language model. It is about who can provide infrastructure on which organisations can safely allow agents to reason, collaborate and act.

The best platform will still depend on the authority those agents receive, the systems they must reach and the operating model around them.

If you are working through those choices, get in touch to discuss the architecture.