A2A Tutorial: Architecting Robust Multi-Agent Systems
Table of Contents
- Introduction
- Core Concepts and Workflow
- Google A2A vs. MCP: Comparison
- A2A Agent Discovery
- Enterprise Ready
- Agent to Client Updates in A2A:
- Conclusion
google-a2a-protocol
Introduction
A2A (Agent-to-Agent) is a protocol that enables structured communication between autonomous agents. In today's interconnected world, where multiple agents often need to cooperate or delegate tasks, A2A makes it easy to integrate various agents across platforms. By adhering to a standardized method of task exchange, A2A reduces friction between agents, ensuring seamless collaboration.
In this tutorial, we’ll explore how A2A works, why it’s critical for building scalable agent systems, and how you can use it for your own projects.
Core Concepts and Workflow
Core Concepts
The A2A protocol enables seamless communication between independent AI agents. Below are the core concepts central to the A2A framework:
- Agent Card: A metadata file (/well-known/agent.json) describing the agent’s capabilities, skills, endpoints, and authentication requirements. This is used for agent discovery.
- A2A Server: An agent exposing HTTP endpoints that implement A2A methods, handling incoming requests and managing task execution.
- A2A Client: An application or agent consuming A2A services by sending requests (e.g., tasks/send) to the server.
- Task: The primary unit of work. Tasks are initiated by sending a request and progress through different states (e.g., submitted, working, completed).
- Message: Represents interactions between the client (user) and the agent. It contains Parts, which are small data units.
- Part: The smallest unit within a message or artifact. It could be a text, file, or structured data.
- Artifact: Output generated by the agent during task processing, such as a file or structured data.
- Streaming: Long-running tasks can use streaming (tasks/sendSubscribe), sending real-time updates via Server-Sent Events (SSE).
- Push Notifications: Servers can send real-time updates to a client via webhooks, eliminating the need for polling.
Typical Task Flow
- Discovery: The client fetches the agent's card.
- Initiation: The client sends a task request (with unique Task ID).
- Processing: The server processes the task, using either streaming or synchronous responses.
- Interaction: The client sends additional messages if the task requires more input.
- Completion: The task reaches a terminal state (completed, failed, or canceled).
Google A2A vs. MCP: Comparison
A2A (Agent-to-Agent) Protocol
- Purpose: Facilitates direct communication and task exchange between autonomous agents.
- Functionality: Enables agents to send and receive tasks, manage workflows, and collaborate on problem-solving.
- Communication Method: Typically utilizes HTTP-based API calls for task initiation and updates.
- Role: Acts as an intermediary layer for agents to coordinate and delegate tasks.
Model Context Protocol (MCP)
- Purpose: Provides a standardized interface for AI models to access and interact with external data sources and tools.
- Functionality: Allows AI models to retrieve real-time data, perform actions in external systems, and leverage specialized tools beyond their built-in capabilities.
- Communication Method: Operates on a client-server model where AI applications (clients) communicate with MCP servers to access resources, prompts, and tools.
- Role: Enhances AI models' capabilities by enabling them to interact seamlessly with external systems and data repositories.
Summary Comparison( Google A2A vs MCP)
Feature | A2A (Agent-to-Agent) | MCP (Model Context Protocol) |
---|---|---|
Primary Role | External communication between agents. | Internal model execution and task processing. |
Task Handling | Manages task creation, updates, and completion. | Executes complex reasoning, tools, or models. |
Communication Type | HTTP-based requests (synchronous or asynchronous). | Internal processing of agent tasks. |
Discovery | Utilizes mechanisms for agent discovery and interaction. | Does not handle agent discovery; focuses on data access. |
Integration Focus | Agent collaboration and task delegation. | AI model access to external data and tools. |
A2A Agent Discovery
In the A2A protocol, agent discovery is the process of finding an agent and understanding its capabilities, available endpoints, and how it can interact with other agents. There are multiple ways to discover agent cards depending on the environment and security considerations.
Agent Card:
Each agent exposes a public metadata file known as an Agent Card (usually located at /.well-known/agent.json). This card includes the following information:
- Capabilities: Defines what tasks the agent can perform.
- Skills: Describes specialized abilities or features of the agent.
- Endpoint URL: The URL where the agent can be accessed for communication.
- Authentication: Specifies authentication methods required to interact with the agent.
Discovery Methods:
Open Discovery:
Description: In this method, agents host their agent cards at a known URL path, typically https://DOMAIN/.well-known/agent.json. This allows clients to discover agents using DNS resolution to locate the agent's domain and then fetch the agent card via a simple GET request.
- Use Case: Ideal for public discovery of agents where the goal is to reduce the discovery process to simply "find a domain."
Curated Discovery (Registry-Based):
- Description: In enterprise environments, agents may be registered in a curated registry or catalog interface. This allows clients to find agents based on predefined, curated lists that are managed by an administrator. This approach is suitable for private or company-specific agent discovery.
- Use Case: Typically used in controlled environments like organizations, where agents are curated and categorized for specific use cases.
Private Discovery (API-Based):
- Description: In cases where agents are kept private or proprietary, agent cards may be exchanged through custom APIs. This is particularly useful when agents need to be secured or only shared within certain networks.
- Use Case: Suitable for private enterprise applications where agents interact behind authentication controls or within closed ecosystems.
Securing Agent Cards:
Agent cards may contain sensitive information, and it is important to implement proper security measures:
- Authentication and Authorization: In many cases, agent cards may be secured using mutual TLS (mTLS) or other security methods, ensuring that only authenticated and authorized clients can access them.
- Private and Curated Discovery: For registry-based or private discovery methods, authentication is often required to ensure the correct and authorized distribution of agent cards and related artifacts.
Enterprise Ready
The A2A protocol is designed to integrate seamlessly into enterprise environments, adhering to established standards for security, privacy, monitoring, and tracing. The protocol does not aim to invent new security models but instead builds upon existing enterprise infrastructures to ensure that agents and their interactions are secure, scalable, and manageable.
Key Enterprise Features:
Transport Level Security:
- HTTPS: A2A relies on HTTPS using modern TLS ciphers to secure the transport layer. This ensures that all communication between A2A clients and servers is encrypted and protected from man-in-the-middle attacks.
- Digital Certificates: Servers present their identity via digital certificates signed by well-known certificate authorities during the TLS handshake. Clients are expected to verify the server identity when establishing a connection.
Server and Client Identity:
- Server Identity: A2A servers must identify themselves using digital certificates as part of the TLS negotiation.
- Client and User Identity: There is no built-in concept of user or client identifiers within the A2A schema. Authentication materials such as OAuth tokens or API keys are passed through HTTP headers rather than in the A2A payload.
- Multi-identity Federation: A2A currently does not address multi-identity federation directly but allows clients to present multiple identities (e.g., enterprise LDAP for internal systems and SaaS-provider identities for external agents). If additional identities are required for a task, they can be handled outside of A2A, with the necessary credential materials passed as needed.
Authentication and Authorization:
- Client Authentication: A2A servers publish the supported authentication protocols in their Agent Card (e.g., API Keys, OAuth, OIDC). Clients must acquire authentication credentials using the specified protocols and present them in each request.
- Request Authorization: A2A servers are responsible for authorizing requests based on both the user identity and the application identity. Authorization may be handled on two levels:
- Skills: Agents advertise their capabilities in the form of skills. Access to specific skills can be authorized on a per-skill basis, limiting access to only the relevant features (e.g., generateRecipe skill).
- Tools (Actions and Data): Sensitive actions or data may be placed behind tools that are restricted based on the client's identity and the user's privilege level. API Management tools are recommended for managing tool access.
Data Privacy:
- A2A emphasizes data privacy by restricting access to sensitive data through authorization mechanisms, ensuring that only authorized clients and users can access specific tasks or tools.
Tracing and Observability:
- Since A2A communication is built on standard HTTP requests, both clients and servers should utilize existing enterprise tracing and observability tools. This includes adding appropriate instrumentation headers and ensuring that events are logged and reported through standard event queues and logs.
Integration with Existing Enterprise Standards:
- A2A does not require enterprises to adopt new security or management standards. Instead, it integrates seamlessly with existing enterprise tools for authentication, authorization, and monitoring. By adhering to Open Authentication protocols and Open Tracing standards, A2A ensures that enterprises can leverage their existing security infrastructure without needing to reinvent the wheel.
Agent to Client Updates in A2A:
- Agent Discovery & Capabilities:
- The agents have specific capabilities like streaming and push notifications. A client can check if an agent supports these features through an agent card.
- Push Notifications:
- Agents send task updates using two main methods:
- Persistent Connection: Via HTTP + Server-sent events.
- Push Notifications: These send the latest task updates to a specified URL, even if a client hasn't subscribed to the task.
- Agents send task updates using two main methods:
- Task Execution Updates:
- Tasks can be processed with state transitions (e.g., "completed" or "input-required"). Clients and remote agents communicate these updates in both connected and disconnected scenarios.
- Disconnected Scenarios:
- Even when agents are disconnected, they can use push notifications to notify clients about task updates. These updates happen through a NotificationService that authenticates agents and ensures secure communication.
- Setting Task Notifications:
- Clients can configure task push notifications by setting a PushNotificationConfig, which includes a URL and optional authentication parameters.
- Agent Security:
- Agents need to verify the authenticity of the push notification URL to avoid malicious activity. Common methods include sending a challenge request and verifying the response.
- Security mechanisms include the use of asymmetric keys, symmetric keys, OAuth, and Bearer Tokens.
- Notification Receiver Security:
- Notifications received by clients should be verified using security measures like JWTs, JWKS, or symmetric keys to ensure authenticity and avoid malicious tampering.
- Replay Prevention & Key Rotation:
- Replay Prevention: Use timestamps (like iat in JWT) to prevent replay attacks by rejecting events older than a specified time.
- Key Rotation: Agents should implement key rotation to ensure security, allowing both old and new keys to be used for validation.
This system allows agents and clients to interact in both connected and disconnected modes, ensuring secure and reliable task management and communication via notifications.
Conclusion
The A2A (Agent-to-Agent) protocol enables seamless communication and task delegation between autonomous agents. By leveraging agent discovery, secure task management, and real-time notifications, A2A ensures smooth cooperation across platforms. Its integration with enterprise security standards like TLS and OAuth guarantees robust protection for data and task execution. Overall, A2A provides a flexible, scalable, and secure framework for building multi-agent systems that can efficiently collaborate in both connected and disconnected environments.
Frequently Asked Questions
What is A2A (Agent-to-Agent) communication?
A2A is a protocol that enables seamless communication and task exchange between autonomous agents, facilitating agent collaboration and delegation of tasks across systems.
How does A2A handle agent discovery?
A2A uses agent cards, which are metadata files containing an agent’s capabilities, skills, and endpoints. Discovery can happen through open, curated, or private methods depending on the environment.
What are the security features of A2A?
A2A utilizes HTTPS, OAuth, and TLS for secure communication. It also supports authentication and authorization mechanisms to protect data and ensure only authorized clients can access agent capabilities.
What types of updates can an agent provide in A2A?
Agents can provide task updates via streaming (using HTTP + Server-Sent Events) or push notifications, enabling real-time progress tracking.
Can A2A be integrated with enterprise security systems?
Yes, A2A is designed to integrate with existing enterprise security standards, including TLS for transport security, OAuth for authentication, and API management for controlling access to tools and data.
How does A2A handle disconnected agents?
Even if agents are disconnected, they can send updates to clients via push notifications, ensuring task progress is communicated securely and reliably.
References
Background References
- (April 12, 2025). Remote Agent to Client Updates. *Github.io*. Retrieved April 12, 2025 from https://google.github.io/A2A/#/topics/push_notifications.md
- (April 12, 2025). Enterprise Readiness. *Github.io*. Retrieved April 12, 2025 from https://google.github.io/A2A/#/topics/enterprise_ready.md
- (April 12, 2025). Discovering Agent (Card)s. *Github.io*. Retrieved April 12, 2025 from https://google.github.io/A2A/#/topics/agent_discovery.md
- (April 12, 2025). A2A ❤️ MCP. *Github.io*. Retrieved April 12, 2025 from https://google.github.io/A2A/#/topics/a2a_and_mcp.md
- (April 10, 2025). Google A2A. *Github*. Retrieved April 10, 2025 from https://github.com/google/A2A
About the Author
Joseph Horace
Horace is a dedicated software developer with a deep passion for technology and problem-solving. With years of experience in developing robust and scalable applications, Horace specializes in building user-friendly solutions using cutting-edge technologies. His expertise spans across multiple areas of software development, with a focus on delivering high-quality code and seamless user experiences. Horace believes in continuous learning and enjoys sharing insights with the community through contributions and collaborations. When not coding, he enjoys exploring new technologies and staying updated on industry trends.