CURRENT
A journal for living in the agentic age
Further Reading
MCP and A2A are becoming the communication layer for autonomous software. MCP assumes the thing on the other end is a toolbox. A2A assumes it's an opaque peer with its own reasoning and goals. They weren't designed as a stack. They're being adopted as one.
The interesting territory is where the categories leak. MCP servers can now reason. A2A agents can wrap single deterministic functions. The boundary between "tool" and "agent" is a protocol choice, and governance frameworks are already building on it. Authorization depends on it. And it keeps dissolving at exactly the point where identity needs to propagate across it.
MCP and A2A are becoming the communication layer for autonomous software. MCP assumes the thing on the other end is a toolbox. A2A assumes it's an opaque peer with its own reasoning and goals. They weren't designed as a stack. They're being adopted as one.
The interesting territory is where the categories leak. MCP servers can now reason. A2A agents can wrap single deterministic functions. The boundary between "tool" and "agent" is a protocol choice, and governance frameworks are already building on it. Authorization depends on it. And it keeps dissolving at exactly the point where identity needs to propagate across it.
MCP and A2A handle different halves of a multi-agent workflow. Most explanations cover each protocol separately and leave it at that. The seam between the two, where a developer's real architectural decisions live, gets skipped. That boundary belongs to neither protocol. It's application code you write yourself.
This walkthrough uses a retail inventory scenario to trace what happens at each stage: an agent queries stock levels through MCP's structured tool calls, determines restocking is needed, then coordinates with an external supplier through A2A's task lifecycle. The two sides work differently in ways that matter. One gives you schemas. The other gives you state transitions and a conversation you didn't fully plan for.
MCP and A2A handle different halves of a multi-agent workflow. Most explanations cover each protocol separately and leave it at that. The seam between the two, where a developer's real architectural decisions live, gets skipped. That boundary belongs to neither protocol. It's application code you write yourself.
This walkthrough uses a retail inventory scenario to trace what happens at each stage: an agent queries stock levels through MCP's structured tool calls, determines restocking is needed, then coordinates with an external supplier through A2A's task lifecycle. The two sides work differently in ways that matter. One gives you schemas. The other gives you state transitions and a conversation you didn't fully plan for.
MCP hit 110 million monthly SDK downloads faster than anyone expected. Thousands of servers, a Linux Foundation home, working groups with formal charters. By every adoption metric, the protocol has arrived.
But adoption velocity and production readiness measure different things. The official roadmap names enterprise gaps that remain pre-RFC. Peer-reviewed research finds most clients don't validate the tool metadata they're handed. Context windows fill up with tool descriptions before agents do any actual work.
Six cards on where MCP actually stands: the scale, the gaps, and the governance machinery trying to close the distance between them.
MCP hit 110 million monthly SDK downloads faster than anyone expected. Thousands of servers, a Linux Foundation home, working groups with formal charters. By every adoption metric, the protocol has arrived.
But adoption velocity and production readiness measure different things. The official roadmap names enterprise gaps that remain pre-RFC. Peer-reviewed research finds most clients don't validate the tool metadata they're handed. Context windows fill up with tool descriptions before agents do any actual work.
Six cards on where MCP actually stands: the scale, the gaps, and the governance machinery trying to close the distance between them.
The agent ecosystem has been circling a coordination problem for the past year: how do autonomous systems built by different teams, on different frameworks, with entirely different internal architectures work together without collapsing into bespoke integration? Google's Agent2Agent protocol is one answer, and it's gaining traction faster than most protocol efforts manage.
Now under Linux Foundation governance and approaching its first anniversary, A2A has moved from announcement to production standard with unusual speed. The adoption numbers tell part of the story. The design choices tell the rest, particularly what the protocol deliberately keeps hidden between collaborating agents and where it draws the line against MCP's complementary role.
Here's the landscape at the one-year mark.
The agent ecosystem has been circling a coordination problem for the past year: how do autonomous systems built by different teams, on different frameworks, with entirely different internal architectures work together without collapsing into bespoke integration? Google's Agent2Agent protocol is one answer, and it's gaining traction faster than most protocol efforts manage.
Now under Linux Foundation governance and approaching its first anniversary, A2A has moved from announcement to production standard with unusual speed. The adoption numbers tell part of the story. The design choices tell the rest, particularly what the protocol deliberately keeps hidden between collaborating agents and where it draws the line against MCP's complementary role.
Here's the landscape at the one-year mark.
