The last three parts went deep on two protocols: MCP for the tool boundary and A2A for the peer boundary. This part pulls back to the whole landscape, because MCP and A2A do not exist alone. There is a third boundary they do not cover, a cluster of adjacent standards filling in around them, and a governance fight over who gets to define the stack. If the earlier parts were about how to read the protocols, this one is about how to read the field, so you can tell what is settled, what is still moving, and what is worth adopting.
The stack has three boundaries, not two
Part one drew two boundaries, down to tools and across to peers. There is a third, and it is the one a user actually sees: the boundary up to the human and their interface. An agent that calls tools and delegates to peers still has to stream its thinking, its tool calls, and its results to a screen, and let a person interrupt or approve along the way. That edge has its own emerging standard, AG-UI, an event protocol from CopilotKit that streams typed JSON events (messages, tool calls, state updates, lifecycle, human-in-the-loop) from an agent runtime to a front end over SSE or a binary channel.1
The picture to hold is three arrows from the agent: up to the user, across to a peer, down to a tool. Each is a different counterparty (a human, an opaque agent, a dumb tool), so each gets a differently-shaped protocol, which is the same lesson from part one extended one boundary further. MCP and A2A are the two mature edges; the user edge is younger, and AG-UI is the current front-runner rather than a settled winner.
How the two protocols actually compose
The most common confusion about MCP and A2A is that they compete. They do not; they stack.2 The canonical pattern is the one from part one: an application uses A2A to talk across to other agents, and each agent internally uses MCP to reach down to its own tools. A travel-planning system might use A2A to delegate “find and price flights” to a specialist flight agent, and that flight agent might use MCP to query an airline API and a calendar. The two protocols meet at the agent: A2A is how it is reached as a peer, MCP is how it reaches its tools.
This composition is why the “which protocol wins” framing is mostly wrong at the wire level. They answer different questions, and a serious system will speak both, plus probably an AG-UI-shaped protocol at the top. The interesting fights are not between MCP and A2A; they are around the edges and above them, in the layers that discovery, identity, configuration, and governance occupy.
The consolidation: ACP folded into A2A
For a while it looked like the peer boundary would fragment. IBM’s BeeAI launched a separate Agent Communication Protocol in early 2025, aimed at the same agent-to-agent problem as A2A. Instead of competing, the two merged: in August 2025, ACP joined forces with A2A under the Linux Foundation, and BeeAI moved to A2A.3 That is worth noting precisely because the broader story is so often told as fragmentation. At the wire level, the peer boundary actually consolidated: a credible competitor folded into the standard rather than splitting the field. When you hear that the agent space is a mess of rival protocols, remember that the most direct rival to A2A chose to become A2A.
The infrastructure layer: AGNTCY
Not every adjacent effort is a competing wire format. Cisco’s AGNTCY project, marketed as the “Internet of Agents,” joined the Linux Foundation in mid-2025 and targets a different layer entirely: the infrastructure agents need to find and trust each other at scale, including discovery, identity, messaging, and observability.4 Where A2A defines how two agents talk once they have found each other, AGNTCY is more concerned with the directory, the identity, and the plumbing around that conversation.
The distinction matters for reading the field. A2A and AGNTCY are not the same kind of thing, so “A2A versus AGNTCY” is usually a category error; the more accurate picture is a wire protocol (A2A) and an infrastructure stack (AGNTCY) that could plausibly sit under or beside it. Whether AGNTCY’s pieces become the standard infrastructure or one option among several is genuinely open, and I would not bet heavily either way yet.
The config layer: AGENTS.md
The most widely adopted “standard” in this whole space is not a protocol at all. AGENTS.md is a Markdown file, a README for coding agents, that tells an agent how to build, test, and navigate a repository.5 It has no wire format, no messages, and no transport; it is a convention for a file in your repo. It is also everywhere, adopted across a long list of coding tools and tens of thousands of projects, and now stewarded by the Agentic AI Foundation.
I include it because conflating “standard” with “protocol” is a common way to misread this landscape. AGENTS.md standardizes configuration, A2A and MCP standardize communication, AG-UI standardizes the UI stream, and AGNTCY standardizes infrastructure. They are complementary layers, not competitors, and a real agent system touches most of them. When someone lists these together as if they were alternatives, that is the tell that the layers are being flattened.
Two foundations, one stack
Now the governance, which is the part that is genuinely unsettled. The two flagship protocols sit under two different homes. A2A was donated to the Linux Foundation in June 2025, with a technical steering committee spanning AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow.6 MCP joined the Agentic AI Foundation in December 2025, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, which also stewards AGENTS.md.7
Read the cast lists and a pattern emerges: Google anchors A2A, Anthropic and OpenAI anchor the AAIF that holds MCP, and the big cloud vendors appear on both. Some industry analysts have framed this as two rival blueprints for who controls the agent stack.8 My read is softer, and I will mark it as a read rather than a fact: both protocols sit under the same Linux Foundation umbrella, both keep getting adopted across vendors, and they serve genuinely different boundaries, which is a strong structural reason for coexistence rather than conquest. It looks more like a land-grab over adjacent territory than a war over the same ground. But the governance is new enough that this is the part of the landscape I would watch most closely, because it is where the next two years could still surprise us.
What to actually bet on
Strip away the politics and the practical guidance for a builder is fairly clear, and it follows the maturity of each layer. MCP for the tool boundary is a safe bet today: it is broadly adopted across every major client, and the data layer is stable even as the transport evolves. A2A for the peer boundary is the right bet if you need it, with the caveat that it reached v1.0 only in 2026 and its edges are still moving, so pin a version. The user edge is worth designing for but not locking in, since AG-UI leads but is not yet a settled standard. AGENTS.md costs nothing to adopt and is effectively a default already. The thing not to do is wait for a single grand unified protocol, because the whole argument of this series is that there will not be one: different boundaries get different protocols, and the winning move is to speak the right one at each edge.
Takeaways
The landscape makes sense once you stop looking for one protocol to win:
- There are three boundaries, and they stack. Down to tools (MCP), across to peers (A2A), up to the user (AG-UI). A real system speaks all three, plus configuration and infrastructure layers around them.
- At the wire level the field is consolidating, not fragmenting. A2A’s most direct rival, IBM’s ACP, merged into it. The fragmentation story is mostly about flattening different layers into a false competition.
- “Standard” is not “protocol.” AGENTS.md is a config file, AGNTCY is infrastructure, AG-UI is a UI stream, MCP and A2A are communication. Sorting any new entrant into its layer is how you avoid the category errors that make the field look chaotic.
- The governance is the unsettled part. Two foundations, overlapping casts, a real question of who defines the stack. Bet on the boundaries, which are permanent, and watch the foundations, which are not. The final part takes that forward and asks where this is all heading.
Footnotes
-
AG-UI is the Agent-User Interaction Protocol from CopilotKit, an event-based protocol streaming typed JSON events between an agent runtime and a front end over SSE or a binary channel. See the AG-UI documentation. ↩
-
A2A’s own documentation frames the two protocols as complementary and shows the composition pattern, an application using A2A across to peers while each agent uses MCP down to its tools. See A2A and MCP. ↩
-
IBM’s Agent Communication Protocol merged with A2A under the Linux Foundation in August 2025; BeeAI moved to A2A. See ACP joins forces with A2A. ↩
-
Cisco’s AGNTCY project (the “Internet of Agents”), covering agent discovery, identity, messaging, and observability, joined the Linux Foundation in July 2025. See the Linux Foundation AGNTCY announcement and the AGNTCY docs. ↩
-
AGENTS.md is a Markdown configuration convention for coding agents (build steps, conventions, test commands), created by OpenAI, released in 2025, adopted across tens of thousands of projects, and now stewarded by the Agentic AI Foundation. See agents.md. ↩
-
A2A was donated to the Linux Foundation in June 2025 with a technical steering committee including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. See the Linux Foundation A2A launch. ↩
-
MCP joined the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, in December 2025; the foundation also stewards AGENTS.md. See MCP joins the Agentic AI Foundation. ↩
-
The framing of A2A and the Agentic AI Foundation as competing governance blueprints is analyst commentary rather than an official position; the underlying foundation memberships are confirmed, the rivalry characterization is interpretation. For an example of the framing, see Blocks & Files, “A2A, AAIF and AI agents”. ↩