A2A

Agent2Agent (A2A) is an open interoperability protocol announced by Google on April 9, 2025, designed to solve a fundamental problem in multi-agent systems: agents built by different vendors on different frameworks cannot natively communicate with each other. Without a shared protocol, an agent built on LangChain cannot delegate a subtask to an agent built on CrewAI or Semantic Kernel. A2A provides the common language that makes cross-framework agent collaboration possible.

The protocol is built on existing web standards - HTTP, Server-Sent Events (SSE), and JSON-RPC 2.0 - rather than introducing new transport infrastructure. This means any system that can make an HTTP request can participate in A2A communication. Google launched it with support from over 50 technology partners including Atlassian, Salesforce, SAP, LangChain, and PayPal. The project was subsequently donated to the Linux Foundation and is maintained as open source under the Apache 2.0 license.

A2A Protocol Specification

The protocol defines seven core components: the A2A client (the agent initiating work), the A2A server (the agent receiving and executing work), Agent Cards (metadata documents), tasks (discrete units of work), messages (communication exchanges), artifacts (outputs), and parts (the content units inside messages and artifacts).

Agent Cards are the foundation of discovery. Each agent publishes a JSON document advertising its name, capabilities, supported modalities, endpoint URL, and authentication requirements. A client agent queries Agent Cards to identify which remote agent is best suited for a given subtask before initiating contact.

Tasks are the central abstraction. Every interaction is framed as a task with a unique identifier and a defined lifecycle. Task states progress through: submitted, working, input-required, completed, and failed. Long-running tasks that take hours or days are supported natively - the remote agent streams status updates back to the client via SSE, or pushes notifications to a client-supplied webhook. Messages carry the actual content of exchanges, composed of typed parts: TextPart for plain text, FilePart for file references, and DataPart for structured JSON. Artifacts represent the tangible outputs a task produces - documents, reports, or structured data.

A2A vs MCP

A2A and Anthropic's Model Context Protocol (MCP) are complementary, not competing. They operate at different layers of the agentic stack and are designed to be used together.

MCP standardizes how an agent connects to tools and external data sources - databases, APIs, file systems, and functions. It is the protocol between an agent and the resources it uses. A2A standardizes how agents communicate with other agents - delegating subtasks, passing context, and coordinating on outcomes. It is the protocol between two agents collaborating on a shared goal.

A practical illustration: an inventory management agent might use MCP to query a database for current stock levels, then use A2A to notify a procurement agent to place a purchase order. MCP handles the agent-to-resource layer. A2A handles the agent-to-agent layer. Neither replaces the other.

A2A Protocol Security

Security in A2A operates at two levels: transport and identity.

At the transport level, all A2A communication occurs over HTTPS, ensuring data confidentiality in transit. This is enforced by the protocol - plain HTTP is not a supported deployment pattern for production use.

At the identity level, A2A adopts the OpenAPI security specification directly. Agents advertise their supported authentication schemes inside their Agent Card, and client agents must authenticate using one of those schemes before any task can be submitted. Supported schemes include API key authentication, OAuth 2.0 token-based flows, and OpenID Connect Discovery for federated enterprise identity. This means existing enterprise identity infrastructure - Active Directory, Okta, Google Workspace - can be used to govern which agents are permitted to delegate to which other agents.

The out-of-process policy engine model, where authorization decisions are made by the remote agent independently of the client, ensures that a compromised client agent cannot escalate its own permissions. The remote agent controls what it will accept and execute.

Version 1.0 of the specification added signed Agent Cards - cryptographically signed metadata documents that allow a client agent to verify the authenticity of a remote agent's advertised capabilities before initiating communication.

A2A Protocol Example

Consider a user asking an orchestrator agent to plan and book a business trip.

First, the orchestrator queries available Agent Cards from a registry. It finds a flights agent, a hotels agent, and an expense policy agent - each advertising their capabilities and authentication requirements in JSON.

The orchestrator authenticates with the flights agent via OAuth 2.0 (as specified in its Agent Card) and submits a task: find flights from Mumbai to Singapore on April 15. The flights agent returns status working via SSE, then completed with an artifact containing structured flight options as a DataPart.

The orchestrator submits a parallel task to the hotels agent with the confirmed travel dates. The hotels agent returns input-required - it needs the employee's hotel tier preference from the expense policy agent. The orchestrator queries the expense policy agent, retrieves the policy as a DataPart artifact, and passes it back to the hotels agent. The hotels agent completes its task and returns hotel options filtered to policy.

The orchestrator assembles both artifacts and presents the complete itinerary to the user. No single agent had visibility into the others' internal logic, memory, or tooling. The entire coordination happened through standardized JSON-RPC messages over HTTPS, with task states making the async flow legible at every step.