EXPLAINER

A2A (Agent2Agent) Protocol

protocolfreshness: volatilekey claims checked 2026-10-09

A2A is an open protocol for communication between independent AI agents — discovering each other's capabilities, exchanging tasks and returning results — complementing MCP, which connects agents to tools.

Short answer: A2A lets agents built by different teams or vendors collaborate: they advertise capabilities (an "agent card"), delegate tasks, stream updates and return artifacts. MCP connects an agent to tools; A2A connects agents to agents. Details are version-dependent — verify against the current spec.

What is it?

MCP is how an agent plugs into tools and data. A2A is how one agent talks to another agent — possibly built by a different company on a different framework. They publish what they can do, hand tasks to each other and send back results, so agents can cooperate without sharing internals.

Also known as: A2A, Agent2Agent, agent to agent protocol, agent-to-agent communication, agent card, A2A protocol, Google A2A, interoperable agents.

Technical definition

A2A was announced by Google on 9 April 2025 and contributed to the Linux Foundation, which launched the Agent2Agent project on 23 June 2025; the project released its first stable specification, version 1.0.0, in 2026 (time-sensitive). Core concepts as commonly described: an Agent Card (a JSON description of an agent's identity, endpoint, skills and auth requirements, served at a well-known URL — /.well-known/agent-card.json in the current specification); tasks with lifecycle states; messages made of typed parts; artifacts as outputs; and streaming/push updates for long-running work. The current specification separates an abstract data model and operations from protocol bindings, and defines JSON-RPC 2.0, gRPC and HTTP/REST bindings, with Server-Sent Events for streaming. The specification is evolving, so field names, paths and transports must be checked in the current spec.

Entity type: protocol · Freshness class: volatile.

When should I use it?

Consider when independently owned agents must interoperate; for in-process orchestration use your framework's native multi-agent features.

Implementation patterns

  • Publish an agent card describing skills and auth for remote agents.
  • Delegate a long-running task and subscribe to status updates.
  • Wrap an existing framework agent behind an A2A server.
  • Gateway pattern: one orchestrator discovers and routes to specialist agents.

Technologies and frameworks

Commonly associated: A2A SDKs (Python, JavaScript and others), JSON-RPC / HTTP, Server-Sent Events, OAuth/OIDC for authentication. Names are examples of what exists, not recommendations, and projects change quickly.

Practical guide

  1. Check whether you need cross-team/vendor interoperability at all.
  2. Read the current spec and pick SDKs.
  3. Define agent skills and publish a card.
  4. Implement authentication and authorisation.
  5. Add timeouts, logging and result validation.

Common failure modes

  • Treating a remote agent's output as trusted input (see What is Prompt Injection?).
  • Weak authentication between agents.
  • Spec/version mismatch between client and server.
  • Over-engineering a single-team system that a function call would solve.
  • Unbounded delegation loops.

Troubleshooting

  • Client cannot find the agent — Check the well-known card path and version in the current spec.
  • Task hangs — Check task state handling, timeouts and streaming support on both sides.
  • Unexpected actions from a remote agent — Treat results as untrusted; restrict permissions and require confirmation.

Contrasted with

Questions this page answers

  • What is the A2A protocol?
  • What is an agent card?
  • How is A2A different from MCP?
  • Do I need A2A for a multi-agent system?
  • Who maintains A2A?

Typical goals: make agents from different frameworks interoperate; understand how A2A relates to MCP.

Sources and verification

Status: key claims checked on 2026-10-09 against the primary sources listed below; everything else is not independently verified. The claims under "Checked against primary sources" were compared with the linked pages on that date. Pages change, so re-check anything time-sensitive before relying on it.

Checked against primary sources (2026-10-09):

  • A2A was announced by Google on 9 April 2025 (Google Developers Blog).
  • The Linux Foundation announced the Agent2Agent project on 23 June 2025 as an open protocol created by Google, to be vendor neutral under its governance.
  • A Linux Foundation release of 9 April 2026 says the A2A project is hosted by the Linux Foundation, was originally developed by Google, and has more than 150 supporting organisations.
  • The specification repository lists 1.0.0 as the latest released version, defines JSON-RPC 2.0, gRPC and HTTP/REST bindings, and serves the agent card at /.well-known/agent-card.json (read 2026-10-09 in the earlier audit).

Primary sources consulted:

Not independently verified:

  • The 150-organisation figure is the project's own announcement, not independently verified.
  • SDK maturity and per-language availability.
  • Whether the 1.0.0 specification is still the latest release.

Freshness class: volatile — Products, versions, protocols, benchmarks, leaderboards, regulations and dates. Verify against the primary source before relying on specifics; re-review every 3 months.

Time-sensitive claims to verify before relying on them:

  • Governance and hosting of the project (announced by Google; Linux Foundation involvement to be verified).
  • Agent-card path, field names and transport bindings by version.
  • SDK availability and maturity.
  • Industry adoption claims.

Further reading and canonical sources (not all checked):

  • A2A protocol specification and documentation — a2a-protocol.org (verify current canonical location)
  • A2A project repository — github.com/a2aproject/A2A (verify)
  • Google announcement of A2A (April 2025) — locator to be identified