Mnemoverse Docs

Appearance

Edward Izgorodin·Published Jun 18, 2026

Agent2Agent (A2A) Protocol: The Open Wire for Agent Interoperability ​

TL;DR

  • A2A (Agent2Agent) is an open protocol enabling communication and interoperability between opaque agentic applications — agents that expose no internal state, memory, or tools.
  • Google launched A2A with 50+ partners in April 2025; the Linux Foundation now governs it as a vendor-neutral project with 100+ participating companies.
  • A2A and the Model Context Protocol (MCP) are complementary: MCP connects agents down to tools and context, while A2A connects agents across to each other.
  • A2A deliberately stays out of the memory layer. Shared persistent memory across agents remains an open problem — one the protocol leaves for complementary solutions.

What A2A Is (and Isn't) ​

A2A (Agent2Agent) is an open protocol for communication and interoperability between opaque agentic applications. It lets agentic applications discover each other, exchange tasks and messages, and coordinate work — without exposing internals. The official A2A repository defines it as "an open protocol enabling communication and interoperability between opaque agentic applications."

That word "opaque" matters. Opaque execution is the core design decision: agents advertise capabilities through a public Agent Card but never reveal their memory, reasoning state, or private tools. The A2A specification makes the boundary explicit — agents collaborate "without needing access to each other's internal state, memory, or tools."

So A2A is not a shared brain for agents. It is a protocol for routing work, messages, and outputs between agents while preserving agent boundaries. That is a useful design point for enterprise systems, multi-vendor workflows, and long-running delegated tasks. It also means A2A does not define, share, or persist memory between agents. This is not a gap; it is a clear boundary line.

Timeline: From Google Cloud Next to the Linux Foundation ​

A2A's public history is short and fast-moving.

  • April 9, 2025: Google announced A2A at Google Cloud Next with over 50 early partners and five design principles (Google Developers Blog). The announcement presented A2A as a complement to MCP, not a replacement.
  • June 23, 2025: Google donated A2A to the Linux Foundation at Open Source Summit North America. The project launched under a vendor-neutral governance model with more than 100 participating companies (Linux Foundation press release). Seed governance includes AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. IBM is a broader supporter but is not listed among the Linux Foundation founding members.

The specification is at version 1.0.0 (A2A spec), under an Apache-2.0 license. Many early blog posts reference v0.x drafts; the current stable version is the authoritative source for primitives and behavior.

A2A is also not the only inter-agent protocol effort. The space is plural and still pre-convergence. Security researchers have formally modeled threats across A2A, MCP, the Agent Network Protocol (ANP), and Agora — showing inter-agent security is far from settled (arXiv:2602.11327).

Core Primitives: Agent Card, Task, Message, Artifact, Part ​

A2A models work around five primitives, all drawn from the official specification:

  • Agent Card: A public JSON document that advertises an agent's identity, capabilities, skills, endpoint, and authentication requirements. It is the discovery mechanism — any agent that wants to collaborate starts by reading another agent's card. It does not expose the agent's hidden state.
  • Task: The fundamental unit of work. Every task carries a unique ID, is stateful, and follows a defined lifecycle (submitted, working, completed, failed, canceled). Long-running tasks are a first-class concern.
  • Message: A single turn in a conversation, assigned a role (user or agent), and containing one or more Parts.
  • Artifact: A structured output produced during a task. An artifact can be a document, image, or any structured data, and it is assembled from Parts.
  • Part: The smallest content unit — text, a file reference, or structured data. Both messages and artifacts are made of Parts, which keeps the protocol modality-agnostic.

A practical reading: Agent Cards advertise capability; Tasks organize work; Messages carry turns; Artifacts carry outputs; Parts carry the content inside messages and artifacts — all without peeking into each other's internals.

The Agent Card is the entry point, so it helps to see one. The following is illustrative, not normative — consult the specification for the authoritative schema:

json
{
  "name": "Portfolio Analyzer Agent",
  "description": "Analyzes investment portfolios and generates risk reports.",
  "endpoints": [
    {
      "protocol": "jsonrpc-http",
      "uri": "https://api.example.com/a2a/v1"
    }
  ],
  "capabilities": [
    {
      "name": "risk_assessment",
      "description": "Calculates Value at Risk (VaR) for a given asset list."
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

Transport: JSON-RPC 2.0, gRPC, and REST ​

A2A originally shipped with a primary binding over JSON-RPC 2.0, HTTP(S), and Server-Sent Events (SSE) for streaming. The Google launch post described it as built on "HTTP, SSE, and JSON-RPC" (Google Developers Blog). Since then, the protocol has expanded to a multi-binding specification that also supports gRPC and HTTP+JSON/REST (A2A specification). Webhook-based push notifications let agents receive task state changes without polling.

The important nuance: A2A should not be described as "JSON-RPC only." That flexibility lets A2A run inside cloud-native infrastructure, on-device, or over existing service meshes, and it fits the protocol's stated support for long-running tasks — some agent work finishes in one request, other work needs streaming progress or a task state that survives beyond a single turn.

Five Design Principles ​

Google's original announcement codified five principles that still guide the protocol (Google Developers Blog):

  1. Embrace agentic capabilities — allow agents to negotiate, reason, and collaborate, not just follow fixed workflows.
  2. Build on existing standards — use HTTP, JSON-RPC, SSE; don't invent new wire formats.
  3. Secure by default — authentication, authorization, and trust are part of the protocol's surface, not afterthoughts.
  4. Support long-running tasks — real agent tasks can take minutes, hours, or days; the protocol must stream progress and survive disconnections.
  5. Modality-agnostic — text, images, audio, and structured data all travel as Parts inside Messages and Artifacts.

These principles position A2A as a pragmatic, standards-anchored protocol for a multi-agent world where agents are heterogeneous and often owned by different organizations.

A2A vs MCP: Complementary, Not Competitors ​

The relationship between A2A and MCP is one of the most common questions architects ask. The official A2A documentation addresses it directly: the two protocols address "distinct but highly complementary needs" (A2A and MCP). It uses an auto-repair-shop analogy: MCP is how the mechanic (the agent) connects to specialized tools, diagnostic computers, and parts catalogs, while A2A is how the shop communicates with external partner agents. Researchers frame the same split as "horizontal and vertical integration standards" for agent systems (arXiv:2505.03864).

DimensionModel Context Protocol (MCP)Agent2Agent (A2A)
Integration axisVertical (agent-to-tool / agent-to-context)Horizontal (agent-to-agent)
Primary purposeConnects an agent down to databases, filesystems, and APIsConnects independent agents across host boundaries
Execution modelTransparent — the agent manipulates the tool directlyOpaque — the caller delegates a task; the target executes it privately
Typical transportLocal stdio, SSE, lightweight bindingsHTTP(S), JSON-RPC 2.0, gRPC, webhooks

In short:

  • MCP connects an agent down to tools, data sources, and context providers.
  • A2A connects an agent across to other agents.

Both are needed. A system that only has MCP has well-equipped but isolated agents. A system that only has A2A has talkative agents with nothing to work with. The framing should not be "A2A vs. MCP" but "A2A + MCP" as a baseline agent stack. For a narrower comparison, see A2A vs MCP.

What A2A Leaves Open: The Memory Gap ​

A2A's opaque execution model is a design choice, not a missing checkbox. Agents talk without sharing state. That means after a task completes — or a session ends — nothing persists between the agents. When Agent A delegates a task to Agent B, Agent B starts with no historical context about prior interactions, user preferences, or cross-session memory unless that context is explicitly serialized into the task's input.

The memory gap has begun to appear in adjacent research. The SAMEP protocol paper, introduced as a memory layer for MCP and A2A, highlights "ephemeral memory limitations preventing effective collaboration and knowledge sharing across sessions and agent boundaries" and positions a dedicated memory layer as a complement that sits beside the protocols rather than replacing them (arXiv:2507.10562). A separate analysis of multi-agent memory consistency finds that context-I/O protocols such as MCP provide a necessary but not sufficient foundation — multi-agent memory consistency itself remains not formally defined (arXiv:2603.10062).

A2A does not forget memory — it deliberately stays out of it, and so does MCP. The two protocols move information between and into agents. Neither defines a persistent substrate that remembers across sessions, agents, and machines — that layer is a complementary need the protocols leave open. A vector database alone is also not the same as durable agent memory; the difference is covered in Mnemoverse is not a vector database. For memory exposed through MCP-shaped interfaces, see Memory MCP.

How to Place A2A in an Agent Architecture ​

A2A's primitives and the memory boundary above translate into a few clear architecture decisions.

Use A2A when the boundary you need to standardize is agent-to-agent communication. The repository defines the protocol for communication and interoperability between opaque agentic applications, and the specification defines the primitives for discovery, tasking, messages, outputs, content parts, streaming, and push notifications.

Use MCP when the boundary you need to standardize is agent-to-tool or agent-to-context access. The official A2A and MCP topic page frames the two as complementary, so a production stack often needs both: an agent might receive a task via A2A, use MCP to query a local database to do the work, and return the result as an A2A Artifact.

Add a memory layer when the system needs durable recall across sessions, agents, or machines. That memory layer should not require agents to expose all internal state to each other — A2A's opaque execution model is clear about that boundary. The design challenge is to preserve agent boundaries while still giving the system a verifiable place to remember. Persistent shared memory is the layer A2A leaves open; a complementary memory API such as Mnemoverse — domain-scoped and per-tenant — can sit alongside protocols like A2A and MCP rather than inside them (multi-tenant platform notes, API overview).

Common questions ​

What is the A2A protocol? ​

A2A (Agent2Agent) is an open protocol enabling communication and interoperability between opaque agentic applications. It lets agents exchange tasks and messages without requiring access to each other's internal state, memory, or tools.

How does A2A differ from MCP? ​

MCP connects an agent down to tools, context, and resources. A2A connects an agent across to other agents. The two protocols are complementary, not competitors, and the official A2A documentation describes them as solving distinct but highly complementary needs.

What are the core A2A primitives? ​

The spec defines five primitives: Agent Card (capability discovery), Task (fundamental work unit with a lifecycle), Message (a turn with one or more Parts), Artifact (output assembled from Parts), and Part (the smallest content unit, such as text or a file reference).

Who created the A2A protocol? ​

Google announced A2A on April 9, 2025, with over 50 initial partners. On June 23, 2025, it was donated to the Linux Foundation as a vendor-neutral project with over 100 participating companies and seed governance from AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.

Is A2A the only agent interoperability protocol? ​

No. A2A is one of several inter-agent protocols. Others include the Agent Network Protocol (ANP), the Agent Communication Protocol (ACP), and Agora. The space is still pre-convergence, and security researchers have modeled threats across several of them.

Does A2A provide shared memory between agents? ​

No, by design. The spec states that agents collaborate without needing access to each other's internal state, memory, or tools. A2A moves tasks and messages between opaque agents; it leaves persistent shared memory as a complementary layer to be solved separately.

Mnemoverse Library — persistent memory for AI agents. By Edward Izgorodin. Last updated 2026-06-18.