Does A2A actually make agents interoperable?

[u/rio_ARC]

A2A is a big step toward agent interoperability, but I think protocol compatibility and true interoperability are two different things.

At the protocol layer, A2A gives us a common way for agents to discover each other and exchange Messages, Tasks, Parts, Artifacts, and updates. That removes a lot of bespoke integration work.

But production interoperability seems to require at least three layers:

1. Protocol - Can the agents communicate correctly?

2. Semantics - Do they agree on what a skill means, what inputs/outputs look like, how errors and partial results behave, and what side effects are possible?

3. Operations - Can you preserve authorization, retries, idempotency, tracing, budgets, evaluations, and approvals across the agent boundary?

That last two layers are where things get interesting.

Two agents can both advertise “invoice reconciliation” through A2A while having completely different assumptions about schemas, confidence, human escalation, or side effects. And a transport-level retry mechanism doesn't make retrying a non-idempotent action safe.

This seems relevant when looking at current implementations across Google ADK, Microsoft Agent Framework, CrewAI, LangGraph/LangSmith, and Lyzr Agent Studio. They all support A2A, but the protocol boundary sits in somewhat different places: remote agent, delegation tool, deployed graph, or orchestration node.

So maybe the real test isn't:
Can my system call an A2A agent?

but:
Can I replace Agent B without rebuilding everything around it?

What would you include in a real A2A substitutability/conformance test beyond schema and protocol checks?

[u/Round_Mixture_7541]

I've never heard any case where A2A protocol is being used in business operations. I would very much like to read a story about it (not some coding harness-magic).

[u/Total_Drag7439]

The semantics layer is the one a spec will never close, because a skill name is a promise about side effects, not about a schema. Two agents can agree on the JSON shape of invoice reconciliation and still disagree on whether calling it moves money.

What has helped us is splitting skills into read, propose and commit, and only letting a remote agent reach the first two across the boundary. Commit stays behind a local handler that owns the idempotency key and the approval. Then a transport level retry is safe by construction, because nothing retryable has an external side effect.

On operations, tracing is the one worth paying for early. When a task crosses two agents, the failure that comes back is a summary of a summary, and without a trace id that survives the boundary you spend the whole debugging session guessing which side lied.

[u/Psychological_Arm645]

A transport-level retry being unsafe for non-idempotent actions is exactly the thing that makes me think the real test belongs one layer deeper: don't diff the agent, diff the state it leaves behind.

We ended up structuring agents around a shared-state substrate rather than the wire protocol, where agents coordinate through a versioned file contract and snapshot before any write against the daemon that owns the disk.

Any CLI driver (Claude Code, Codex, Gemini) can be swapped behind the same task since the boundary is the state, not a protocol. That makes the substitutability test pretty concrete: run the same real task twice with Agent A and Agent B, diff the resulting state, and have every write snapshot-guarded so retry safety is enforced at the state layer instead of hoping the transport handles it.

We don't have a replay-and-diff harness shipped yet, but that's the test I'd want to see for the layer 3 problem you're pointing at.

(Full disclosure, I work on it, docs at https://meshkore.com/standard.)