MCP vs A2A vs ACP: The AI Agent Protocol Stack Explained (2026)

By mid-2026, most production multi-agent systems are built on some combination of three named protocols: Model Context Protocol (MCP), Agent2Agent (A2A), and Agent Communication Protocol (ACP). Engineers new to the space often assume these are three competing standards fighting for the same job. They are not — MCP and A2A solve genuinely different problems, and ACP is no longer a separate, independently maintained track at all.

This guide explains what each protocol actually does, clears up the ACP situation (it merged into A2A under the Linux Foundation in August 2025), and shows how to diagram a system that combines a vertical agent-to-tool protocol with a horizontal agent-to-agent protocol — which is the shape almost every real multi-agent architecture takes in 2026.

Vertical vs. horizontal: the two problems these protocols solve

Every protocol in this space addresses one of two directions of communication in an agentic system:

• Vertical (agent → tool/data): How does a single agent call a database, an API, a file system, or a SaaS product from inside its own reasoning loop? This is the problem MCP solves.
• Horizontal (agent → agent): How does one autonomous agent discover, negotiate with, and delegate a task to a different agent — one that may run on a different framework, in a different organization, or behind a different vendor's API? This is the problem A2A solves, and the problem ACP was originally built to solve before it converged with A2A.

A useful mental model: MCP is the protocol inside an agent's own head — how it reaches out to its tools. A2A is the protocol between agents' heads — how one agent's reasoning loop hands work to another's. A well-diagrammed multi-agent system should make this boundary visually obvious.

Model Context Protocol (MCP): the agent-to-tool layer

MCP was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external tools, databases, and context sources through a consistent client/server interface — MCP hosts, MCP clients, and MCP servers exchanging JSON-RPC 2.0 messages over stdio (for local tool servers) or Streamable HTTP (for remote ones). Adoption since then has been unusually fast: MCP is now supported across most major model providers and agent frameworks, and enterprise teams commonly run dozens of MCP servers per organization to expose internal systems to their agents.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI — moving MCP from a single-vendor project to neutrally governed shared infrastructure, comparable in intent to how HTTP or TCP/IP are not owned by any one company.

In an architecture diagram, MCP shows up as the connection between an individual agent and its tool belt: the search index it queries, the internal CRM it reads and writes, the code execution sandbox it calls. See our dedicated MCP architecture diagram guide for the full breakdown of hosts, clients, servers, and transports.

Agent2Agent (A2A): the agent-to-agent layer

A2A was announced by Google in April 2025 to solve a problem MCP does not address: how does an agent built with one framework call on an agent built with a completely different framework, owned by a different team or company, without either side needing to know the other's internals? An A2A agent publishes a JSON Agent Card describing its capabilities, and callers submit Tasks over JSON-RPC 2.0 via HTTPS, with status updates streamed back over Server-Sent Events.

Google donated A2A to the Linux Foundation in June 2025, and steering participants now include AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. By 2026 the protocol had reached v1.0, adding signed Agent Cards for authenticity verification and an Agent Payments (AP2) extension for agent-initiated transactions, with over 150 supporting organizations. For the full protocol anatomy, see our A2A protocol architecture guide.

Agent Communication Protocol (ACP): merged into A2A, not a rival to it

ACP was launched by IBM Research in March 2025 to power the open-source BeeAI platform, taking a deliberately REST-native approach: agent tasks are mapped onto plain HTTP verbs (POST to create a task, GET to check status, and so on) and the whole interface is described in OpenAPI, so any standard HTTP client can talk to an ACP agent without a specialized SDK.

That design lived on its own track for about five months. In August 2025, IBM's ACP officially merged with A2A under the Linux Foundation's LF AI & Data umbrella — the ACP team wound down independent development and contributed its work into A2A, and BeeAI itself moved to build directly on A2A going forward. If you see ACP referenced in older diagrams, docs, or vendor slide decks, treat it as a historical name for capability that now lives inside A2A, not as a third, separately maintained option you need to choose between. (It is also worth not confusing IBM's ACP with the similarly abbreviated "Agent Connect Protocol" work from the Cisco-led AGNTCY collective — a related but distinct Linux Foundation effort whose schema work has since fed into the merged A2A spec.)

Practically, this means new architectures should be diagrammed with A2A as the horizontal protocol — not ACP. If you are documenting a legacy BeeAI deployment that predates the merger, it is fine to label the connection "ACP (pre-2025.08, since merged into A2A)" so reviewers understand the lineage without assuming it is still a maintained, independent standard.

Which protocol for which layer in your diagram

A single agent in a production system will typically speak both protocols at once, just for different neighbors:

• Down, to its own tools: MCP — the agent calls its vector database, its internal ticketing API, its code interpreter, or a file system through MCP servers it trusts and has been configured to use.
• Sideways, to peer agents: A2A — the agent discovers a peer agent's Agent Card and delegates a sub-task to it, whether that peer runs in the same repo, a different team's cluster, or a different company's cloud entirely.

A concrete example: an orchestrator agent receives a customer request, uses MCP to query its own knowledge base and CRM directly, then recognizes the request needs a shipping carrier's specialized logistics agent and delegates that sub-task over A2A to an agent it does not own or control. The diagram should draw these as visually distinct arrow types — for example, a solid line labeled "MCP (stdio/HTTP)" for tool calls, and a dashed line labeled "A2A (HTTPS/SSE)" crossing a trust-boundary box for the delegation. For more on this pattern at scale, see multi-agent orchestration patterns.

MCP vs. A2A vs. ACP comparison table

Prompt templates for diagramming a multi-protocol agent stack

Customer-service system: MCP for tools, A2A for cross-vendor delegation

Enterprise research agent: MCP data access with A2A peer specialists

Legacy ACP migration note

What to annotate on the diagram

• Trust boundaries: Draw an explicit boundary box around each organization or team that owns and operates a given agent. Any A2A connection that crosses a boundary box is the highest-risk edge in the diagram and deserves the most scrutiny.
• Auth between agents: Label what credential authorizes each MCP tool call (OAuth scope, service token, API key) and each A2A task (bearer token, mTLS, signed Agent Card verification). Never leave a cross-boundary A2A arrow unlabeled.
• Protocol version: Note the A2A spec version (v1.0 as of 2026) and whether a connection is legacy ACP being migrated. Version mismatches between agents are a common source of production incidents in fast-moving protocol ecosystems.
• Transport type: Distinguish stdio-based local MCP servers (no network exposure) from remote Streamable HTTP MCP servers and from A2A's HTTPS/SSE connections — each has different exposure and monitoring implications.
• Data residency: Where an A2A delegation crosses into a third-party agent, mark what data leaves your environment in the task payload, since that agent may log, retain, or further delegate it beyond your visibility.

Frequently asked questions about the AI agent protocol stack

Do I need to choose between MCP and A2A?

No — they are complementary, not competing. Most production multi-agent systems use MCP for every agent's own tool connections and A2A whenever one agent needs to hand work to a genuinely separate agent, especially one owned by a different team or vendor. A system that only calls its own tools may never need A2A; a system with a single agent and no tools may never need MCP. Systems with both traits need both protocols.

Is ACP still worth using for a new project?

No. ACP's development team merged its work into A2A under the Linux Foundation in August 2025, and BeeAI — the project ACP was built for — has itself moved to A2A. New multi-agent projects should build on A2A directly rather than adopting ACP, which is no longer independently maintained.

How do I show protocol boundaries without cluttering the diagram?

Use two consistent arrow styles across the whole diagram — one for MCP tool calls, one for A2A agent delegation — and keep that convention identical in every diagram your team produces. Reserve detailed annotations (auth method, protocol version, transport) for the edges that cross a trust boundary; internal same-team MCP calls rarely need the same level of labeling as a cross-organization A2A delegation.

Related guides: MCP architecture diagrams, A2A protocol architecture, multi-agent orchestration patterns, and agentic AI security architecture.