AI Agent Protocols, Explained

The moment AI stops being a single chatbot and becomes *agents*, software that takes actions, calls tools, and hands work to other software, every pair of pieces has to agree on how to talk. Four protocols showed up to settle that question. They are routinely framed as rivals fighting for one crown. Mostly, they are not even on the same board.

Before shared protocols, wiring M agents to N tools or other agents meant roughly M × N bespoke integrations: one adapter per pair, none of it reusable. A shared protocol turns that into M + N: build each side to the standard once, and any compliant agent can reach any compliant tool. It is the move USB-C made for chargers, which is why MCP, the first of these, gets called "USB-C for AI."

The four cover different parts of the problem, on different axes, and increasingly stack on one another. Here is each one on its own terms: what it does, what its diagram shows, and where it fits.

MCP — connecting agents to tools

The Model Context Protocol standardises the link between an AI application and the tools and data it needs. An MCP client, embedded in the host app, opens a stateful JSON-RPC session to an MCP server, which exposes three things: tools (actions the agent can call), resources (data it can read), and prompts (reusable templates).

Read it left to right: the host holds the model and the client, and each MCP server is a thin adapter fronting one external system (a Slack server for Slack, a Git server for GitHub, a filesystem server for local files) translating the client's JSON-RPC calls into that system's native API. One server per system, all spoken to the same way.

Anthropic introduced MCP in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025. Its axis is agent ↔ tools/data, not agent-to-agent, which is why it complements the next two rather than competing with them. It carries a real trust question: a server's tool descriptions flow into the model's context, so a compromised server is a live prompt-injection surface. That makes server trust part of the design, not an afterthought.

A2A — agents talking to agents

Where MCP reaches tools, Agent2Agent (A2A) lets independent agents, built by different vendors, on different frameworks, discover one another and divide work. Each agent publishes an Agent Card at a well-known address, describing its skills and how to authenticate; another agent reads it and delegates a task.

The two sides stay deliberately opaque to each other: they exchange tasks, not internal state or memory, so neither has to reveal how it works. Tasks run over HTTP, and long-running results stream back over Server-Sent Events. A slow agent reports progress instead of blocking the caller.

Google introduced A2A in April 2025 and donated it to the Linux Foundation, where the A2A Project formed in June 2025; IBM's earlier Agent Communication Protocol (ACP) converged into it that August. A2A is the enterprise agent-to-agent standard: cross-vendor, with auth schemes (OAuth 2.0 / OpenID Connect) declared per agent in the Agent Card.

ANP — agents on the open internet

Agent Network Protocol (ANP) tackles the same agent-to-agent problem, but for the open, decentralized internet rather than the enterprise. There is no central broker: each agent carries its own cryptographic identity (a W3C Decentralized Identifier, via the did:wba method) and authenticates peers directly.

ANP is layered, as the diagram shows. At the bottom, identity and end-to-end encryption built on DIDs. In the middle, its most distinctive idea, a meta-protocol layer, where two agents that have never met first negotiate which protocol and data format they will speak before exchanging anything real. On top, an application layer that handles discovery through JSON-LD documents.

ANP is an independent open-source project (v1.0 landed in May 2025), notably not under the Linux Foundation. Its ambition is to be "the HTTP of the agentic web": a public, permissionless layer any agent can join.

SLIM — the secure transport underneath

The first three define what agents say. SLIM (Secure Low-Latency Interactive Messaging) handles how the messages travel. It is less a wire protocol than a secure messaging fabric that sits beneath protocols like A2A and MCP and carries their traffic.

In the diagram, agents connect through gateways to a central SLIM runtime running on gRPC (over HTTP/2 and HTTP/3). The runtime offers several patterns (request/reply, streaming, and publish/subscribe) so it can carry A2A's request/response exchanges or fan one message out to many agents at once. Throughout, MLS (Message Layer Security) keeps payloads encrypted under group keys, so gateways and the runtime relay ciphertext they cannot read. The encryption survives every intermediate hop.

SLIM comes from Cisco's work in the AGNTCY project, which joined the Linux Foundation in July 2025. Because it is a layer below the others, it does not compete with them; it carries them.

Side by side

The takeaway: they stack, they don't compete

The natural question is which protocol "wins." But that assumes a contest that isn't really happening. MCP connects agents to tools; A2A and ANP connect agents to each other; SLIM carries any of it securely underneath. They sit on different axes, and one system can use all four at once.

Picture a single request. You ask your agent to reconcile last month's invoices. It finds a specialist accounting agent by reading its Agent Card and delegates the job as an A2A task, carried over SLIM, MLS-encrypted end to end. The accounting agent needs live figures, so it turns around and acts as an MCP client, calling a server that fronts your database, then streams the result back up the chain. Four protocols, one job, each doing the part it was built for.

Which to reach for follows from the axis: tool and data access → MCP; cross-vendor collaboration inside an enterprise → A2A; federation across the open internet with no central authority → ANP; encrypted transport underneath any of them → SLIM.

One honest caveat to "they don't compete": A2A and ANP do share an axis. Both connect agents to agents; they differ on trust model: A2A leaning on enterprise identity (OAuth / OIDC), ANP on self-owned DIDs over the open internet. Where those worlds meet, the two genuinely overlap.

A last nuance worth keeping straight: three of the four now sit under the Linux Foundation, but by different routes and on different timelines: A2A as its own project (June 2025), SLIM via AGNTCY (July 2025), and MCP most recently via the Agentic AI Foundation (December 2025). ANP remains independent. Three of four standardising under one foundation inside eight months is itself a signal: the plumbing of the agentic web is consolidating, in the open. "Under the Linux Foundation" is not one club with one rulebook; it is a shared instinct that this plumbing should stay open.