MCP, A2A, and the Coming Agentic Interop Layer

The agentic interop layer is being built, slowly, in two separate working groups whose work is going to collide in the next eighteen months. One is the Model Context Protocol, originally proposed by Anthropic and now adopted by enough implementers that it deserves the “de facto standard” label for tool-server interop. The other is the broader set of agent-to-agent (A2A) protocol efforts — less consolidated, more contested, and still defining what an “agent” is for protocol purposes.

This piece is an attempt to read both efforts in parallel and to flag where the standards conversation is actually unresolved. We use no fabricated numbers, no fabricated implementations, and no fabricated participants. Where we infer the direction of a working group, we say so.

What MCP is

The Model Context Protocol, in its current shape, is a transport-level specification for how an agent (or, more precisely, an “MCP client”) talks to a tool provider (an “MCP server”). The protocol defines how clients discover the capabilities of a server, how they call those capabilities, and how they receive structured results. The most important property of the spec, from an architectural standpoint, is that it abstracts the tool layer away from the model layer. The same MCP server can be used by any MCP-compatible host — Claude, OpenAI, an internal platform — without code changes on the server.

The architectural diagram, simplified:

The transports are stdio in the local case and HTTP/SSE in the remote case. The wire format is JSON-RPC 2.0. The capability model is a small set of primitives — resources, tools, prompts, sampling — that are deliberately narrow.

What MCP gets right is the abstraction layer. Before MCP, every agent platform had its own tool calling convention, which meant tool authors had to ship a per-platform integration or, more commonly, did not ship to most platforms at all. MCP is the OAuth of the agentic era in this sense — not a moral achievement, just a shared abstraction that lets the ecosystem grow.

What MCP does not yet get right is identity. The spec assumes the host trusts the server and the server trusts the host. There is no native model for “this agent is acting on behalf of user X with permissions Y.” Identity is the responsibility of the host application, which is a defensible boundary choice but one that pushes a real problem down the stack. We will return to this.

What A2A is

The agent-to-agent (A2A) protocol effort is messier. There is no single canonical specification. There are several proposals in circulation, some from individual vendors, some from working groups inside the larger interop conversations, and at least one from an academic group working on autonomous-multi-agent systems.

The shared problem they are trying to solve is straightforward: when one agent needs to invoke another agent — not a tool, not a model, an agent — what does that call look like? How does the calling agent know what the called agent can do? How does the called agent know who is asking and with what authority? How are partial results streamed back? How does termination work when the caller decides the work is no longer needed?

These are genuinely harder problems than MCP solves. A tool is a function with a typed signature. An agent is a process with state, a context window, possibly its own tools, and a set of behaviors that depend on the input in non-deterministic ways. The protocol surface is larger and the failure modes are more interesting.

The current state of the A2A conversation, as best we can read it from the public proposals, is that the working groups have converged on a few principles and are still arguing about most of the rest:

• Agents should be addressable. Each agent should have a stable identifier and a discoverable capability descriptor.
• Invocations should be asynchronous by default. The caller should not block on the callee.
• Calls should be cancellable. The caller should be able to terminate work it no longer needs.
• Results should be streamable. Partial output should be available before completion.

What is not converged: the authentication model, the cost-accounting model, the failure-semantics model, and the question of whether agents from different vendors can usefully share a context window.

Where the two efforts collide

In the medium term, MCP and A2A are going to overlap. The most likely collision point is in the question of what counts as a “tool” versus what counts as an “agent.”

The current line is roughly: a tool is stateless, narrow, and called with a typed request that returns a typed response. An agent is stateful, broader, and called with a goal that returns a result over time. In practice, the line gets fuzzy fast. An MCP server that wraps a long-running task is starting to behave like an agent. An agent that exposes a narrow capability is starting to behave like a tool.

We expect, in the next twelve months, one of two things to happen. Either MCP extends to cover the stateful-long-running case — which would, effectively, absorb the A2A use case — or A2A consolidates into a distinct protocol layered on top of MCP, in which agents are described as a particular kind of MCP server with additional discovery and lifecycle semantics.

The second outcome is, in our reading, more likely. The MCP spec is small and deliberately narrow; adding agent-lifecycle semantics to it would dilute its main strength. A separate layer that uses MCP as the transport and adds the agent-specific surface is a cleaner architectural fit.

The identity problem

The hardest unresolved question is identity. Both MCP and A2A have, so far, punted on the problem in similar ways. The host application is responsible for knowing who the user is. The host is responsible for knowing what the user can do. The protocol assumes the host has gotten this right.

This is fine when the host is a single chat application. It is not fine when the host is an orchestrator running multiple agents on behalf of multiple users against shared tools. In that case, the protocol needs to be able to carry an identity context — at minimum, a token that the server can verify — and the protocol needs to specify how a server should react when the identity context is missing or invalid.

The MCP working group is, in our reading, aware of this and is treating it as a near-term priority. The A2A conversations have not yet, to our knowledge, produced a converged answer. We will be watching the working-group materials closely. Identity is the problem that determines whether agentic systems are deployable in regulated environments. It is also the problem most easily deferred to the host, which is why both protocols have, so far, deferred it.

The cost-accounting problem

A second unresolved problem is cost accounting. When an agent invokes a tool, the tool may have a cost. When an agent invokes another agent, the cost may be substantial and may grow during execution. Neither MCP nor any of the A2A proposals has a native cost-accounting model.

In practice, this means the calling host has to do the accounting itself, which it does by tracking the model and tool calls it knows about. This works for first-party tools and breaks for third-party agents whose internal costs are not visible. The protocol gap turns into a real lock-in pressure: hosts prefer agents whose costs they can see, which means agents that are first-party or that voluntarily expose their internals.

A serious protocol layer will eventually need a cost-accounting primitive. The shape is not yet clear. The work is not, as far as we can tell, being done in either working group as of this writing.

The audit problem

A third problem, less discussed in the working groups but increasingly raised by enterprise adopters, is audit. When an agent calls a tool, the call should be logged. When the call returns a result, the result should be logged. When the result influences a subsequent decision, the chain should be reconstructable.

MCP’s logging model is, at present, the host’s responsibility. The server can emit notifications but is not required to. Audit, in any serious enterprise sense, requires the host and every server in the call chain to agree on a logging discipline. This is the kind of discipline that arrives in protocol specifications late — usually after the first compliance incident — and it tends to arrive as a versioned extension rather than a core property.

We expect MCP to get an audit-extension proposal in the next twelve months. We do not have a strong prediction about which working group will produce it.

Reading the field

If you are building an agentic product today, the practical advice is conservative.

• Implement MCP for tool integration. The protocol is small, the host coverage is good, and the abstraction is durable.
• Do not bet your architecture on a single A2A proposal. Pick the proposal whose semantics are closest to your needs, implement against it, and be prepared to swap when the standards conversation consolidates.
• Solve identity at the host. Do not assume the protocol will solve it for you. The protocol will eventually, but not soon enough.
• Track cost accounting yourself. Build a model of who-called-what at the host level. Do not rely on the called services to expose it.
• Log everything. When the audit extension arrives, you will be glad to have logs to back-fill. The cost of structured logging now is small. The cost of not having it when regulators ask is large.

What we are watching

We will be following both working groups across 2026 and reporting on the working materials as they become public. The most consequential decisions of the next year are likely to be made in two places. The first is in the MCP identity proposals, which will determine how soon enterprise adoption is feasible. The second is in whichever A2A proposal first ships with cancellation and streaming semantics that other vendors can actually adopt.

The agentic interop layer is being built right now. The architectural choices being made in the next eighteen months will shape the next decade. Most of the conversation, today, is happening in IRC-equivalent corners of the internet rather than in the founder press. That is the right place for it. It is also the reason we cover the working groups: by the time the protocols show up in vendor marketing, the interesting decisions have already been made.