The A2A Protocol: How AI Agents Talk to Each Other

Most businesses now run at least one AI agent. The next problem is already showing up: those agents live on islands. Your support agent cannot ask your billing agent to issue a refund. The lead-qualification agent your marketing team bought cannot hand a hot lead to the scheduling agent your sales team built. Each one is competent inside its own walls and useless the moment a task crosses a boundary.

That is the gap the Agent2Agent (A2A) protocol is built to close. Open-sourced by Google and now run as a Linux Foundation project, A2A is a standard way for independent agents, even ones built by different vendors on different frameworks, to discover each other, exchange tasks, and coordinate. In its first year the project crossed 150 supporting organisations, landed in Google, Microsoft, and AWS platforms, and moved into real production use in supply chain, financial services, and IT operations. If you are investing in agents, this is the plumbing worth understanding now, before the integrations you build by hand have to be torn out later.

Two problems, two protocols

It helps to be precise about what is actually being standardised, because two different standards keep getting confused.

The Model Context Protocol (MCP) solves vertical integration: how one agent connects to tools, databases, and data sources. It is how an agent reaches down to the systems it needs.

A2A solves horizontal integration: how one agent talks to another agent. It is how an agent reaches across to a peer. One gives an agent its hands; the other gives it colleagues.

What A2A actually does

Strip away the spec and A2A provides a few concrete things. Agents publish an "agent card", a small machine-readable document that advertises what they can do, so others can discover their capabilities without a custom integration. They exchange tasks through a standard message format, track those tasks through their lifecycle, and stream partial results back as work progresses.

Technically it rides on familiar rails: JSON-RPC 2.0 over HTTPS, with Server-Sent Events for streaming updates. That matters because it means A2A slots into normal web infrastructure. There is no exotic transport to operate, and your existing auth, logging, and network controls largely still apply. SDKs already exist in Python, JavaScript, Java, Go, and .NET.

A2A vs MCP: not a competition

A lot of coverage frames these as rivals. They are not. A realistic 2026 setup uses both at once.

Picture a procurement workflow. Your purchasing agent uses MCP to read your ERP and your supplier catalogue (vertical: agent to tools). When it needs a quote, it uses A2A to ask a supplier's pricing agent for a current price (horizontal: agent to agent). The supplier's agent in turn uses its own MCP connections to look up stock. Each protocol is doing the job it was designed for. Betting on one to the exclusion of the other is the mistake.

Where agent-to-agent coordination pays off

The early production wins cluster where work naturally spans systems or organisations.

• Multi-step internal workflows. A request that touches support, billing, and fulfilment, each owned by a different agent, instead of one monolith that has to know everything. This is the practical side of the single-agent versus multi-agent decision: A2A is what lets you split the work cleanly.
• Cross-vendor coordination. Your agent talking to a partner's agent, a supplier's, a logistics provider's, without either side building a bespoke integration for the other.
• Agentic commerce. Buyer-side agents negotiating with seller-side agents, the agent-to-agent commerce pattern that is starting to reshape how stores get discovered.

If none of your agents needs to talk to another agent yet, you do not need A2A yet. The value appears the moment a task has to cross a boundary.

The security question you cannot skip

Opening your agents to messages from other agents is exactly as serious as it sounds. An agent that accepts tasks from peers is a new, externally reachable attack surface, and prompt-injection and capability-confusion risks do not disappear because the caller is "also an agent". Treat an inbound A2A request like any untrusted input: authenticate the caller, scope what each peer is allowed to ask for, and keep a human approval step on anything irreversible. The guardrail practices for securing agents apply directly, and they matter more, not less, once agents start acting on each other's instructions.

What to do about it in 2026

For most teams the honest answer is: prepare, do not rip everything up. Keep your agents modular and well-scoped so that exposing one over A2A later is a small change rather than a rewrite. When you build a new agent, give it a clear, documented capability boundary, the same thing an agent card will eventually advertise. And when you evaluate agent platforms, ask whether they support A2A on their roadmap, because cross-vendor coordination is where this is heading.

The studios and teams that win the next phase will not be the ones with the single smartest agent. They will be the ones whose agents cooperate. If you want help designing an agent architecture that is ready to interoperate without over-engineering it today, talk to us.