Every protocol carries an implicit theory about what's on the other end of the connection. HTTP assumes a server that responds to requests. SMTP assumes a mailbox that accepts messages. The assumptions are so baked in that we forget they're assumptions at all.

MCP and A2A are becoming the communication substrate for autonomous software, and they carry two very different theories. MCP places intelligence on the caller's side; the server waits. A2A starts from the opposite premise: both parties are opaque autonomous agents with their own memory, reasoning, and goals. The thing on the other end is a peer.

The conventional framing treats these as complementary layers. MCP for tools, A2A for agents. Clean separation. The TCP/IP analogy gets invoked, and it's useful for about thirty seconds. TCP/IP was designed with unified architectural intent across its layers. MCP and A2A emerged from different organizations, different communities, different moments in the development of agent infrastructure. They weren't designed as a stack. They're being adopted as one.

The categories leak, though, and that's where it gets interesting. MCP includes a sampling primitive that lets servers request LLM completions from the client, inverting the assumed direction of intelligence. An MCP server using sampling reasons, requests, acts on intermediate results. Frameworks like mcp-agent go further, exposing full agents as MCP servers. And an A2A agent that wraps a single deterministic function is functionally identical to an MCP tool, just described in prose instead of JSON Schema.

The leakage runs deeper than taxonomy. The protocols disagree about whether the thing on the other end has state that matters. An MCP server using sampling has internal reasoning, intermediate conclusions, context that shapes its next action. MCP's architecture doesn't model any of that as something the caller should care about. A2A at least names the opacity, declaring that neither side sees the other's internals. These are different kinds of unknowing. MCP assumes there's nothing to see. A2A assumes there's something worth seeing and deliberately hides it. For the deployer trying to reason about what they're running, the difference is significant: the observability expectations, the auditability assumptions, the very question of whether "what happened inside that call" is a meaningful thing to ask. And both protocols can now describe the same computational entity.

The boundary between "tool" and "agent" turns out to be a protocol choice. Governance attaches to that boundary. MCP uses OAuth 2.1 for authorization. A2A obtains credentials out-of-band. Neither protocol defines how identity propagates across the seam when an A2A task triggers an MCP tool call. As one security analysis put it:

The server sees an authenticated agent. The person who asked has already dropped out of the identity chain. When the entity crossing that boundary is itself an agent with delegated tasks of its own, the chain breaks further. Authorization loses certainty about what kind of thing it's authorizing, because the protocol boundary that's supposed to distinguish tool from agent is the very boundary that keeps dissolving.

Email's protocol stack had a version of this problem. SMTP handled delivery, IMAP handled retrieval, and neither understood the other's model of what "sent" meant. SMTP had no concept of a sent folder. Sending a message and saving a copy required transmitting the content twice, to two different protocols, which eventually needed a separate RFC extension to reconcile. Two useful protocols, one seam, years of patches.

MCP and A2A will coexist. They already do. The protocols that carry our assumptions about what agents are can't agree on which side of the line a given entity belongs to. The governance frameworks that depend on that line are already being built.