Agent communication protocols: A2A, ACP, and MCP
Three names come up and only one of them is an agent to agent protocol. A2A (Agent2Agent) is the agent to agent standard, now at v1.0 under the Linux Foundation. MCP (Model Context Protocol) connects an agent to tools and data, not to other agents. ACP is an acronym two different projects used, and one of them no longer exists.
This is a reference page for someone evaluating or implementing. If you just have two coding agents open that can’t see each other, none of this will help you today and you want how do you get AI agents to talk to each other instead. Status here was checked against primary sources in July 2026 and protocol status in this space changes fast, so verify version numbers before you build against them.
The one-paragraph version
| What it connects | Shape | Who runs it | |
|---|---|---|---|
| MCP | agent to tools, data, prompts | client/server, JSON-RPC 2.0 | Agentic AI Foundation (Linux Foundation) |
| A2A | agent to agent, across orgs | peer agents exchanging tasks | Linux Foundation |
| ACP (IBM) | agent to agent | REST | superseded, merged into A2A |
| ACP (Zed) | editor to coding agent | JSON-RPC over stdio | community, github.com/agentclientprotocol |
MCP: agent to tool, not agent to agent
MCP is the one most people have already used and the one most often miscategorised as an agent communication protocol. It isn’t one. It standardises how an LLM application reaches a capability outside itself.
The model is three roles: hosts are the LLM applications that initiate connections, clients are the connectors inside a host, and servers are the things providing capabilities. Messages are JSON-RPC 2.0. Servers can offer three things to clients: resources (context and data), prompts (templated messages and workflows), and tools (functions the model can execute). Clients can offer elicitation back to the server, which is a server-initiated request for more information from the user.
The current specification revision is 2026-07-28. Beyond the base protocol, MCP now defines opt-in extensions negotiated at initialization, including Tasks for long-running asynchronous operations with polling and durable handles, Skills over MCP, and MCP Apps for interactive UI rendered inline.
Governance changed at the end of 2025. Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, announced on 9 December 2025. The AAIF was co-founded by Anthropic, Block, and OpenAI, with MCP joining goose and AGENTS.md as founding projects.
Why people conflate it with agent to agent: because an MCP server can be backed by anything, including another agent. You can wrap agent B in an MCP server and call it from agent A, and it works. But the protocol models B as a tool: a stateless capability you invoke and get a result from. It has no vocabulary for B having its own goals, refusing, asking a clarifying question three turns in, or reporting that it’s blocked. If that’s the relationship you’re modelling, you’re fighting the spec.
The A2A project’s own documentation puts the distinction well: “A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”
A2A: the agent to agent standard
A2A (Agent2Agent) was announced by Google in April 2025 and donated to the Linux Foundation that June. It reached v1.0.0 in March 2026, with v1.0.1 following in May 2026. The Technical Steering Committee has representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow, and the Linux Foundation reported more than 150 supporting organizations at the one-year mark in April 2026. It’s Apache 2.0.
Four pieces are worth knowing.
The Agent Card. Discovery works through a JSON document describing an agent’s identity, skills, and security requirements, published at a well-known URI:
https://{agent-server-domain}/.well-known/agent-card.jsonThat’s the whole discovery story, and it’s deliberately boring: RFC 8615, fetch it over HTTPS, read the skills. There’s also a Get Extended Agent Card method for capabilities an agent only reveals to authenticated callers.
The Task. The unit of work one agent delegates to another. Tasks carry a lifecycle rather than being a single request/response, with states SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED, CANCELED, FAILED, and REJECTED. INPUT_REQUIRED is the state that matters most and the one no tool protocol has: it’s the remote agent saying it can’t continue without something from you. That single state is most of the reason A2A exists separately from MCP.
Three transports. The v1.0 spec defines bindings for JSON-RPC, gRPC, and HTTP+JSON/REST, plus rules for custom bindings. An agent picks what suits it and advertises the choice in its card.
Long-running work. Alongside the eleven core methods (send message, streaming send, get, list, cancel, subscribe, four push-notification config methods, and the extended card fetch) there’s a push notification config, so a task that takes hours can call you back instead of holding a connection open.
If you’re implementing anything cross-organization, where agent A and agent B are run by different companies with different frameworks and separate auth, this is the standard to target. That’s what it was designed for, and after the ACP merge below it’s the only serious candidate.
ACP, problem one: the IBM protocol that no longer exists
If you searched for “ACP agent communication protocol”, this is probably what you found, and the answer you need is that it’s finished.
IBM Research launched the Agent Communication Protocol in March 2025 to power its BeeAI platform, then donated BeeAI and ACP to the Linux Foundation. It was a REST protocol with an OpenAPI specification: GET /agents to discover, POST /runs to execute, Message and MessagePart structures carrying multimodal content, and support for synchronous, streaming, and asynchronous responses.
A2A appeared a month after ACP launched, solving the same problem with overlapping backers. In August 2025 the two teams announced ACP was joining A2A under the Linux Foundation. The ACP repository was archived on 27 August 2025 and is read-only, with a migration guide in its README. BeeAI, which ACP was built for, now runs on A2A.
The practical upshot: don’t implement ACP. If you’re maintaining something that speaks it, the migration target is A2A. Content still describing ACP as a live competitor to A2A predates August 2025, and there’s a lot of it, which is why this section exists.
ACP, problem two: Zed’s Agent Client Protocol
Same acronym, completely different layer, and this one is very much alive.
The Agent Client Protocol was created by Zed Industries and released in August 2025. It standardises communication between code editors and coding agents, so that an agent implements one interface and runs inside any compliant editor, instead of every agent vendor shipping a plugin per IDE or forking VS Code. It’s JSON-RPC over stdio for a local agent running as an editor subprocess, with HTTP and WebSocket for remote agents. Apache licensed, now community governed at github.com/agentclientprotocol, and adopted by JetBrains among others.
Its own documentation notes that it re-uses MCP’s JSON representations where it can, adding custom types for coding-specific UX like displaying diffs. So it sits next to MCP rather than competing with it: MCP gives the agent tools, ACP gives the agent a place to render.
Naming collision aside, this ACP is the one to read if you’re building a coding agent and want it to show up in editors you don’t control. It has nothing to do with agents talking to each other.
How to tell which one you need
The question that resolves almost every case is: what is on the other end of the connection?
- A tool, an API, a database, a document store. Something you invoke that returns a result and has no opinions. That’s MCP.
- An editor or IDE that should host your coding agent. That’s Zed’s Agent Client Protocol.
- Another agent, with its own model, context, and goals, likely run by someone else. That’s A2A. If your protocol needs to express “I’ve started, this will take twenty minutes, and I need one more thing from you before I can finish”, you need task states, and that’s the line MCP doesn’t cross.
- Another agent that is yours, on your machine, in another terminal. None of these. Read the next section.
The gap all three leave
None of these protocols solve the problem most people actually walk in with, which is two coding agents on one laptop that can’t see each other.
A2A assumes agents are network services with stable addresses, published cards, and their own auth. A coding agent in a terminal is a process attached to a pty. It has no address, no card, and no server. You could wrap it in one, and for a long-lived agent service that’s the right move, but for two sessions you opened this morning it’s a lot of scaffolding to deliver one sentence.
The local problem also has a requirement none of these protocols model: the human is in the loop and is frequently the blocker. A coding agent stops on an approval prompt. A2A’s INPUT_REQUIRED comes closest to expressing that, but it describes an agent waiting on its caller, not an agent parked on a permission dialog that a person needs to see. Coordinating local agents is as much about surfacing who is waiting on you as it is about moving messages between them.
That’s a tooling problem rather than a protocol one. The options, from a shared file up to a purpose-built coordination layer, are in how do you get AI agents to talk to each other. crystl approaches it from the tooling side: a CLI that lets one agent read and drive its siblings, and crystl quest, which puts a party of agents in a shared chat you can watch and join. No new wire protocol involved, because for agents on one machine that was never the missing piece.