The Interoperability Illusion of A2A: Protocol Compatibility ≠ True Collaboration

An Overly Optimistic Reading of a Protocol

As multi-agent systems emerge as a new paradigm for AI applications, the A2A (Agent-to-Agent) protocol has been met with high hopes — widely regarded as a critical step toward solving agent interoperability. And it does deliver a general-purpose mechanism at the protocol layer: agents can discover each other and exchange Messages, Tasks, Parts, Artifacts, and status updates. This eliminates a significant amount of custom integration work.

But one Reddit developer raised a sharp and thought-provoking point: protocol compatibility and true interoperability are two different things. A2A addresses the question of "can agents communicate?" — but it falls far short of the deeper challenge: "after communicating, can they actually work together?" This article follows that line of thinking to unpack three often-overlooked layers of agent interoperability.

Three Layers of Agent Interoperability

The author breaks production-grade interoperability into three layers — the most valuable framework in the entire discussion.

Layer 1: Protocol Layer — Can Agents Communicate Correctly?

The most fundamental question is: can agents communicate correctly? This is precisely what A2A has already solved. Through a unified message format and task model, agents built on different frameworks can handshake and exchange data at the transport layer. This is where standardization delivers the most obvious benefits, and why major frameworks are racing to support A2A.

A2A was released by Google in 2025 as an open HTTP-based protocol. It uses JSON-RPC 2.0 as its message format and implements an "Agent Card" mechanism for agents to declare and advertise their own capabilities. Each agent can expose a standardized .well-known/agent.json endpoint describing the skills it supports, its input/output formats, and its authentication methods. Tasks are the protocol's core unit of abstraction — representing a stateful work request that can include multiple Message turns and carry structured intermediate or final results via Artifacts. This design draws on the mature philosophy of HTTP REST, giving agents built in different languages and frameworks a common language at the transport layer. Compared to MCP (Model Context Protocol), A2A is more focused on asynchronous, long-running task collaboration between agents, while MCP is more oriented toward synchronous calls between a model and tools or data sources. The two are generally seen as complementary rather than competing standards in multi-agent architectures.

Layer 2: Semantic Layer — Is Understanding Consistent?

This is where the real trouble begins. Two agents can both declare via A2A that they support "invoice reconciliation" — but their understanding of that skill may differ dramatically:

• Are the input/output schemas consistent?
• How is confidence expressed?
• How are errors and partial results handled?
• What side effects might occur?
• Under what conditions should the task escalate to human intervention?

The protocol tells you "this agent can do invoice reconciliation" — but it doesn't tell you whether that agent's assumptions align with yours. Semantic misalignment is insidious: everything looks fine at the protocol layer, while problems quietly emerge in the business logic.

Layer 3: Operations Layer — Can Engineering Reliability Be Guaranteed?

The third layer concerns engineering reliability: when a call crosses agent boundaries, can authorization, retries, idempotency, tracing, budgets, evaluations, and approvals all be maintained?

The author makes a pointed observation: a retry mechanism at the transport layer does not make a non-idempotent operation safe to retry. If Agent B performs an action with side effects — like a money transfer — automatic retries at the A2A layer could cause serious damage. Operational consistency is something protocol standards alone cannot guarantee.

Idempotency is a core concept in distributed systems engineering: the same operation, executed once or multiple times, produces exactly the same result. In monolithic systems, developers typically rely on database transactions to ensure atomicity. But when operations cross agent boundaries, transactional semantics break down. Traditional microservice architectures have already surfaced this pain point deeply — patterns like "eventual consistency" and "idempotency keys" exist precisely for this reason. In multi-agent systems, the problem is amplified further: the call chain may span multiple autonomous agents, each potentially making independent retry decisions, with no natural isolation between protocol-level retries and business-level side effects. This means the operational reliability of multi-agent systems fundamentally inherits all the classic challenges of distributed systems — requiring active architectural design for idempotent operations, distributed tracing (e.g., OpenTelemetry), and cross-agent circuit breaker and fallback mechanisms, rather than expecting protocol standards to automatically catch everything.

Different Frameworks Draw the A2A "Boundary" in Different Places

The author surveyed current major implementations — Google ADK, Microsoft Agent Framework, CrewAI, LangGraph/LangSmith, and Lyzr Agent Studio — and found that while all of them support A2A, the protocol boundary sits in very different places:

• Some treat a remote agent as the boundary;
• Some wrap it as a delegation tool;
• Some map it to a deployed graph;
• Others treat it as a node in an orchestration flow.

This means that even when everyone "supports A2A," the actual abstraction levels and integration patterns still differ significantly. Beneath the surface of apparent standardization lies a divergence of architectural assumptions. This also explains why the label "supports A2A" alone is not sufficient to guarantee smooth cross-system collaboration.

The Real Interoperability Test: Substitutability, Not Callability

The most illuminating conclusion in this piece is its redefinition of what interoperability should actually be measured by. The author argues that the right question is not:

Can my system call an A2A agent?

But rather:

Can I replace Agent B without having to rebuild everything around it?

This standard of substitutability cuts to the heart of the matter. Callability is just the minimum bar; substitutability tests whether agents are truly loosely coupled by genuine contracts. If replacing an "invoice reconciliation agent" requires rewriting the caller's error handling, schema adapters, approval flows, and monitoring logic — then the so-called interoperability is nothing but an illusion.

The concept of substitutability has deep roots in software engineering. Its most direct theoretical source is the Liskov Substitution Principle (LSP) from object-oriented design: a subtype object should be able to transparently replace a supertype object without breaking the caller's behavioral expectations. Transposing this principle to a multi-agent context means that two agents claiming to support the same skill should be interchangeable without requiring any modification to the caller's logic. This also aligns closely with the practice of "contract testing" in microservice architectures — tools like Pact use consumer-driven contracts to verify service substitutability, rather than merely checking interface formats. For multi-agent systems, establishing a similar agent contract testing mechanism — requiring service providers to pass consumer-side semantic compatibility verification before releasing new versions — may be the most effective path to turning "substitutability" from a concept into an engineering practice.

What Dimensions Should A2A Conformance Testing Cover?

Following the author's line of reasoning, an agent conformance test that goes beyond schema and protocol checks might need to cover the following dimensions:

• Semantic contract validation: Not just validating input/output schemas, but verifying that semantic assumptions about the same skill are consistent — including confidence expression and the definition of partial results.
• Side effect declarations: Does the agent explicitly declare the idempotency and side effects of its operations, allowing callers to decide whether it's safe to retry?
• Error and degradation behavior: Is the agent's behavior under exceptions, timeouts, and human escalation predictable and negotiable?
• Operational cross-cutting concerns: Can authorization, tracing, budgets, and approvals be propagated across boundaries — rather than silently dropped at the boundary?
• Substitutability regression: Integration tests targeting the goal of "replacing a peer agent," verifying that surrounding systems can switch backend implementations without modification.

Conclusion: Protocol Standardization Is Just the Starting Point for Multi-Agent Collaboration

A2A is undeniably an important step toward a more mature agent ecosystem, and it deserves credit for lowering the barrier to communication. But we need to be clear-eyed: protocol standardization only addresses the first of three layers of challenge. Semantic alignment and operational consistency — the two layers that are harder to standardize and more dependent on engineering practice and industry conventions — are what ultimately determine whether a multi-agent system can truly be deployed in production.

For teams building multi-agent systems today, rather than settling for "we support A2A," it's worth honestly answering the harder question: if you swapped out one of the agents, how much would you need to rebuild? The closer the answer is to "almost nothing," the closer your system is to true interoperability.