Building Multi-Agent Systems: 5 Integration Patterns with A2A and MCP Protocols
Core Question: How can enterprises build scalable, interoperable multi-agent systems using A2A and MCP protocols to break down team, language, and organizational boundaries?
No organization will build every agent it needs from scratch. The real value comes from discovering and using agents built by different teams, in different languages, across different organizations. This is exactly what A2A (Agent-to-Agent Protocol) and MCP (Model Context Protocol) solve—A2A handles agent-to-agent communication, while MCP manages agent-to-tool connections.
At Cloud Next 26, Google Cloud released the infrastructure that makes this integration practical at enterprise scale. This comprehensive guide explores five proven integration patterns for building multi-agent systems, helping you understand how to apply these technologies in real business scenarios.
Image source: Google Cloud Tech
Pattern 1: Agent Card Discovery—Making Agents Visible to Each Other
Core Question: In distributed systems, how can one agent discover the existence of other agents, understand their capabilities, and establish communication?
Before your agent can delegate tasks to another agent, it first needs to know that agent exists, what it can do, and how to communicate with it. This is the foundational challenge of building multi-agent systems.
Agent Cards: The Digital Identity for AI Agents
A2A solves this discovery challenge through Agent Cards. Every A2A-compatible agent publishes a JSON document at a well-known URL that describes its capabilities, authentication requirements, and rate limits. Think of it as an OpenAPI specification, but designed specifically for agent-to-agent interaction rather than traditional client-server communication.
In the Agent Development Kit (ADK), exposing your agent as an A2A server requires just a single configuration. The system automatically generates the Agent Card from your agent’s definition. Consuming a remote agent is equally straightforward through the RemoteA2aAgent component, which handles authentication, data serialization, error handling, and result streaming. From the coordinator’s perspective, a remote agent built by another team in another language feels just like a local agent.
Agent Registry: The Service Mesh for Your Agent Ecosystem
The Agent Registry amplifies this discovery capability. When you register agents in a central registry, other agents across your organization can discover them without knowing specific URLs. The registry becomes the service mesh for your agent ecosystem: a single place to find what capabilities are available, who maintains them, and how to access them.
Real-World Application Scenario:
Imagine you’re a technical lead at a large financial institution. Different teams within your company have developed various agents: the risk management team built a credit assessment agent, the compliance department created a document review agent, and the customer service team developed a customer profiling agent. Without a unified discovery mechanism, each team would need to hardcode the addresses and interface details of other agents, leading to high system coupling and difficult maintenance.
With an Agent Registry, each team simply registers their agent in a central directory, and other agents can dynamically discover and call these services. When the risk management team upgrades their credit assessment model, they only need to update the capability description in the registry—calling parties don’t need any code modifications to benefit from more accurate assessments.
Author’s Reflection:
In real enterprise environments, I’ve found that the importance of agent discovery mechanisms is often underestimated. Many teams focus solely on implementing single functionalities when building agents, neglecting how to make other systems “see” and “understand” their agent. The Agent Card design philosophy reminds me of service discovery mechanisms in early microservices architecture—it’s not glamorous technology, but it’s the cornerstone of building scalable systems. Without a good discovery mechanism, even the most powerful agents remain information silos.
Pattern 2: Delegated Specialization—Letting Specialists Handle What They Do Best
Core Question: When an agent encounters tasks beyond its expertise, how can it delegate across team, language, and framework boundaries?
The most common integration pattern is delegation: your agent encounters a task outside its expertise and hands it off to a specialist agent. This pattern builds on Agent Card discovery but extends it across team and framework boundaries.
Seamless Collaboration Across Boundaries
The specialist agent doesn’t need to be built with ADK. It doesn’t need to be written in the same language. It doesn’t need to be maintained by the same team. It just needs to speak the A2A protocol. This design philosophy aligns with the success principles of microservices architecture: independent deployment, independent scaling, and independent evolution. A2A provides the service contract that makes this possible for agents.
Case Study: Cross-Team Customer Onboarding
Consider a customer onboarding workflow that spans five teams and four languages:
-
Coordinator (your team, using Python) handles overall workflow orchestration -
Identity Verification delegated to the security team’s Go agent -
Credit Assessment delegated to the risk team’s Java agent -
Account Provisioning delegated to the platform team’s Go agent -
Compliance Documentation delegated to the legal team’s Python agent -
Welcome Communication delegated to the marketing team’s TypeScript agent
Image source: Google Cloud Tech
Each specialist is owned by a different team, maintained independently, and deployed on its own schedule. The coordinator doesn’t know or care about internal implementations. It only knows their Agent Card capabilities and the A2A protocol.
The Power of Independent Evolution
When the security team updates their verification agent to support new document types, no changes are needed in the coordinator. When the risk team improves their credit models, the coordinator automatically gets better assessments. Each team iterates independently, and the overall system improves.
Practical Application Scenario:
In an e-commerce order processing scenario, an order coordinator agent needs to handle the complete process from order placement to delivery. It can delegate payment verification to the payment team’s agent, inventory checks to the warehouse team’s agent, logistics安排 to the supply chain team’s agent, and customer notifications to the customer service team’s agent.
When the payment team integrates a new payment channel, they only need to update the payment verification agent—the order coordinator doesn’t need to perceive these changes. When the warehouse team optimizes their inventory algorithm, the entire platform’s inventory check efficiency automatically improves. This decoupling allows each team to focus on their area of expertise and iterate quickly without affecting other teams.
Author’s Reflection:
The delegated specialization pattern made me deeply realize that the value of technical protocols lies not just in connection, but in liberation. The A2A protocol liberates collaboration constraints between teams by standardizing communication interfaces. Each team can freely choose the technology stack best suited for their needs and innovate at their own pace while seamlessly integrating into the overall system. This “loose coupling, high cohesion” design philosophy is the essence of modern distributed systems. I’ve seen too many project delays caused by inconsistent technology stacks—A2A provides an elegant solution to this problem.
Pattern 3: Tool Bridge—Connecting Data and Tools Through MCP
Core Question: How can agents securely and efficiently access various data sources, APIs, and enterprise systems without building custom connectors for each data source?
While A2A connects agents to agents, MCP (Model Context Protocol) connects agents to tools and data. The Tool Bridge pattern uses MCP to give your agents secure access to data sources, APIs, and enterprise systems without building custom connectors for each one.
From Custom Integrations to Standardized Protocols
Without MCP, every data connection requires its own custom integration code. Your agent needs a Python connector for one REST API, a different connector for another database, yet another for a legacy system. Three data sources mean three connectors to build, test, and maintain.
MCP eliminates this complexity by providing a single protocol that any tool can implement.
Rich Ecosystem of Ready-to-Use Tools
Google Cloud’s MCP Marketplace provides more than 60 ready-to-use tools and integrations, including GitHub, Notion, Hugging Face, AgentOps, and Stripe. These tools allow your agent to connect instantly through simple configuration, bypassing the need for lengthy custom development.
For database connectivity specifically, the BigQuery MCP connector connects over 30 different data sources to your agents through a single MCP interface. Apigee API Hub takes this further: if you have existing REST APIs documented in Apigee, you can automatically turn them into agent-accessible tools. Your agents access data through the same governance layer that manages your existing API traffic. Rate limiting, authentication, logging, and access control are all handled by infrastructure you already manage.
Image source: Google Cloud Tech
Unified Interface, Interchangeable Backends
ADK supports MCP natively. When you add an MCP tool to your agent, the agent discovers the tool’s capabilities, invokes it with structured parameters, and receives structured responses. From the agent’s perspective, an MCP tool through Stripe looks the same as an MCP tool through BigQuery. The protocol is the interface. The backend is interchangeable.
Practical Application Scenario:
Consider an intelligent customer service system that needs to access multiple data sources to answer customer questions:
-
Connect to CRM systems via MCP to retrieve customer history -
Query order status through MCP connection to order systems -
Access product information from knowledge bases via MCP -
Track delivery progress through MCP connection to logistics systems
Without MCP, development teams would need to write specialized connectors for each system, handling different authentication methods, data formats, and error handling logic. With MCP, all of this is accomplished through a unified protocol interface. The customer service agent simply calls standardized MCP tools without caring whether the backend is Salesforce, SAP, or a custom-built system.
Author’s Reflection:
MCP’s emergence has shown me the future of enterprise integration. In the past, integrating each new system was a massive undertaking requiring understanding API documentation, handling various edge cases, and writing大量 glue code. MCP encapsulates this complexity at the protocol layer, allowing agent developers to focus on business logic rather than integration details. This “learn once, connect anywhere” philosophy significantly lowers the development barrier for agent applications. I particularly appreciate MCP’s governance integration capability—it doesn’t bypass existing enterprise API management infrastructure but deeply integrates with it, giving enterprises confidence to deploy agent applications at scale.
Pattern 4: Cross-Organization Federation—Breaking Down Enterprise Boundaries
Core Question: How can agents from different organizations collaborate on shared tasks while maintaining各自 governance and security boundaries?
The most ambitious pattern involves agents from different organizations collaborating on shared tasks. This is where A2A’s open protocol design becomes essential, because you can’t assume the other organization uses the same framework, language, or cloud provider.
Agent Gallery: A Validated Partner Ecosystem
The Agent Gallery in Gemini Enterprise makes this collaboration practical. Over 100 validated partner agents from Adobe, ServiceNow, Workday, Salesforce, and others are available directly within the platform. Every partner agent has been validated by Google Cloud for security and interoperability.
Collaboration with Independent Governance
The critical property is that each organization maintains its own governance. Your Agent Gateway policies control what data your agents can share with partner agents, what actions they can take based on the partner’s responses, and what information they can request. The partner agent operates under its own security model, validated by Google Cloud’s integration requirements.
Cross-Organization Payment Workflow Case Study:
Consider a multi-agent payment workflow where your agent needs to coordinate with external merchant agents and financial service agents. Each party maintains its own governance while collaborating on shared transactions through A2A. Your agent doesn’t need to understand how the merchant’s system works internally. It communicates through the A2A protocol, and each side enforces its own security boundaries independently.
Image source: Google Cloud Tech
The same principle applies to any cross-organization integration. Your agent doesn’t need to understand Salesforce’s data model or ServiceNow’s internal architecture. It delegates to the partner agent in Agent Gallery, which is maintained by the partner’s team, validated by Google Cloud, and governed by your Agent Gateway policies. When the partner updates their platform, their agent is updated. Your system benefits without any changes on your end.
Practical Application Scenario:
In a supply chain finance scenario, a core enterprise’s procurement agent needs to collaborate with supplier quotation agents, logistics company transportation agents, and bank financing agents. Each enterprise maintains its own data security and business rules but achieves automated business processes through the A2A protocol.
When the procurement agent initiates a purchase request, the supplier agent automatically returns quotations, the logistics agent calculates shipping costs and timelines, and the bank agent evaluates financing options. The entire process requires no manual intervention, with each participant operating within their own security boundary and exchanging necessary business information through the standardized A2A protocol.
Author’s Reflection:
The cross-organization federation pattern has shown me the future形态 of B2B collaboration. Traditional EDI (Electronic Data Interchange) system integration is complex and costly, often excluding small and medium-sized enterprises. The A2A protocol, through open standards and validation mechanisms, enables organizations of different sizes and technical capabilities to participate equally in collaborative ecosystems. I particularly appreciate this pattern’s respect for governance boundaries—it doesn’t require all participants to adopt unified security policies but allows each organization to maintain autonomy while achieving interoperability. This “harmony in diversity” design philosophy is the wisdom behind building healthy ecosystems.
Pattern 5: Ambient Event Mesh—Continuously Responsive Agent Networks
Core Question: How can you build background agent networks that continuously listen for events, automatically process them, and delegate to specialist agents when needed?
The final pattern combines A2A with event-driven architecture to create a mesh of ambient agents that react to events continuously in the background, without waiting for user requests.
Event-Driven Agent Architecture
Batch and Event-Driven Agents in the Gemini Enterprise Agent Platform connect directly to BigQuery tables and Pub/Sub streams. When you combine this with A2A, you create a network of agents that listen for events, process them, and delegate to specialist agents as needed—all running continuously in the background.
Each agent in the mesh runs independently. When an event arrives, the receiving agent processes it and decides whether to handle it locally, delegate to a specialist via A2A, or escalate to a human via Mission Control. The mesh is self-organizing—adding a new specialist agent (say, a fraud detection specialist) requires only registering it in Agent Registry and updating the routing logic in the relevant ambient agents.
Image source: Google Cloud Tech
Powerful Solution for High Event Volumes
This pattern is particularly powerful for organizations with high event volumes. A content platform processing millions of uploads per day, a financial institution processing millions of transactions, an e-commerce platform processing millions of customer interactions—all can use ambient agent meshes to handle the long tail of events that require intelligent processing.
Observability and Governance
The governance story is critical here. Every agent in the mesh has its own identity via Agent Identity. Every tool access is governed by Agent Gateway. Every interaction is traced through Agent Observability. The mesh is not a black box—it is a fully observable, governed network of specialized agents.
Practical Application Scenario:
In a financial transaction monitoring scenario, an ambient event mesh could work as follows:
-
Transaction Event Agents continuously listen to transaction streams on Pub/Sub -
When anomalous transaction patterns are detected, they automatically delegate to Fraud Detection Specialist Agents for deep analysis -
If more context is needed, the fraud detection agent can call Customer Profiling Agents to retrieve user behavior history -
For high-risk transactions, Notification Agents send alerts to the risk control team -
All decisions and processing are completely recorded through the agent observability system
The entire process requires no manual triggering. The agent mesh runs 24/7, automatically processing massive volumes of transaction events and only escalating when human intervention is truly needed.
Author’s Reflection:
The ambient event mesh pattern made me rethink the very nature of “agents.” Traditionally, we’re accustomed to viewing agents as services that respond to user requests, but event-driven agent meshes show another possibility—agents can act as the “nervous system” of an environment, continuously感知, thinking, and acting. This shift from “passive response” to “active感知” marks the evolution of agent technology from tools to infrastructure. I particularly appreciate this pattern’s emphasis on observability—in complex distributed systems, without observability there is no trust, and without trust there is no scale. Agent identity, gateway governance, and end-to-end tracing—these seemingly “boring” infrastructure components are precisely the keys to building reliable agent systems.
Choosing the Right Integration Pattern
Core Question: When building multi-agent systems, how do you choose the most appropriate integration pattern based on the relationships between agents?
Image source: Google Cloud Tech
When building multi-agent systems, choose your integration pattern based on the relationship between agents:
-
Agent Card Discovery: Best for scenarios requiring dynamic discovery and invocation of other agents -
Delegated Specialization: Ideal for tasks requiring cross-domain expertise collaboration -
Tool Bridge: Perfect for agents needing access to multiple data sources and tools -
Cross-Organization Federation: Essential for collaborating with external organization agents -
Ambient Event Mesh: Optimal for continuously listening and processing events
Getting Started Today
The interoperability stack is available now:
-
A2A Protocol: Supported in ADK across Python, TypeScript, Go, and Java -
MCP: Native support in ADK, managed support for GCP databases -
Agent Gallery: 100+ validated partner agents in Gemini Enterprise -
Native Ecosystem Integrations: Plug-and-play connectors for enterprise systems
The A2A + MCP codelab walks you through building a multi-agent system with cross-language collaboration. ADK samples include multi-agent patterns to help you get started quickly.
Companies building isolated agents will be refactoring in twelve months. Companies building interoperable agent ecosystems will be compounding their advantage every day.
Practical Summary & Implementation Checklist
One-Page Quick Reference
-
Discovery First: Before building agents, plan how to expose capabilities through Agent Cards -
Delegation is King: Don’t try to make one agent do everything—specialization is key -
Standardize Connections: Prioritize MCP tools over custom connectors -
Open Collaboration: Break organizational boundaries through A2A protocol and build ecosystems -
Event-Driven: For high-traffic scenarios, consider the ambient event mesh pattern
Implementation Checklist
-
[ ] Configure Agent Cards for each agent -
[ ] Register agents in Agent Registry -
[ ] Evaluate whether existing data sources have MCP connectors -
[ ] Define Agent Gateway governance policies -
[ ] Configure Agent Identity and observability -
[ ] Select appropriate combination of integration patterns
Frequently Asked Questions (FAQ)
Q1: What’s the main difference between A2A and MCP?
A: A2A handles communication between agents, enabling agents from different teams and languages to call each other. MCP handles connections between agents and tools/data sources, providing a unified tool access interface.
Q2: My team uses Java. Can we call agents built by Python teams?
A: Yes. The A2A protocol supports cross-language communication. As long as both sides follow the A2A protocol, agents built in Java, Python, TypeScript, Go, and other languages can call each other.
Q3: Is Agent Registry mandatory?
A: No, but it’s highly recommended. Without a registry, you need to hardcode other agents’ URLs. With a registry, agents can dynamically discover and invoke other agents, making the system more flexible and easier to maintain.
Q4: Do MCP connectors support my company’s legacy systems?
A: If your legacy system has REST APIs and is documented in Apigee, you can automatically convert them to MCP tools through Apigee API Hub. Otherwise, you’ll need to develop custom MCP connectors.
Q5: How do we ensure data security in cross-organization collaboration?
A: Each organization maintains its own governance boundaries. Through Agent Gateway policies, you can precisely control what data is shared with partner agents, what operations can be performed, and what information can be requested. All interactions are authenticated and authorized.
Q6: What’s the difference between ambient event mesh and traditional message queues?
A: Traditional message queues just pass messages. Agents in an ambient event mesh not only receive events but can also make intelligent decisions: handle locally, delegate to specialists, or escalate to humans. The mesh is self-organizing and can dynamically add new specialist agents.
Q7: How do we monitor and debug multi-agent systems?
A: Through the Agent Observability system, you can trace every agent interaction and view complete call chains. Each agent has an independent identity, and all tool accesses are logged through the gateway, ensuring the system is fully observable.
Q8: Starting small, which pattern should I choose?
A: We recommend starting with Agent Card Discovery and Delegated Specialization. These two patterns are foundational and can help you establish communication mechanisms between agents. As system complexity increases, gradually introduce MCP Tool Bridge and Ambient Event Mesh patterns.
Ready to build interoperable agent systems? Start with these five proven integration patterns and join the growing ecosystem of enterprises leveraging A2A and MCP protocols to create scalable, maintainable, and powerful multi-agent architectures.
