Agents in Dialogue Part 3: A2A Protocol - Orchestrating Modern AI Agent Teams

In the previous articles of this series, we first explored the Model Context Protocol (MCP), which standardises how AI agents connect to external tools and data. We then explored Agent Communication Protocols (ACPs), which is used for direct agent-to-agent dialogue. This article focuses on the Agent2Agent (A2A) Protocol, a modern initiative designed to meet this critical demand to enable the orchestration of sophisticated AI agent teams.

Catch up on the series:

Like this series?
We dive deeper into AI-native architecture, agents, and systems thinking every week in our weekly newsletter Waves of Innovation. ---

A2A Protocol: Orchestrating Modern AI Agent Teams

Introducing the A2A Protocol: Google's Open Standard

The Agent2Agent (A2A) protocol is a modern, open standard, prominently initiated and driven by Google, designed to facilitate seamless communication and collaboration among AI agents. Its core objective is to enable these agents—regardless of the underlying frameworks they are built on, the platforms they are hosted on, or the vendors who developed them—to securely discover one another, exchange information, and coordinate their actions effectively. In essence, the A2A protocol aims to provide AI agents with a "common language," allowing them to transcend proprietary boundaries and work together in a cohesive manner.¹

Core Purpose: Seamless Inter-Agent Collaboration

The primary motivation behind the A2A protocol is to remove the communication problems that often exist between different AI agents within an enterprise or across the broader AI ecosystem. It empowers agents to collaborate on complex tasks that necessitate the combined expertise of multiple specialised entities. A key distinction is that A2A focuses on "agent interoperability"—how agents talk to each other, rather than "tool interoperability," which is the principal domain of protocols like MCP. By standardising inter-agent communication, A2A enables the dynamic assembly of multi-agent solutions, where tasks can be flexibly matched to the most suitable agents available.²

Under the Hood: Key Architectural Elements & Design Principles

The A2A protocol is built upon a set of core design principles and architectural concepts that define how agents interact.

Design Principles: The A2A protocol adheres to five fundamental design principles that shape its architecture and capabilities:

Embrace Agentic Capabilities: The protocol is designed to allow agents to collaborate as autonomous peers, leveraging their inherent reasoning and decision-making abilities, even if they do not share memory, tools, or execution plans directly.
Build on Existing Standards: A2A leverages established and widely adopted web standards such as HTTP, JSON-RPC, and Server-Sent Events (SSE), facilitating easier integration with the existing enterprise IT.
Secure by Default: The protocol incorporates security considerations from the outset, including support for authentication and authorisation mechanisms comparable to OpenAPI's authentication schemes.
Support for Long-Running Tasks: A2A is explicitly designed to handle tasks that may not complete in a timely manner. It supports asynchronous operations, background processing, and scenarios that may involve human-in-the-loop interventions over extended periods.
Modality Agnostic: Recognising that agent interactions are not limited to text, A2A is designed to be modality-agnostic. It can support the exchange of various data types, including text, images, audio and video streams, files, and structured data such as forms or UI components.²

Core Concepts & Interaction Flow: The A2A protocol defines several core concepts and a typical interaction flow for agent collaboration:

Actors: The primary actors in A2A interactions are typically a User (who initiates a request), a Client Agent (which formulates and sends a task on behalf of the user or another process), and one or more Remote Agents (which receive and perform the tasks).
Agent Card (/.well-known/agent.json): This is a crucial component for agent discovery. An Agent Card is a machine-readable metadata file, typically published at a well-known URL, that describes a remote agent's capabilities. This includes its name, description, skills, the communication modalities it supports (e.g., text, audio), endpoint URL, and authentication requirements. Client agents use these cards to find suitable remote agents for specific tasks.
A2A Server: An agent that wishes to offer its capabilities to other agents exposes an HTTP endpoint that implements the A2A protocol methods. This server receives requests and manages task execution.
A2A Client: An application or another AI agent that consumes A2A services. It sends requests (such as initiating tasks) to an A2A Server's specified URL.
Task: The Task is the central unit of work in the A2A protocol. A client agent initiates a task by sending a request to a remote agent. Each task is assigned a unique ID and progresses through a defined lifecycle with states such as submitted, working, input-required (if the remote agent needs more information from the client), completed, failed, or canceled. Tasks are typically initiated using methods like tasks/send or tasks/sendSubscribe.
Message: Messages represent the individual communication turns between the client agent (often with role: "user") and the remote agent (with role: "agent") within the context of a task.
Part: Parts are the fundamental content units within Messages or Artifacts. The protocol defines several types of Parts, including TextPart for plain text, FilePart for files (which can be sent inline or via a URI), and DataPart for structured JSON data (e.g., for forms or other structured information exchange).
Artifact: Artifacts represent the immutable outputs generated by the remote agent upon completion or during the execution of a task. These can include generated files, structured data results, or other forms of output.
Streaming (for long-running tasks): For tasks that may take a considerable time to complete, A2A supports streaming of updates. If a server supports the streaming capability, a client can use the tasks/sendSubscribe method. The client then receives Server-Sent Events (SSE) containing TaskStatusUpdateEvent messages (providing real-time progress updates) or TaskArtifactUpdateEvent messages (delivering artifacts as they become available).
Push Notifications: For scenarios where persistent SSE connections may not be ideal, servers supporting push notifications can proactively send task updates to a webhook URL provided by the client. This can be configured via methods like tasks/pushNotification/set.

Typical Flow: A common interaction pattern involves the following steps:

Discovery: The client agent fetches the Agent Card from a remote agent's well-known URL to learn about its capabilities.
Capability Check: The client examines the Agent Card to determine if the remote agent's skills, supported modalities, and authentication requirements are compatible with the task at hand.
Task Initiation/Submission: If compatible, the client agent constructs a task request according to the A2A protocol specifications and sends it to the remote agent's A2A server, using methods like tasks/send (for synchronous-style interaction) or tasks/sendSubscribe (for streaming updates).
Processing & Interaction: The remote agent's server validates the request and begins processing the task. If streaming is used, the server sends SSE events (status updates, intermediate artifacts) as the task progresses. If the task enters an input-required state, the client agent can send subsequent messages with further information using the same Task ID.
Completion & Response Delivery: Once the remote agent completes the task, its A2A server packages the final result (e.g., the final Task object with status completed and any associated Artifacts) and sends it back to the client agent.³

A2A in Action: Common Use Cases

The A2A protocol is designed to enable a wide variety of collaborative AI scenarios:

Complex Workflow Automation: A2A is well-suited for orchestrating workflows that require the expertise of multiple specialised agents. For example, in an IT helpdesk system, a primary agent could receive a user's issue, then use A2A to delegate diagnostic tasks to a hardware specialist agent, software troubleshooting tasks to another, and finally, if needed, a provisioning task to a deployment agent. Similarly, a loan approval process might involve a coordinating agent using A2A to interact with separate agents for risk assessment, compliance checking, and fund disbursement.
Enterprise Application Integration: Agents can collaborate across different enterprise applications. An example from SAP demonstrates a Host Agent on SAP Business Technology Platform (BTP) using A2A to coordinate with remote agents like a Utilities Agent (for time/weather) and an SAP Agent (for enterprise search using Retrieval-Augmented Generation over SAP HANA Cloud).⁵
Multi-Modal Experiences: A2A's modality-agnostic nature allows for rich, interactive experiences. For instance, in a field service scenario, a technician interacting with a wearable device could be assisted by a team of collaborating AI agents: one handling voice input/output, another displaying technical diagrams or video instructions, and a third interacting with backend diagnostic systems, all coordinated via A2A.
Research Compilation and Report Generation: A primary research agent tasked with compiling a market analysis report could use A2A to delegate sub-tasks: one agent for web crawling and data extraction, another for statistical analysis of internal company data, and a third for structuring and drafting the final report.
Dynamic Task Delegation: By using Agent Cards for capability discovery, systems can dynamically match tasks to the most appropriate available agents, rather than relying on hardcoded integrations. This allows for more flexible and adaptive multi-agent systems.

Key Proponents and Ecosystem

The A2A protocol is being driven by Google, which has launched the initiative with support from over 50 industry partners, including major technology vendors and service providers. This broad backing indicates significant interest in establishing a common standard for inter-agent communication. The open nature of the protocol has also encouraged community contributions, with sample implementations and integrations emerging for popular AI frameworks like LlamaIndex, Autogen, and PydanticAI.⁴ Notably, Microsoft has also announced support for A2A within its Semantic Kernel framework, further bolstering its potential for widespread adoption.⁶

The design of the A2A protocol inherently encourages a microservices-like architecture for building AI systems. Individual agents, in this model, function as specialised, independently deployable services that communicate over a standardised network protocol. The way agents expose their capabilities through Agent Cards and accept tasks is analogous to how microservices expose APIs. The emphasis on agents being potentially "opaque" (i.e., their internal workings are not necessarily known to other agents) and possibly originating from different vendors aligns perfectly with the microservice principles of loose coupling and independent development. This architectural style is increasingly seen as critical for constructing complex AI systems that are scalable, resilient, and maintainable over time.

However, while A2A provides the standardised "language" for agent collaboration, the "logistics" of managing interactions in very large-scale agent ecosystems present further considerations. By default, A2A interactions often rely on point-to-point HTTP connections. As the number of agents (N) in a system grows, the potential number of direct connections can increase dramatically (roughly N-squared), potentially leading to a highly complex and brittle communication web. In such scenarios, complementary architectural patterns, like event meshes or message queuing systems (e.g., using Apache Kafka), might be necessary. An event mesh ⁷ or a Kafka-like backbone ⁸ can decouple agents, enable publish/subscribe communication patterns, improve overall system scalability, and provide durable, asynchronous communication. These patterns can address some of the limitations of purely point-to-point A2A communication when deployed at massive scale, effectively enhancing how A2A messages are delivered and managed within a large, dynamic ecosystem, while A2A itself defines what is being communicated.

Weaving the Threads: MCP, ACP (IBM/BeeAI), and A2A (Google) in Concert

Understanding the individual roles of the Model Context Protocol (MCP), the Agent Communication Protocol (ACP) from the BeeAI/IBM initiative, and Google's Agent2Agent (A2A) Protocol is crucial. Their true power and significance emerge when considering how they differ, coexist, and complement each other within the broader landscape of AI agent communication.

Clarifying the Landscape: How These Protocols Differ and Coexist

These protocols, while all concerned with communication in AI systems, serve distinct but sometimes overlapping or complementary functions:

Model Context Protocol (MCP): The primary focus of MCP is to standardise communication between an AI agent (or an AI-powered application) and its external tools, data sources, and resources. It is fundamentally about providing an AI model with the necessary context and capabilities to perform its tasks by interacting with the outside world.
Agent Communication Protocol (ACP - IBM/BeeAI): This protocol, as explored in our second article, also focuses on agent-to-agent communication, leveraging RESTful APIs and HTTP. It aims to provide a simple, interoperable way for agents, particularly within or connectable to the BeeAI ecosystem, to collaborate. It emphasizes simplicity, progressive complexity, and minimal assumptions about agent internals.
Agent2Agent (A2A) Protocol (Google): This modern protocol, the focus of the current article, also targets agent-to-agent communication. Its emphasis is on enabling task delegation, secure collaboration, and interoperability between potentially opaque agents that may originate from diverse platforms and vendors, using mechanisms like Agent Cards for discovery and supporting long-running, multi-modal tasks.

MCP's Foundational Role with Agent-to-Agent Protocols

MCP (for agent-to-tool/resource) and protocols like A2A or the IBM/BeeAI ACP (for agent-to-agent) are not competitors; rather, they are designed to be highly complementary, addressing different layers or aspects of an AI agent's interaction needs.

A common way to delineate their roles is: A2A/ACP are for agents talking to each other, while MCP is for agents talking to their tools and data sources. In a complex multi-agent system, agents might use A2A or ACP to coordinate a high-level plan, negotiate responsibilities, or delegate sub-tasks. Subsequently, each individual agent might then use MCP to interact with specific services, databases, or APIs required to execute its assigned part of the overall plan. An illustrative example is a sophisticated loan processing system. A primary "Loan Orchestration Agent" could use A2A (or ACP if within that ecosystem) to communicate with a "Risk Assessment Agent" and a "Compliance Verification Agent." The Risk Assessment Agent, in turn, might use MCP to connect to a credit scoring API (a tool) and access historical financial data (a resource). Similarly, the Compliance Verification Agent could use MCP to query regulatory databases. The results from these MCP interactions would then be communicated back to the respective agents, and potentially shared or reported to the Loan Orchestration Agent via A2A/ACP. This combination facilitates a powerful, layered architecture. It allows for a clear separation of concerns: agents can operate at a higher level of abstraction when collaborating with peers (using A2A or ACP), while still possessing standardised and efficient access to the granular functionalities and data they need from the external world (via MCP). This modularity is key to building more capable, scalable, and maintainable AI systems.

The following table offers a comparative overview to clearly distinguish the primary roles and characteristics of MCP, the IBM/BeeAI ACP, and Google's A2A Protocol:

Table 2: MCP vs. ACP (IBM/BeeAI) vs. A2A (Google) – Distinct Roles, Powerful Synergy

Feature	Model Context Protocol (MCP)	Agent Communication Protocol (ACP - IBM/BeeAI)¹¹	Agent2Agent (A2A) Protocol (Google)
Primary Focus	Agent-to-Tool/Resource Communication	Agent-to-Agent Communication	Agent-to-Agent Communication
Analogy/Aim	"USB-C port for AI"	Standardized RESTful API for agent interoperability, especially within BeeAI ecosystem	"Common language for AI teams"
Key Function	Standardises how AI agents discover, access, and use external tools & data sources	Enables agents from different frameworks to collaborate via RESTful API, supporting sync/async/streaming	Enables autonomous AI agents to discover (via Agent Cards), communicate, and collaborate on tasks
Developed By (Initiator)	Anthropic¹⁶	IBM Research / BeeAI Community (Linux Foundation project)	Google
Core Interaction Pattern	Client-Server; AI (client) invokes tools/resources on MCP server	RESTful API calls between agents (services)	Peer-to-Peer (conceptually); Client Agent requests tasks from Remote Agent Server
Key Standards Used	JSON-RPC 2.0, HTTP, SSE (for remote)	RESTful HTTP, supports sync/async/streaming. (JSON-RPC over HTTP/WebSockets also mentioned)¹⁴	HTTP, JSON-RPC, Server-Sent Events (SSE), OpenAPI-like auth
Discovery Mechanism	tools/list method within established connection¹⁸	Manifest-based offline discovery	Agent Card (/.well-known/agent.json)
Ecosystem Focus	Connecting AI models to any tool/service	Interoperability within BeeAI and connectable agent frameworks¹³	Broad interoperability across diverse agent platforms and vendors

An Illustrative Scenario: A Complex AI Task in Concert

To vividly demonstrate the practical synergy between these protocols, consider a hypothetical complex task: automated enterprise market analysis and strategy proposal generation.

High-Level Coordination (A2A or ACP): A "Chief Strategy Agent" (CSA) is tasked with producing this report.
- If leveraging the A2A Protocol, the CSA acts as an A2A client, discovers other agents via their Agent Cards, and delegates tasks (e.g., to a "Market Data Collection Agent" (MDCA), "Competitive Sentiment Analysis Agent" (CSAA), etc.) using A2A's task-based methods like tasks/send.
- If operating within an ecosystem using the IBM/BeeAI ACP, the CSA would use ACP's RESTful API calls to interact with other ACP-compliant agents (MDCA, CSAA, etc.), potentially discovering them via their ACP manifests.
Tool and Resource Utilisation (MCP): Regardless of whether A2A or ACP is used for inter-agent coordination, each specialised Analyst Agent (MDCA, CSAA, "Financial Modelling Agent" (FMA)), upon receiving its task, then uses MCP to interact with the necessary external tools and data sources:
- The MDCA might use MCP to connect to financial news APIs, market research databases, and internal sales databases.
- The CSAA could use MCP to connect to social media listening platforms and NLP services.
- The FMA might leverage MCP to access financial data providers and proprietary modelling tools (perhaps via a Python execution server like PydanticAI's²⁰ or a similar MCP-enabled tool).
Information Synthesis and Reporting (A2A/ACP & MCP):
- Analyst Agents report their findings and generated artifacts back to the CSA using the chosen inter-agent protocol (A2A or ACP).
- The CSA then passes these consolidated findings to a "Report Drafting Agent" (RDA) using the same inter-agent protocol.
- The RDA, in turn, might use MCP to access document templating tools or a sophisticated content generation model to structure and write the final market analysis and strategy proposal.
Final Output: The completed report is delivered by the RDA back to the CSA via A2A/ACP, which can then present it to the human user or initiate further actions.

This scenario illustrates how protocols like A2A or the IBM/BeeAI ACP provide the framework for high-level coordination and task delegation among autonomous agents, while MCP empowers those agents with standardised access to the diverse array of tools and data sources required to perform their specialised functions.

The Future is Articulately Autonomous

The development and adoption of protocols like MCP, the IBM/BeeAI ACP, and Google's A2A Protocol are not merely academic exercises or niche technical advancements. They represent critical enablers for the evolution of artificial intelligence from collections of standalone models into sophisticated, integrated, and collaborative ecosystems.⁹ Standardisation in communication is paramount for lowering the barriers to entry for intelligent automation and for fostering the creation of AI-native platforms that are inherently more composable, adaptive, and secure by design.

Impact on Developing More Sophisticated Systems

These communication frameworks are paving the way for the development of true multi-agent systems, where the capabilities of individual agents can be dynamically discovered, composed, and extended to tackle problems of increasing complexity. By enabling agents to collaborate effectively across organisational, platform, and vendor boundaries, these protocols are facilitating more complex and autonomous decision-making processes and task execution sequences.¹²

The widespread adoption of such open and standardised protocols could potentially lead to the emergence of an "AI service economy." In this vision, specialised AI agents could offer their unique capabilities to other agents, much like businesses offer services today. Discovery mechanisms like A2A's Agent Card or ACP's manifest-based discovery function akin to service advertisements. If agents can reliably and securely discover and interact, regardless of origin, it fosters innovation. Concurrently, MCP's standardisation of tool usage simplifies consumption of backend services. This dynamic mirrors how web APIs catalysed the digital service economy. Considerations around billing and cost models for agent interactions within the A2A community hint at this future.²¹

Key Takeaways for Developers and Tech Leaders

For those involved in designing, building, or leading the development of AI systems, several key takeaways emerge:

Understand Distinct Roles: Grasp the complementary roles of MCP (agent-tool/resource) and agent-to-agent protocols like A2A or the IBM/BeeAI ACP when architecting solutions. Each addresses different facets of AI communication.
Embrace Open Standards: Adopting open standards can enhance interoperability, reduce integration overhead, and future-proof systems against a rapidly evolving technological landscape.
Prioritise Security and Clarity: As AI agents gain greater autonomy and the ability to act on behalf of users or organisations, ensuring secure communication channels, robust authentication/authorisation, and clear, unambiguous interaction patterns becomes paramount.
Recognise the Evolutionary Path: The journey towards effective, standardised AI collaboration is continuous, building on past lessons (like those from historical ACPs such as KQML/FIPA ACL) and adapting to modern web architectures and development practices.

Concluding Thought

The Model Context Protocol, along with emerging agent-to-agent standards like the IBM/BeeAI Agent Communication Protocol and Google's Agent2Agent Protocol, are more than just technical specifications. They are fundamental enablers of a future where intelligent agents can communicate, coordinate, and collaborate with unprecedented seamlessness. By providing the common languages and interaction frameworks these agents need, these protocols are instrumental in unlocking new levels of automation, efficiency, and innovation across a multitude of domains. As AI continues its inexorable advance, the ability of its constituent parts to engage in meaningful dialogue will be a defining characteristic of its ultimate impact.

If you found this useful,
We explore topics like agent systems, AI Native architecture, and organizational design every week in Waves of Innovation.
It’s free, in-depth, and written by the same team behind this series.

---

References:

Pydantic Logfire: Now with an MCP Server - Pydantic Blog, https://pydantic.dev/blog/pydantic-logfire-mcp-server
Model Context Protocol Specification - Model Context Protocol GitHub Repository, https://github.com/model-context-protocol/specification
Introducing the Model Context Protocol - Anthropic News, https://www.anthropic.com/news/introducing-the-model-context-protocol
Model Context Protocol - Anthropic Documentation, https://docs.anthropic.com/claude/docs/model-context-protocol
Model Context Protocol (MCP) - Cursor Documentation, https://cursor.sh/docs/mcp
A deep dive into the Model Context Protocol - IBM Developer Blogs, https://developer.ibm.com/blogs/a-deep-dive-into-the-model-context-protocol/
How to Use Model Context Protocol the Right Way - Boomi Blog, https://boomi.com/blog/model-context-protocol-how-to-use/
Azure AI Agent Service - Model Context Protocol (MCP) - Microsoft Learn, https://learn.microsoft.com/en-us/azure/ai-services/openai/agents-mcp
Introduction to Agent Communication Protocol - agentcommunicationprotocol.dev, https://agentcommunicationprotocol.dev/introduction/welcome/
Announcing the Agent Communication Protocol (ACP) - agentcommunicationprotocol.dev Blog, https://agentcommunicationprotocol.dev/blog/announcing-acp/
BeeAI and the Agent Communication Protocol: Towards an open agent ecosystem - IBM Research Blog, https://research.ibm.com/blog/beeai-agent-communication-protocol
BeeAI: The Open Platform for AI Agents - beeai.dev, https://beeai.dev/
Agent Communication Protocol (ACP) - ACP GitHub Repository, https://github.com/agent-com-protocol/acp
acp-python 0.1.0a5 - Python Package Index (PyPI), https://pypi.org/project/acp-python/
@agentcomprotocol/acp-ts - npm, https://www.npmjs.com/package/@agentcomprotocol/acp-ts
Discussion: Stateful Agents and ACP - ACP GitHub Discussions, https://github.com/agent-com-protocol/acp/discussions/12
Welcome to BeeAI: An Open Platform for AI Agents - BeeAI Blog, https://beeai.dev/blog/welcome-to-beeai/
Discussion: Data Encoding in ACP - ACP GitHub Discussions, https://github.com/agent-com-protocol/acp/discussions/10
Discussion: Kubernetes Deployment for ACP Agents - ACP GitHub Discussions, https://github.com/agent-com-protocol/acp/discussions/11
Introducing the Agent2Agent Protocol: An open standard for AI agent interoperability - Google AI Blog, https://ai.googleblog.com/2024/05/agent2agent-protocol-open-standard-ai-agent-interoperability.html
Agent2Agent Protocol Overview - Google Developers, https://developers.google.com/ai/agents/protocols/a2a/overview
Agent2Agent Protocol Developer Guide - Google Developers, https://developers.google.com/ai/agents/protocols/a2a/guide
Semantic Kernel and the Agent2Agent Protocol - Microsoft Dev Blogs (Semantic Kernel), https://devblogs.microsoft.com/semantic-kernel/semantic-kernel-and-the-agent2agent-protocol/
Discussion: Billing API for Agent Services - A2A Protocol GitHub Discussions, https://github.com/google/agent2agent-protocol/discussions/8
What Is an Event Mesh? - Solace, https://solace.com/what-is-an-event-mesh/