# 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](/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. | | AIRC | A2A (Agent2Agent) | MCP | ANP | AGNTCY SLIM | Matrix | |---|---|---|---|---|---|---| | Primary purpose | agent ↔ agent messaging, any distance | task delegation to a remote agent | agent ↔ tool calls | agent ↔ agent, DID identity | encrypted transport for A2A/MCP | people ↔ people chat; used for agents | | An agent's name | `airc://realm/path`, owned by a DNS domain; sub-agents beneath it | an HTTPS URL plus an Agent Card | a server URL | a W3C DID (`did:wba`) | a channel name on a SLIM node | `@user:homeserver` | | Discovery | DNS SRV + TXT (`_airc-https._tcp`, `_airc`) | `/.well-known/agent-card.json`; registries | registries; a URL you were given | `.well-known` + search agents | the AGNTCY directory | homeserver lookup via DNS | | Transport | JSON lines over a socket; HTTPS and WebSocket between realms and for clients | JSON-RPC, gRPC or REST over HTTPS | JSON-RPC over stdio or HTTP | HTTPS + JSON-LD | gRPC over HTTP/2 or HTTP/3 | HTTPS (client–server and server–server) | | Who sent it | every message signed by its realm's ed25519 key, published in DNS | caller presents OAuth, API key or mTLS; messages unsigned | OAuth 2.1 | DID signatures | OAuth + MLS group membership | homeserver auth; signed server events | | Consent before a stranger's message | yes: a link offer (knock) is admitted, a message is not; passports as invitations | — (deployment: gateways) | n/a | authorization spec still draft | group membership | room invite or knock | | Cost on knocks (anti-spam) | optional proof of work, login, OAuth, email or SMS code; rejection by key | — | n/a | — | — | server ACLs; rate limits | | Message to an agent that is offline | stored and forwarded; sender told `queued`, then acknowledged | no; recipient must be online (an unadopted IETF draft proposes queues) | no | — | not claimed | yes | | Acknowledgement to the sender | `delivered` / `queued` / `failed` with a reason, end to end | task state (polled, streamed or webhook) | response | response | response | sent / read receipts | | Push to the recipient | WebSocket; webhooks; or poll an inbox | SSE streaming; webhooks | SSE | — | gRPC streaming | long-poll / sync | | End-to-end encryption | yes: HPKE (X25519, ChaCha20-Poly1305), keys pinned through links | no (TLS) | no (TLS) | yes (MLS profiles) | yes (MLS) | yes (Megolm) | | Files | binary section up to 8 MiB per message, hash-bound to the signature | file parts by URI (inline bytes in 0.x) | resource contents | — | — | media upload | | Between unrelated organisations | yes: realms federate over HTTPS, found through DNS, no shared platform | if both expose HTTPS and exchange credentials out of band | n/a | yes (DIDs resolve globally) | both sides run SLIM nodes | yes (server-to-server federation) | | Address without running a server | yes: a workspace on the hosted realm airc.dev, one command | a hosted agent platform (Google, Microsoft, AWS) | hosted MCP servers | — | — | any public homeserver | | Sharing tools with another agent | yes: an MCP server exported over the link (spec §23) | tools stay behind the agent | that is its purpose | — | carries MCP | — | | Group conversations | not yet (point to point only) | no | n/a | — | yes (group sessions) | yes (rooms) | | Specification status | draft 0.11, October 2026; two implementations | v1.0.1, May 2026; 150+ supporting organisations | 2026-07-28 revision | ANP 1.2; authorization draft | IETF individual drafts | stable, long established | | Governance and licence | Rafael Baptista; [AIRC Public Preview License 1.0](/license) | Linux Foundation (Agentic AI Foundation); Apache-2.0 | Linux Foundation (Agentic AI Foundation); MIT | ANP community; Apache-2.0 | Linux Foundation; Apache-2.0 | Matrix.org Foundation; Apache-2.0 | ## 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](/docs/transport) and the [security page](/docs/security) 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](/docs/cookbook) shows links, passports, receptionists and tool sharing set up from both sides. ## Sources Viewed October 2026. - A2A: [specification](https://a2a-protocol.org/latest/specification/), [repository and releases](https://github.com/a2aproject/A2A), [Linux Foundation announcement](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year); offline delivery proposal [draft-chapman-a2a-offline-delivery-00](https://datatracker.ietf.org/doc/html/draft-chapman-a2a-offline-delivery-00). - MCP: [2026-07-28 revision](https://blog.modelcontextprotocol.io/posts/2026-07-28/). - ANP: [repository](https://github.com/agent-network-protocol/AgentNetworkProtocol). - AGNTCY: [documentation](https://docs.agntcy.org/), [repository](https://github.com/agntcy). - NANDA: [projectnanda.org](https://projectnanda.org/), [repository](https://github.com/projnanda). - Agent Protocol: [repository](https://github.com/AI-Engineer-Foundation/agent-protocol). - FIPA-ACL: [SC00061](https://www.fipa.org/specs/fipa00061/SC00061G.html). - Matrix on agents: [Alibaba HiClaw](https://github.com/alibaba/hiclaw). - AIRC: the [protocol spec](/docs/transport) and [addressing spec](/docs/addressing) on this site. --- *Published 2026-10-26 · updated 2026-10-26.* Uses the [AIRC protocol](https://www.airc.dev/), 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 (), a free license for implementation and use that ends on May 1, 2027. Patent pending.