A2A Deep Dive: What the Agent-to-Agent Protocol Actually Does

If MCP is about connecting an agent to tools, A2A is about connecting an agent to other agents. Google’s Agent-to-Agent protocol, now an open standard under the Linux Foundation, addresses a problem that MCP deliberately ignores: how do independently built, independently operated AI agents collaborate without revealing their internal architectures?

This distinction matters. An MCP server is a tool that an agent controls. Another A2A agent is a peer that operates independently.

What A2A provides

The A2A protocol specifies seven core building blocks for inter-agent communication:

Agent Cards. The discovery mechanism. An Agent Card is a JSON document that advertises an agent’s capabilities, supported modalities, authentication requirements, and endpoint URLs. Think of it as a machine-readable business card that enables one agent to determine whether another agent can help with a specific task.

Tasks. The fundamental unit of work. A task has a unique identifier and progresses through a defined lifecycle: submitted → working → input-required → completed (or failed). This lifecycle is central to A2A’s design—it acknowledges that agent work is rarely instantaneous.

Messages. The communication primitive. Messages carry content between agents, tagged with roles (agent or user). Each message contains one or more Parts.

Parts. The content units within messages. A2A defines three types: TextPart for natural language, FilePart for binary content, and DataPart for structured data. This flexibility allows agents to exchange everything from plain text to spreadsheets to JSON payloads.

Artifacts. The tangible outputs of completed work. When a remote agent finishes a task, it returns artifacts—documents, images, data files—that the requesting agent can consume or forward.

Authentication. Unlike MCP, A2A explicitly addresses authentication. Agent Cards specify supported authentication schemes, including API keys, OAuth 2.0, and OpenID Connect. This enables secure cross-organization communication.

Transport. A2A uses JSON-RPC 2.0 over HTTPS. For long-running tasks, it supports Server-Sent Events (SSE) for streaming updates and webhook push notifications for asynchronous completion. Version 0.3 added gRPC support.

What A2A doesn’t provide

Orchestration. A2A enables point-to-point agent communication. It doesn’t specify how to coordinate workflows across multiple agents, manage dependencies between tasks, or handle complex multi-agent choreography.

Discovery at scale. Agent Cards are published by individual agents, but A2A doesn’t define a registry or directory service. Finding available agents in a large enterprise requires infrastructure beyond the protocol.

Trust and reputation. An Agent Card says what an agent claims it can do. There’s no standard mechanism for verifying these claims or building trust scores based on historical performance.

Governance. Rate limiting, cost tracking, audit logging, compliance enforcement—these operational concerns are outside the protocol’s scope. You need to build (or buy) governance infrastructure around A2A.

Error semantics. A2A defines a task failed state, but doesn’t standardize error categories or recovery protocols. The meaning of failure—and what to do about it—is left to implementations.

How A2A compares to MCP

The comparison is less “A2A vs. MCP” and more “A2A and MCP at different layers”:

A practical example: an agent uses MCP to query a product database (tool access). That same agent uses A2A to delegate a pricing analysis to a specialist agent from a different vendor (peer collaboration). The two protocols complement each other.

The Agent Card in practice

Agent Cards are the linchpin of A2A. A well-constructed card includes:

{
  "name": "Financial Analysis Agent",
  "description": "Analyzes financial documents and produces risk assessments",
  "url": "https://agents.example.com/financial-analyst",
  "version": "2.1.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "risk-assessment",
      "name": "Portfolio Risk Assessment",
      "description": "Evaluates investment portfolio risk",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["application/json", "application/pdf"]
    }
  ],
  "authentication": {
    "schemes": ["oauth2"],
    "credentials": "https://agents.example.com/.well-known/oauth"
  }
}

The card tells a requesting agent everything it needs to decide whether this agent is useful and how to interact with it—without revealing the internal architecture, model choices, or tool implementations.

Implementation considerations

Start with well-defined skill boundaries. A2A works best when agents have clear, bounded capabilities. “General purpose assistant” is a poor Agent Card. “Invoice data extractor from PDF documents” is a good one.

Design for the input-required state. A2A’s task lifecycle includes input-required—the remote agent can ask for clarification mid-task. Your client agents need to handle this gracefully, not just fire-and-forget.

Plan for asynchronous completion. Many A2A tasks won’t complete in seconds. Build your architecture around webhook notifications and polling, not synchronous blocking.

Version your Agent Cards. As your agents evolve, their capabilities change. Treat Agent Cards as contracts with the same versioning discipline you apply to APIs.

Monitor the A2A boundary carefully. A2A communication crosses trust boundaries. Every task delegation is a potential security surface. Log everything, validate inputs, and enforce authentication rigorously.

The bigger picture

A2A addresses a real gap in the agentic architecture: how independently built systems collaborate without coupling. As agentic systems mature, the need for standardized inter-agent communication will only grow.

The protocol is young—version 0.3 as of mid-2025—but its foundation on established standards (HTTPS, JSON-RPC, OAuth) and its governance under the Linux Foundation signal serious intent. For organizations building multi-agent systems or planning to expose their agents as services, A2A is worth understanding now and adopting when your architecture demands it.

The key insight: A2A doesn’t replace MCP, orchestration frameworks, or governance layers. It fills the specific gap of peer-to-peer agent communication. Use it for that purpose, and build everything else around it.