Skip to content

A2A (Agent-to-Agent Protocol): What is it? ​

An open standard protocol enabling agents to collaborate and delegate tasks over networks

About This Document ​

This document explains A2A's core concepts, key differences from MCP, benefits and challenges, and future outlook. For detailed comparison with sub-agents, also refer to what-is-subagent.md.

For the overall taxonomy of agent terminology (architecture patterns, execution roles, implementation units), see agent-taxonomy.md.

What is A2A? ​

A2A (Agent-to-Agent Protocol) is an open standard protocol that enables different AI agents to communicate and collaborate in peer-to-peer relationships over networks.

Background and Leadership ​

Here is a brief history of A2A's origins and standardization.

  • Google led the effort, announcing A2A in April 2025
  • In June 2025, A2A was donated to the Linux Foundation's Agent2Agent project for vendor-neutral stewardship
  • As of April 2026, over 150 organizations participate in the A2A protocol project (AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow, and others)
  • A2A v1.0 is a stable release, with adoption advancing across multiple cloud platforms
  • Around August 2026, moves to place A2A alongside MCP under the Agentic AI Foundation (AAIF) were reported (confirm governance details at the time of reading)
  • Like MCP, it is positioned as one foundational protocol for agent collaboration

IMPORTANT

A2A is past pure specification work: v1.0 and cloud implementations are in use. That does not mean adoption alone is enough. Design authentication and delegation with Agent Identity.

The Essence of A2A ​

A2A's defining characteristic is enabling agent ↔ agent peer communication:

  • MCP: AI agent ↔ tools/APIs (the agent calls tools)
  • A2A: AI agent ↔ AI agent (either side can request work)

In One Sentence ​

"A protocol allowing different AI agents to request work from each other"

Architectural Model ​

Three-layer structure for agent development:

  • Build with ADK: Construct the agent itself
  • Equip with MCP: Connect tools and APIs
  • Communicate with A2A: Communicate with other agents

Why A2A? ​

Current Challenges ​

As AI agent technology evolves rapidly, companies and organizations develop and operate their own agents. However, there is no standard communication mechanism between these agents.

The Silo Problem:

  • Internal Sales Analysis Agent → wants to query Salesforce AI Agent
  • But there's no standard communication protocol
  • MCP enables "agent ↔ tools" but not "agent ↔ agent"
  • Result: agents operate in isolation, making cross-organization collaboration difficult

Before and After A2A ​

Before A2A:

  • Agent-to-agent communication handled by custom implementations (API integration, etc.)
  • Without standards, each integration requires custom specification negotiation
  • Not scalable

After A2A:

  • Standardized protocol enables agent-to-agent communication
  • Authentication, authorization, and trust models are unified
  • Agents from different organizations can collaborate seamlessly

Communication Flow ​

The diagram below illustrates the basic flow of agents from different organizations communicating via the A2A protocol.

Fundamental Differences from MCP ​

While both A2A and MCP enable "connections," their connection targets are fundamentally different. The comparison table below clarifies the distinctions.

Feature Comparison ​

The following table contrasts MCP and A2A.

AspectMCPA2A
Led byAnthropicGoogle → Linux Foundation
PurposeAgent ↔ ToolsAgent ↔ Agent
Connection TargetMCP servers (you manage)Other agents (including external parties)
Communication ModelClient-driven (agent calls tools)Peer-to-peer (both can request)
Context SharingShareable with parent agentFully isolated (expects opaque parties)
OwnerSelfSelf or others
Trust ModelImplicit trustAuthentication/authorization required

Decision Flowchart: Which Should You Choose? ​

Use the following flowchart to determine the right choice among MCP, A2A, and custom sub-agents.

Core Concepts of A2A ​

Three key concepts are essential in A2A.

1. Agent Card ​

An agent's "self-introduction card" that provides information helping other agents and discovery systems understand what capabilities an agent offers.

Format: JSON

Included Information:

  • Agent name and description
  • Supported Capabilities
  • Authentication method
  • Supported A2A versions
  • Endpoint information

Location: Discoverable via /.well-known/agent.json

2. Task ​

A "unit of work" agents request from each other. Handles both brief interactions and extended processes.

Lifecycle:

  • submitted: Immediately after task receipt
  • working: Processing
  • input-required: Additional information needed
  • completed: Success
  • failed: Failure

Characteristics:

  • Asynchronous execution
  • Long-running task support
  • Polling or callback mechanisms

3. Artifact ​

Data generated as a task execution result. Not limited to text—includes files and structured data.

Supported Formats:

  • Text (plain text, markdown, etc.)
  • Files (PDF, images, etc.)
  • Structured data (JSON, XML, etc.)
  • Multimodal (images, audio anticipated)

Benefits of A2A ​

Adopting A2A provides the following advantages.

✅ Standardized Cross-Organization Collaboration ​

Agents from different organizations can communicate via a standard protocol. This marks a shift from "custom per-company integration" to "standards-based collaboration."

✅ Agent Specialization and Cooperation ​

Each agent can specialize in its domain, while complex tasks benefit from multi-agent collaboration. For example:

  • Sales Agent ← retrieves forecast data from Market Analysis Agent
  • Sales Agent ← retrieves customer info from CRM Agent

✅ Multimodal Support ​

Information exchange isn't limited to text—images, audio, and files enable richer communication.

✅ Asynchronous Task Support ​

Long-running operations like report generation can execute in the background, with results retrieved later.

✅ Vendor Independence ​

As an open standard under Linux Foundation stewardship, there's no vendor lock-in.

Drawbacks and Challenges ​

A2A also comes with challenges that remain to be addressed.

❌ Implementation Complexity ​

Authentication, authorization, and encryption are mandatory—requirements stricter than MCP.

❌ Network Dependency ​

Requires handling network latency, connection dropouts, and other failures. Timeout configuration and retry logic are essential.

❌ Debugging Difficulty ​

Tracing inter-agent communication is complex, making troubleshooting challenging. Logging strategy is critical.

❌ Maturity is Still Low ​

Compared to MCP (released November 2024), A2A is even newer. Implementation patterns and operational best practices remain limited.

❌ Nascent Ecosystem ​

Only a limited number of agents and tools support A2A yet. Broader adoption will take time.

❌ Trust Challenges ​

You cannot fully guarantee the quality or security of agents owned by others. Risks of misuse by malicious agents must be considered.

Choosing Between Sub-agents and A2A ​

For collaboration between agents you manage, use "custom sub-agents." For external agent collaboration including other organizations, use "A2A."

Comparison ​

The following table contrasts custom sub-agents with A2A agents.

DimensionCustom Sub-agentA2A Agent
LocationWithin same processOver the network
OwnerSelfSelf or others
Trust RelationshipFull trustAuthentication/authorization required
ContextPartially shared with parentFully isolated
LifecycleSession-scopedPersistent service

Understanding via Metaphor ​

  • Sub-agents = "In-house specialist department"

    • Located in the same building (process)
    • Under supervisor (parent agent) oversight
    • Fully trustworthy
  • A2A agents = "Outsourced partner / vendor"

    • Located at separate facilities (separate processes)
    • Communicate over networks
    • Relationship based on contracts (authentication/authorization)

Complementary, Not Competing ​

Sub-agents and A2A agents don't compete—they complement each other. Most systems use both:

  • Internal task decomposition → Custom sub-agents
  • External resource utilization → A2A agents

Current Maturity and Future Outlook ​

Timeline (approx. as of August 2026) ​

Key milestones from MCP and A2A to the present. Dates follow public announcements and press; confirm governance names at the time of reading.

  • November 2024: Anthropic releases MCP
  • April 2025: Google announces A2A
  • June 2025: A2A is donated to the Linux Foundation's Agent2Agent project
  • October 2025: OpenID Foundation publishes "Identity Management for Agentic AI" v1.1 (Agent ID systematization)
  • December 2025: Moves such as AGENTS.md contributions into Linux Foundation–related frameworks
  • March–April 2026: A2A v1.0, reports of 150+ supporting organizations, and cloud implementations advance; product announcements such as Microsoft Entra Agent ID and Okta for AI Agents continue
  • Around August 2026: Reports of moving A2A toward the Agentic AI Foundation (AAIF)
  • Design combination: MCP (tool connection) + A2A (agent-to-agent) + Agent ID (identity and delegation) is one stack often seen in production. It is not another name for the five-layer model

Current Status ​

A2A is past pure specification work: a stable release and implementations are advancing. This book covers supporting elements on these pages:

Build with ADK, equip with MCP, communicate with A2A, identify with Agent ID

The original three-layer model (Build / Equip / Communicate) plus Identify is a common 2026 framing. A2A alone cannot handle trust boundaries. For cross-organization traffic, design it together with Agent ID.

Remaining Open Issues ​

A2A has reached GA, but the ecosystem still has unresolved areas:

  • Cross-vendor interoperability — Inter-vendor Agent ID interop is not yet established (OIDC-A, IPSIE, AuthZEN standardization is in progress)
  • Scope attenuation in recursive delegation — Design needed so authority does not balloon across A2A-mediated sub-agent chains (OAuth Token Exchange, Macaroons, etc.)
  • Revocation propagation — Mechanism for revocation in one place to reach all endpoints (Shared Signals Framework, etc.)
  • Authentication for browser-controlling agents — Web Bot Auth draft in progress

Details in Agent Identity / Remaining Issues.

Explore these documents to deepen your A2A understanding:

PurposeDocument
Identification and delegation in A2AAgent Identity
Relation to intra-org Agent TeamsMulti-Agent / Agent Teams
Sub-agent detailswhat-is-subagent.md
Agent terminology organizationAgent Taxonomy
MCP detailswhat-is-mcp.md
Overall architectureII.1 Five layers
About Skillswhat-is-skills.md

Sources ​

Last Updated: August 2026 Status: Governance wording corrected; claims softened; distinguished from the five-layer model

Released under the MIT License.