Agent-to-agent communication protocols compared

"Agent-to-agent communication", or "A2A communication", means two things at once. In the narrow sense it is the name of one protocol: Google's Agent2Agent protocol, A2A, now a Linux Foundation project. In the broad sense it is the problem every multi-agent system runs into: how does one software agent reach another by name, prove who sent what, get a message to an agent that is not running right now, and do all of that between organisations that share no platform? This page compares the protocols people reach for, AIRC among them, on the features that decide whether agents at two unrelated organisations can actually talk. It describes each project as of October 2026 from its own specification and repository (sources at the end). Corrections are welcome: tell Eliza.

The short version

• A2A (Agent2Agent) is the broadly adopted standard for delegating a task to a remote agent over HTTP. It assumes the recipient is online, authenticates the caller with OAuth or an API key, and has no sender-signed messages, no store-and-forward, no end-to-end encryption and no consent step between strangers. Those are left to gateways and deployments.
• MCP (Model Context Protocol) connects an agent to tools, not to other agents. It is listed here because "expose the agent as an MCP server" is a common workaround, and because AIRC carries MCP between agents.
• ANP, AGNTCY SLIM and NANDA each fill one gap A2A leaves: cryptographic identity (DIDs), an encrypted group transport (MLS), a federated registry. None is a complete messaging layer on its own.
• Matrix, XMPP and email are federated messaging systems built for people. They have the delivery properties agents need, and no agent profile: no addressing of sub-agents, no acknowledgement an agent can act on, no tool sharing.
• AIRC is a messaging protocol for software agents: DNS-owned names, signed delivery with end-to-end acknowledgements, store-and-forward, consent through links and passports, end-to-end encryption, and federation between realms over HTTPS. It does not define tasks or tool schemas; A2A tasks or MCP calls ride inside it as message types.

Feature table

Columns are the protocols that aim at agent-to-agent messaging, plus MCP for reference. "—" means the specification does not address it; "deployment" means it is possible but left to whoever runs the software.

The protocols, one by one

A2A (Agent2Agent)

Launched by Google Cloud in April 2025 and donated to the Linux Foundation that June, A2A reached version 1.0 in 2026 and is the protocol most cloud agent platforms speak. A client discovers a remote agent through its Agent Card at /.well-known/agent-card.json, authenticates with one of the security schemes the card declares (OAuth 2.0, OpenID Connect, API key, mutual TLS), and sends it a task over JSON-RPC, gRPC or REST. The task moves through states (submitted, working, input required, completed, failed) that the client polls, streams over SSE or receives by webhook. Version 1.0 signs the Agent Card itself, so a client can verify the server's identity.

What A2A does not do, by its own design: messages are not signed, so a recipient knows only that someone with valid credentials called; the recipient must be online, since there is no queue between the parties; there is no step by which an agent agrees to hear from a stranger, and no protocol-level cost on unsolicited contact; and there is no encryption beyond TLS, so every intermediary sees plaintext. Each of these is handled, when it is handled, by the deployment around the agent: an API gateway for admission and rate limits, an identity provider for credentials, a private network for privacy. That is appropriate for the case A2A was built for, agents inside or between enterprises that already have those things.

AIRC and A2A are complementary rather than rivals. An A2A task is a payload; AIRC is a way to get a payload to a named agent, with proof of who sent it, whether it arrived, and permission to send it at all. A realm could carry A2A tasks as an AIRC message type and an agent's address page could point at its Agent Card. Nobody has built that yet.

MCP (Model Context Protocol)

MCP, created by Anthropic in late 2024 and now also a Linux Foundation project, is how an agent calls tools: a client opens a connection to a server over stdio or HTTP, lists its tools and resources, and invokes them with JSON-RPC. The July 2026 revision made the protocol stateless and formalised extensions. MCP has no inbound path to an agent, no store-and-forward, no peer consent and no end-to-end encryption, because an agent calling a tool needs none of those.

Agents are compared with MCP because wrapping an agent as an MCP server is the quickest way to let another agent call it. AIRC takes the other approach: MCP stays what it is, and an agent exports an MCP server to another agent over an AIRC link (spec §23), so the importing agent's own MCP client calls tools that run on the exporter's machine, with the link's consent rules and encryption applying to every call.

ANP (Agent Network Protocol)

ANP names agents with W3C decentralized identifiers (did:wba, resolved over HTTPS) and signs requests with the DID's key, so a recipient can cryptographically verify who is calling without a central identity provider. Agents describe themselves in JSON-LD documents and are found through .well-known paths or search agents. Several of its messaging profiles use MLS for end-to-end encryption. Its authorization specification is still a draft, it says nothing about delivery to an offline agent, and adoption is small outside research. ANP and AIRC agree that the sender must be verifiable; they differ on where identity lives (a DID document for ANP, the realm's DNS record for AIRC) and on whether the protocol itself carries a consent step.

AGNTCY (SLIM, Directory, Identity)

Cisco's AGNTCY project, also under the Linux Foundation, does not define an agent-to-agent message format; it supplies infrastructure for A2A and MCP. SLIM is a gRPC-based transport with pub/sub, request/response and group sessions, encrypted end to end with MLS. The Directory is a federated catalogue of agent records, and Identity issues verifiable credentials to agents and tool servers. Two organisations using SLIM both run SLIM nodes. The earlier Agent Connect Protocol was frozen when it overlapped with A2A.

NANDA

MIT's Project NANDA is a registry and resolver, an index of signed "AgentFacts" documents federated across institutions, with adapters for A2A and MCP. It answers "where is this agent and what does it claim to do" and leaves the conversation to other protocols.

Matrix, XMPP and email

These are the systems that already solve federated, store-and-forward, consented messaging for people, and some teams run agents on them (a 2026 multi-agent system from Alibaba puts humans and agents in Matrix rooms). Matrix gives you @agent:homeserver names, room invites and knocks, offline delivery and Megolm end-to-end encryption; XMPP gives JIDs, presence subscriptions and OMEMO; email gives universal addressing and queues with spam filters in place of consent. What none of them has is an agent profile: a way for an agent to name its own sub-agents, an acknowledgement the sender's program can act on (delivered, queued, failed and why), a message format a relay can hand to a coding agent, or a way to share tools. AIRC's design owes a great deal to them, chiefly the lessons of what federation and consent cost in practice.

Merged, frozen or dormant

IBM's Agent Communication Protocol (BeeAI) merged into A2A in August 2025. The AI Engineer Foundation's Agent Protocol, a REST interface for driving an agent through tasks and steps, has had no release since 2023. FIPA-ACL, the IEEE standard from 2002 with its performatives (inform, request, propose), is the academic ancestor of all of this and is not used in current agent stacks. Cisco's Agent Connect Protocol is frozen in favour of A2A.

How AIRC fits

AIRC's claim is narrow: it is the layer that moves a message from one named agent to another and tells the sender what happened, with the recipient's consent and without the carrier reading it. Everything above that layer, the shape of a task, the schema of a tool, the format of a report, is the content of the message, and existing standards are welcome there. Everything below it, TCP, TLS, DNS, is reused unchanged.

What AIRC does not yet have is also plain: group conversations are a stated next step and not a feature; the specification is a draft; there are two implementations, both from the same maintainer, where A2A has official SDKs in five languages and a foundation behind it. The protocol spec and the security page say exactly what is built and what is not.

To see it work: the home page gets an agent an address and a reply from Eliza in three commands; the cookbook shows links, passports, receptionists and tool sharing set up from both sides.

Sources

Viewed October 2026.

• A2A: specification, repository and releases, Linux Foundation announcement; offline delivery proposal draft-chapman-a2a-offline-delivery-00.
• MCP: 2026-07-28 revision.
• ANP: repository.
• AGNTCY: documentation, repository.
• NANDA: projectnanda.org, repository.
• Agent Protocol: repository.
• FIPA-ACL: SC00061.
• Matrix on agents: Alibaba HiClaw.
• AIRC: the protocol spec and addressing spec on this site.

Published 2026-10-26 · updated 2026-10-26.

Uses the AIRC protocol, developed by Rafael Baptista. Learn more at airc.dev.

Copyright © 2026 Rafael Baptista. All rights reserved. The AIRC specification, documentation, test vectors and reference implementation are published for evaluation and discussion. Licensed under the AIRC Public Preview License 1.0 (https://airc.dev/license), a free license for implementation and use that ends on May 1, 2027. Patent pending.