AI agents now speak three protocols, and mixing them up is the most common architecture mistake I see. MCP connects an agent to tools. A2A lets agents talk to each other. ACP connects an agent to your editor. They're not competitors — they're the three layers of a stack, and each one was built because the layer below it was already solved.
Here's what each protocol does, where it came from, and how the three fit together in one working setup.
MCP: Agent to Tools
MCP is the oldest of the three and the one you most likely already use. Anthropic open-sourced it in November 2024; OpenAI adopted it in March 2025, Google and Microsoft followed, and in December 2025 it moved to the Linux Foundation as vendor-neutral infrastructure.
The mechanics: MCP servers expose tools, resources and prompts. An MCP client — your agent — discovers what's available at connection time and presents it to the model. JSON-RPC over stdio or HTTP. One protocol, M+N integrations instead of M×N.
The ecosystem is enormous: 97 million-plus monthly SDK downloads by late 2025, servers for everything from databases to browsers to ticketing systems. If you're doing anything with agents, MCP is the floor, not an option. We covered the full story in What Is MCP?.
A2A: Agent to Agent
A2A solves the problem MCP deliberately doesn't: what happens when the work spans multiple agents, maybe on different machines, maybe owned by different teams.
Google announced A2A in April 2025 with 50+ partners, and in June 2025 it was donated to the Linux Foundation — the same neutral-home path MCP took months later.
The core idea is an Agent Card: a JSON document at a well-known URL that describes what an agent can do, what skills it offers and how to authenticate. A client agent fetches the card, decides the remote agent is the right one for the job, and delegates. Tasks run with their own lifecycle states, and the two sides exchange outputs — including streaming — without either side needing to know the other's internals.
The division of labor is clean: MCP is how an agent uses a database. A2A is how your code-review agent hands a finding to the ticketing agent across the network. If you're building multi-agent systems, this is the layer that lets you build the integration once and talk to everyone.
One naming trap worth knowing: Zed's Agent Client Protocol also abbreviates to ACP, and IBM's Agent Communication Protocol merged into A2A in 2025. When a blog post says "ACP" or "A2A," check which one it means — the acronyms collided, the protocols didn't.
ACP: Agent to Editor
Zed's Agent Client Protocol is the newest and, for terminal-agent users, the most immediately useful. It's the LSP idea applied to agents: one standard protocol between editors and agent backends, so N editors and M agents become N+M instead of N×M.
Editor-to-agent communication used to be bespoke — every terminal agent shipped its own integration, every editor hard-wired its own agent. ACP standardizes the contract: the editor sends user input and file state, the agent sends edits, diffs and streaming output back. The whole thing is modeled on LSP, which spent a decade killing the same problem for language servers.
The practical effect: a terminal agent that speaks ACP works in Zed, Neovim and any other editor that implements the client side. You keep your agent — its models, its sessions, its config — and your editor becomes a view onto it, rather than the agent being a captive of the editor's vendor.
Octomind ships an ACP server, so an Octomind session started in your terminal can be driven from Zed or Neovim, with the same session resuming later in the terminal. The session is the source of truth; editors are windows.
How the Layers Stack
Put together, the three slot into one architecture:
Editor (Zed, Neovim)
│ ACP — editor ↔ agent
▼
Your agent (Octomind session)
├── MCP — agent ↔ tools ───▶ Tools (filesystem, search, DB, browser)
└── A2A — agent ↔ agent ───▶ Remote agent (review, ticketing)
│ MCP — their tools
▼
Their tools (their MCP servers)An editor talks to your agent over ACP. Your agent talks to its tools over MCP. When a task outgrows one agent, A2A delegates across the network to another agent, which talks to its tools over its MCP servers.
You don't need all three on day one. MCP alone covers a single agent with tools — that's most projects. ACP matters when you want your agent inside your editor without re-buying a vendor's agent. A2A matters when you're composing systems of agents across boundaries.
But the direction is set: protocols, not bespoke integrations, at every layer. The stack is settling the way networking stacks always do — one open standard per layer, and the integration tax collapsing to near zero.
Get Octomind — one agent, three protocols, every layer.
FAQ
What's the difference between MCP and A2A? MCP connects an AI agent to tools and data — databases, search, filesystems — through standardized servers. A2A connects agents to each other: one agent discovers another via its Agent Card and delegates tasks across the network. MCP is "agent uses a tool"; A2A is "agent hires another agent." Most stacks need MCP first; A2A matters once work spans multiple agents or teams.
What is ACP (Agent Client Protocol)? ACP is Zed's open protocol connecting editors to AI agent backends, modeled on LSP — the protocol that standardized editor-to-language-server communication. It lets any ACP-speaking agent plug into any ACP-speaking editor, so you choose your agent and your editor independently. Watch the acronym collision: IBM's Agent Communication Protocol is a different thing entirely — it merged into A2A in 2025.
Do I need all three protocols? No — adopt by layer. MCP alone handles a single agent using tools, which covers most projects. Add ACP when you want your terminal agent drivable from your editor (Octomind ships an ACP server for exactly this). Add A2A when you're building multi-agent systems that span machines or teams. Each protocol solved a layer, so each one earns its place when you reach that layer.
