Your Agents Can Talk. That Was Never the Hard Part.

Building Minds — a practical field guide to Agent2Agent (A2A)

A new protocol arrived this year, and the pitch is seductive. Google built Agent2Agent, donated it to the Linux Foundation, and roughly 150 companies put their logos on the announcement. The specification is real and mature — v1.0 shipped in March, the SDKs have millions of downloads, and the wire format is genuinely well-designed. Your agent can now discover another vendor's agent, hand it a task, stream the result back, and never once see inside it.

That is a real accomplishment. It is also not your problem.

The hard part of getting two agents to collaborate was never the envelope the message travels in. It was everything the envelope does not carry: whether the other agent is competent, whether it is allowed to do what you just asked, whether it means the same thing you do by "approved" or "complete," and whether you can prove afterward what it actually did. A protocol standardizes the handshake. It does not standardize trust, meaning, authority, or accountability. Those you still have to build.

This is the interoperability trap. A2A makes agent-to-agent communication feel solved, which makes it tempting to treat the remaining work as integration plumbing. It is not plumbing. It is the operating model — the same lesson that separates the enterprises capturing real returns on agentic AI from the ones stuck producing demos.

Let me give you the frame I actually use, and the tests you can run this quarter.

First, know what A2A is for

A2A is horizontal. It connects agents to other agents — independent systems that reason, hold state, ask clarifying questions, and manage long-running work across a vendor, framework, or organizational boundary. Its cousin, MCP, is vertical: it connects a single agent to its tools, data, and resources. You use both. MCP gives one agent hands; A2A lets that agent delegate to a peer it does not own.

The trap has a specific shape here: not everything that speaks needs to be an agent. If a capability is a deterministic function — look up a record, run a calculation, fetch a document — it is a tool, and it belongs behind an API or MCP, not dressed up as an A2A peer. Promoting every LLM-backed endpoint to a full agent adds discovery, trust, and governance overhead you did not need to buy. Reserve A2A for genuine autonomy. Everything else is a call, not a collaboration.

Actionable: Before you reach for A2A, write one sentence about the participant. If the sentence is "it does X when asked," it is a tool. If the sentence is "it decides how to accomplish X and may come back with questions," it is an agent. Only the second sentence justifies the protocol.

The eight things that must be true

Here is the checklist I run against any A2A ambition. If you cannot answer these, the protocol is not your blocker — your operating model is.

1. There are genuinely independent agents. Real state, real reasoning, real long-running work. Not a wrapped API.
2. Interoperability cost is material. You are facing the second, third, and fourth point-to-point integration — not a one-off connection you could hardcode in an afternoon.
3. Agent Cards stay accurate and revocable. The metadata that advertises what an agent can do, where it lives, and how to authenticate is current — and you can pull it when something goes wrong.
4. Identity survives the hop. When your orchestrator hands work to a specialist, the specialist knows which human or client initiated it and what that principal is allowed to do. Authority does not evaporate at the boundary.
5. Semantic contracts exist above the wire. Both sides agree on what the business terms mean, what counts as acceptable evidence, and what "done" looks like. Free-form language is not a contract for consequential actions.
6. Observability crosses the boundary. Trace IDs, audit events, provenance, timestamps, status history — you can reconstruct what happened across organizations, not just inside your own.
7. Failure is bounded. Delegation depth, cost, time, data access, and irreversible actions all have hard limits. An agent cannot recruit an unbounded chain of other agents on your budget.
8. The vendor actually shipped. A logo on a partner slide is a commitment, not a product. You need documentation, conformance evidence, support boundaries, and an SLA.

Notice how few of these are about the protocol. Seven of the eight are about governance, identity, meaning, and evidence. That is the point.

The seven-word rule for what must not be true

If you want a single sentence to carry into your next architecture review, make it this: authenticated is not the same as trusted.

A signed Agent Card proves an agent is who it says it is. It says nothing about whether that agent is competent, safe, semantically aligned, or authorized for the outcome you care about. The most expensive mistakes in cross-agent systems come from collapsing that distinction — granting a remote agent ambient access to everything the originating user could do, or treating protocol conformance as proof of business correctness. Conformance means the message was well-formed. It does not mean the answer was right.

Recommended by LinkedIn

[I have argued four times that I do not need to buy the… Alexander Harris

2 weeks ago](https://www.linkedin.com/pulse/i-have-argued-four-times-do-need-buy-product-finally-found-harris-ntgie) [I Stopped Thinking the Model Was the Product Srivatsan Santhanam

5 months ago](https://www.linkedin.com/pulse/i-stopped-thinking-model-product-srivatsan-santhanam-epbbc) [Building Multi-Agent Systems with OpenClaw Kevin Lu

7 months ago](https://www.linkedin.com/pulse/building-multi-agent-systems-openclaw-kevin-lu-vygqc)

Three tests that settle the question fast

Do not argue about A2A in the abstract. Run these.

The technical proof. Build one narrow pilot: an orchestrator agent, one independent specialist, an MCP-backed data layer inside the specialist. Wire up Agent Card discovery, OAuth or mTLS, task streaming, the "input-required" handoff, artifacts, distributed tracing, and cancellation. Success has a precise definition: you can swap out the specialist for a different vendor's agent without redesigning the orchestration contract. If you cannot, you built a point-to-point integration wearing a protocol costume.

The governance proof. Before the pilot, try to answer seven questions. Who approves an Agent Card? Who owns the signing key and the endpoint? How do you revoke a skill? Which principal is visible at each hop? Which actions require a human in the loop? Where are messages and artifacts retained? How do you quarantine and replay an incident? If these have no owners, the technology is not what is stopping you.

The economic proof. A2A earns its keep only when the marginal cost of the next integration falls far enough to pay for the control plane — the registry, the tracing, the security, the certification. One integration never justifies it. A roadmap of many, across systems you do not control, might.

The pattern that keeps you safe

When the tests pass and you build for real, the architecture that survives contact with a security team looks like this:

Human/Enterprise workflow
        ↓
Policy-bound orchestrator
        ↓  A2A through a gateway + registry
Specialist agents in separate trust zones
        ↓  MCP / API under local least privilege
Approved enterprise systems and data

The orchestrator receives evidence-bearing artifacts — not unrestricted access to a peer's internals. High-impact recommendations route to a human. Actions execute through narrow, policy-bound tools, never free-form delegation. The agents stay opaque to each other, which is A2A's design gift, but opacity is not an excuse for decisions no one can audit.

Where this actually stands in mid-2026

Be honest with your stakeholders about the evidence, because the gap between announced and shipped is wide. The specification is mature, and the developer momentum is real. But publicly verifiable shipped integrations are still concentrated in a few vendors, named enterprise production case studies remain thin, and most of the convincing deployments so far run inside a single vendor's stack — which quietly undercuts the whole interoperability promise.

So, the posture I recommend is: prototype now, standardize your criteria now, and do not yet assume broad cross-vendor production portability. Reassess quarterly against five signals — SDK general-availability status, vendor product documentation, conformance-kit adoption, registry and identity standards, and security disclosures. When those mature, move. Until then, an internally governed A2A pilot where the autonomy is real beats a cross-vendor bet the market has not yet proven.

The larger point

Every few years, the industry produces a protocol and mistakes it for a strategy. A2A is a good protocol. It solves a genuine problem — the combinatorial mess of connecting agents built by different teams on different frameworks. If you have that problem, it is worth your attention.

But it solves the easy layer. The layers that decide whether cross-agent collaboration is safe and valuable — identity that survives delegation, shared meaning above the message, bounded failure, evidence you can audit, governance with real owners — those are not in the specification. They never are. The protocol is the communication layer. The cognitive and enterprise stack sits on top of it, and that is where the work, the risk, and the advantage live.

Your agents can talk now. Good. The question was always what happens when they do.

Reply and tell me: are you seeing real cross-vendor A2A in production, or is it still logos on a slide? I'm collecting field evidence.

— Jerry