A2A: How AI Agents from Different Vendors Coordinate

You have wired one agent to your tools and it works. Then a client asks whether your agent can hand a task to their agent, built on a different framework, and you realize the two have no shared language for it. That gap is exactly what the A2A protocol was built to close, and in its first year it has gone from a Google announcement to a Linux Foundation standard with real production use.

What is the A2A protocol and why does it matter?#

The A2A protocol is an open standard that lets AI agents from any framework discover each other and exchange tasks, regardless of platform or vendor. Google built it in April 2025 and handed governance to the Linux Foundation, which reported on 9 April 2026 that it had passed 150 production organizations in its first year.

That matters because the agent world is fragmenting fast. You might build on one framework, your client on another, and a vendor on a third, and until A2A there was no shared way for those agents to talk. A2A gives them a common handshake, so an agent can advertise what it does and accept work from an agent it has never met. According to the Linux Foundation announcement dated 9 April 2026, the project also reached 22,000-plus GitHub stars and shipped SDKs in five production languages (as of early July 2026, verify before relying).

One agent reads another's Agent Card, hires it, and gets a result back, across frameworks. Model of the A2A discovery flow per the Linux Foundation

How does one agent discover and hire another over A2A?#

Discovery runs through an Agent Card, a small published document that describes what an agent can do and how to reach it. One agent reads another agent's Card, decides it is the right fit, and then sends a task over the protocol. The second agent works the task and returns the result, all across a framework boundary.

The Agent Card is the piece that makes cross-vendor coordination tractable. Instead of hardcoding an integration, your agent looks up capabilities the way a client looks up a contractor's profile before sending work. In the April 2026 v1.0 stable release, Agent Cards can be signed, so a consuming agent can verify the Card came from who it claims, per the IBM overview of the Agent2Agent protocol (as of early July 2026, verify before relying).

A2A vs MCP: which one do you actually need?#

They solve different problems and are complementary, not competing. MCP connects a single agent to its tools and data, so it can read a database or call an API. A2A connects one agent to other agents, so agents built by separate teams can hand work back and forth. Most small builders reach for MCP first.

MCP is an agent's link to tools and data; A2A is its link to other agents. Complementary, not competing, per the Linux Foundation and IBM, as of early July

The clean mental model, stated plainly in both the Linux Foundation announcement and the IBM overview, is that MCP is an agent's connection to capabilities while A2A is an agent's connection to peers. A team shipping one agent that queries a CRM needs MCP. A team stitching a sales agent, a support agent, and a partner's agent into one flow is where A2A starts to earn its place. You will often use both together.

Is A2A production-ready in mid-2026, and who backs it?#

By April 2026 A2A reached v1.0 stable and picked up real platform backing. The same release added signed Agent Cards and the Agent Payments Protocol (AP2), and the protocol gained generally available support inside Microsoft Copilot Studio, Azure AI Foundry, and Amazon Bedrock AgentCore. Those are not experiments; they are shipped integrations from the major clouds.

Momentum, not a quality score. All three figures per the Linux Foundation announcement dated 9 April 2026 (as of early July 2026, verify before relying).

The adoption numbers below are a signal of momentum, not a quality score, and you should read them that way. Per the Linux Foundation announcement dated 9 April 2026, the project cleared 150 production organizations, 22,000-plus GitHub stars, and five SDK languages in its first year. AP2 in particular hints at where this is going, since agents that transact on your behalf need a payments layer, per Galileo's A2A guide (as of early July 2026, verify before relying).

Table: key A2A facts, per the Linux Foundation announcement dated 9 April 2026 and IBM's overview (as of early July 2026, verify before relying).

Do you actually need A2A yet on a small team?#

Probably not today, and that is a fair answer. A2A pays off when you have multiple agents, often from different teams or vendors, that must coordinate. If you run one agent that calls a few tools, MCP covers you and A2A is overhead. The honest test is whether a second, independent agent is really in your flow.

Start from whether a second independent agent is really in your flow; most small teams land on MCP first. Reasoned from the A2A and MCP mechanics, as of early

For a solopreneur on n8n, the practical path is tools first. n8n already has an MCP Client Tool node to connect an agent to tools, which is the more common need, and our walkthrough of n8n with MCP shows where that lives. When you genuinely reach several agents handing work to each other, our multi-agent orchestration guide is the next step, and A2A becomes the standard worth watching for cross-vendor coordination.

Where does A2A leave a small builder today?#

A2A is a genuine standard now, Linux Foundation-governed, v1.0 stable, and live in three major cloud platforms as of April 2026. For most small teams the near-term move is still MCP for tools, with A2A as the coordination layer you adopt once a second independent agent enters your flow.

The reason to track it now, even before you need it, is that cross-vendor agent coordination is where the market is heading, and the plumbing is being standardized in the open. If you are mapping your own agent tooling, our MCP servers solopreneur guide covers the tools side of that same picture, so you can add A2A later without rework.