What is agent-to-agent (A2A)?

Two AI agents, built by different teams on different frameworks, need to collaborate. Neither has read the other’s code. Without a shared protocol, that conversation doesn’t happen.

A2A defines how that conversation starts. Each agent publishes an Agent Card, a JSON document at a well-known URL that describes its capabilities and how to reach it. Another agent fetches the card, reads what the target can do, and sends a structured Task over JSON-RPC 2.0 on HTTP. The target processes the task and returns a result, streaming progress over Server-Sent Events if the job runs long.

What sits on the wire

The Agent Card is the discovery layer. It answers two questions: what can this agent do, and how do I reach it? Each agent self-describes at a known endpoint (/.well-known/agent.json) rather than registering with a central directory. Any agent that wants to delegate work fetches the card first. This is what makes cross-framework collaboration possible without a shared registry.

The Task is the unit of work. It carries a structured payload and a unique ID that tracks it through a defined lifecycle: submitted, working, input-required, completed, or failed. Long-running tasks don’t require polling; agents subscribe to status updates over Server-Sent Events or receive push notifications via webhook. The lifecycle design means A2A can span minutes or hours without either side holding an open connection.

The transport is JSON-RPC 2.0 over HTTP, with OAuth 2.0 for authentication. No novel wire format. The design reuses what enterprise HTTP infrastructure already knows how to route and secure.

A2A and MCP occupy different layers

MCP (Model Context Protocol) defines how an agent connects to external tools: a database, a search service. A2A defines how agents connect to each other. The two protocols are complementary: a routing agent might use A2A to hand a sub-task to a specialist, which then uses MCP to call the tools it needs.

The practical boundary: if the other side is a stateless function that returns structured data, that is an MCP tool boundary. If the other side is an agent with its own reasoning, context, and capabilities, that is an A2A boundary.

Governance and current state

Google published the initial A2A specification in April 2025 with over 50 founding partners including Salesforce, SAP, ServiceNow, and Atlassian. The project was donated to the Linux Foundation in June 2025 under its LF AI & Data umbrella. IBM’s Agent Communication Protocol (ACP), which had been the primary competing standard, merged into the A2A project in August 2025 rather than continuing as a separate specification.

The current release is v1.0.1, published May 28, 2026, maintained under the Apache 2.0 license. SDKs are available in Python, JavaScript, Java, and Go, with native support in LangGraph, AutoGen, CrewAI, Semantic Kernel, and Google’s Agent Development Kit (A2A specification, v1.0.1, May 2026).

The trust problem Agent Cards had to solve

Most descriptions treat the Agent Card as capability advertising, roughly the agent equivalent of API documentation. That frames it too narrowly.

In a multi-agent system where agents discover and delegate to agents they have never interacted with before, the Agent Card is the only signal a receiving agent has about who is on the other end of the connection. Without a way to verify the card, an attacker can publish a forged card at a plausible endpoint and redirect task delegation to a malicious agent.

Signed Agent Cards, added in v1.0, address this directly. The card carries a cryptographic signature tied to the host domain, so a receiving agent can verify it was issued by the actual domain owner before accepting any tasks. That feature, not the transport format or the Task lifecycle, is what moved A2A from a coordination convenience to a production-grade identity layer.

Sources

• A2A Protocol Project. A2A specification, v1.0.1. Linux Foundation, May 28, 2026.