The Agentic Mesh: Google Cloud's Control Plane for Enterprise AI
Enterprise architecture has spent two decades solving the same underlying problem: systems become difficult to scale, govern, and evolve when too much responsibility is concentrated in a single service boundary. That is what drove the shift from monoliths to SOA, to microservices, and to platform engineering. Enterprise AI is now following the same trajectory, and faster than most organisations have been prepared for.
Early generative AI deployments treated the LLM as a monolithic endpoint: a single model responsible for reasoning across multiple domains simultaneously. That works adequately for productivity tooling and conversational assistants. It breaks down quickly once AI systems are operating inside security boundaries, regulated data, and autonomous task execution.
The architectural response is disaggregation: responsibilities distributed across specialised agents, each focused on a narrower enterprise domain:
Figure 1: The disaggregation of enterprise AI into specialised domain agents.
Once systems become distributed, coordination becomes one of the hardest problems to solve well.
How do organisations securely orchestrate specialised AI agents at scale without creating tightly coupled, operationally fragile systems?
For me, the architectural significance here is less about any individual protocol and more about what this shift represents: Enterprise AI is starting to look less like an application feature and more like a platform engineering problem.
What Problem A2A Solves
Traditional integration contracts (REST, gRPC, OpenAPI) assume a predictable interaction model where schemas are predefined, responses are structured, service behaviour is bounded.
Autonomous agents introduce a different set of requirements. An orchestrating agent may need to pass intent, context, confidence levels, and delegation constraints, not just exchange structured data.
This is where A2A becomes architecturally significant rather than just another integration standard.
Originally announced at Google Cloud Next in April 2025 1, Agent2Agent Protocol (A2A) has moved well beyond an emerging specification. As of this year, organisations including Microsoft, AWS, Salesforce, SAP, and ServiceNow have it in production. A2A functions as an interoperability contract for autonomous systems: how agents delegate work, share context, and coordinate without tightly coupling their implementations.
A2A and MCP: Complementary Layers
A2A often gets discussed alongside Anthropic’s Model Context Protocol (MCP) 2, so it is worth being clear on where each one fits. The distinction is straightforward: MCP handles how an individual agent connects to tools and data sources. A2A handles how agents communicate with each other across organisational and platform boundaries.
They are complementary layers, not competing standards. Most serious enterprise multi agent deployments will eventually involve both.
Figure 2: A2A and MCP operating as complementary protocol layers.
Delegation and State
In practice, A2A moves agent interaction beyond simple function calling and towards distributed workflow coordination. A central orchestration layer can delegate a forecasting task to an analytics agent while passing operational constraints, contextual memory references, and governance policies. Without a consistent delegation model, agent integrations quickly become brittle point to point workflows.
State management is the immediate second challenge. Passing full conversational history between agents introduces severe latency and token overhead. Architects should be solving this with shared memory layers, ensuring agents reference context indirectly rather than retransmitting large payloads.
The Agentic Mesh Pattern
As agent ecosystems scale, enterprises need a dedicated control layer for orchestration, identity propagation, policy enforcement, and distributed state management. This is where the Agentic Mesh pattern becomes useful.
Conceptually it resembles a service mesh, adapted for non deterministic workloads. In a traditional service mesh, routing decisions are based on service discovery and traffic policy. In an Agentic Mesh, routing becomes semantic, based on domain expertise, contextual relevance, operational policy, and trust boundaries. The mesh abstracts that complexity away from individual agents, which is critical: agents should not each need to independently solve discovery, identity, policy enforcement, and observability.
Figure 3: Logical routing of user intent through an Agentic Mesh control plane.
What Google announced at Next ‘26 is the clearest signal yet of where this pattern is solidifying at the platform level.
Google’s Control Plane: The Gemini Enterprise Agent Platform
At Google Cloud Next ‘26, Google announced the Gemini Enterprise Agent Platform 3, framed as the evolution of Vertex AI and the foundation layer for the agentic enterprise. What struck me as architecturally significant is not the product itself, but what Google chose to make first class platform capabilities rather than afterthoughts.
The platform ships with dedicated components for Agent Identity, Agent Gateway, Agent Registry, and Agent Observability. These are the exact concerns the Agentic Mesh pattern addresses. Governance, identity, and observability are not features to bolt on after deployment. They are the control plane. That is a meaningful architectural position, and one that separates this from previous generations of AI tooling that left governance as a future consideration.
Figure 4: Core components of the Gemini Enterprise Agent Platform.
Two details from the technical sessions stood out for me. First, Agent Development Kit (ADK) now supports a graph based framework for organising agents into networks of sub agents, giving developers explicit, auditable control over how agents collaborate. Second, Agent Gateway natively understands both A2A and MCP as first class protocols, applying policy enforcement and identity verification consistently across both. That unification at the gateway level is, in my view, one of the more quietly significant architectural decisions Google have made.
The Operational Reality: Identity, Observability, and Policy
Understanding the platform is one thing. Getting it into production is another. Three things trip up almost every team at this stage.
Identity and the Blast Radius
Static service accounts were not designed for dynamic delegation. When a primary orchestrator hands off to a Finance, HR, or Security sub agent, it needs to pass a constrained identity context that limits what that agent can access and execute.
Agent Identity handles this via SPIFFE IDs: cryptographic identity that travels with the delegation chain. Agent Gateway is the enforcement point; it verifies that identity before any cross-agent call is permitted. If a sub agent behaves unexpectedly, its blast radius is bounded by the scope of the identity it carries.
Least privilege identity propagation is not optional. It is the first thing to get right.
Traditional Monitoring Won’t Cut It
Monitoring latency is straightforward. Monitoring reasoning is not.
When a multi agent workflow does fail, engineering teams need to trace prompt variations, intermediate reasoning steps, and delegation confidence scores, not just HTTP 500s. That means AI native observability needs to be designed into the architecture from the start. Conventional APM tooling was built for deterministic systems. It does not know what to do with reasoning steps, token usage, or confidence drift.
Governance Can’t Be Hardcoded
Enterprise governance requirements such as DLP, PII masking and regulatory controls cannot be hardcoded into individual agents. The mesh must inject Policy Enforcement Points into the network path, evaluating sensitive context before it crosses trust boundaries. Agent Gateway is positioned to serve this role in Google’s architecture, enforcing governance policy consistently across both A2A and MCP traffic while working alongside Model Armor to inspect prompt content, block injection attempts, and mask PII before they reach the model.
Figure 5: Dynamic identity propagation and trust boundaries across an Agentic Mesh.
Getting these three foundations right is what determines whether a multi agent system is genuinely production ready or simply impressive in a controlled environment.
Getting the Foundations Right
The transition to multi agent systems is structural, not cyclical. What Google demonstrated at Next ‘26 is that identity, observability, and policy are now first class platform capabilities rather than engineering exercises left to the implementer.
For architects deciding where to start: most workflows still only require a single, well optimised agent. The Agentic Mesh pattern earns its complexity when use cases genuinely need specialised domain reasoning, parallel execution, or strict security isolation. Get the identity and observability foundations in place first. Validate in lower risk workflows before extending into regulated or high stakes processes. The architectural patterns are clear and the platform is ready to build on. Organisations that get the foundations right now will not be retrofitting governance into production systems six months from now.
References
Footnotes
-
Google Developers Blog. Announcing the Agent2Agent Protocol (A2A). April 9, 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ ↩
-
Anthropic. Model Context Protocol (MCP). 2024. https://modelcontextprotocol.io ↩
-
Google Cloud. Introducing Gemini Enterprise Agent Platform. April 22, 2026. https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform ↩