Imagine your procurement agent - built on LangChain, maintained by the platform team - needs to hand a price-comparison task to the vendor agent that the supply chain team built on Vertex AI. Today, that handoff is either a human Slack message, a bespoke HTTP call someone wrote six months ago, or a silent failure where the task just stops. Nobody designed a bad system. There was simply no shared language for two agents from different stacks to negotiate work.
That is the exact problem the Agent2Agent protocol was built to address, and last week something significant happened to it: the Linux Foundation announced the launch of the Agent2Agent (A2A) project, an open protocol created by Google for secure agent-to-agent communication and collaboration. This is not a press-release milestone. Handing a protocol to the Linux Foundation is how a vendor signals it wants the standard to outlast its own strategic interests - and that it needs competitors to adopt it sincerely.
What A2A actually does
The protocol is narrower than its name implies, and that narrowness is the point. A2A defines how autonomous AI agents from different vendors and frameworks can discover each other, delegate tasks, and coordinate work without exposing their internal implementation. Three things: discovery, task structure, transport. That's it.
Discovery works through Agent Cards -
agents communicate by first discovering each other through published Agent Cards, JSON files at /.well-known/agent.json advertising capabilities.
The requesting agent authenticates, sends a Task object, and receives structured artifacts in return. Communication can be synchronous, streaming via Server-Sent Events, or asynchronous via webhooks depending on task complexity and duration.
The task object itself has an explicit lifecycle. The communication between a client and remote agent is oriented toward task completion. This "task" object is defined by the protocol and has a lifecycle - it can be completed immediately or, for long-running tasks, each of the agents can communicate to stay in sync on the latest status.
A useful grounding: A2A and MCP are different protocols that solve different problems. A2A handles agent-to-agent coordination - how one agent delegates work to another agent across vendor boundaries. MCP handles agent-to-tool access: how a single agent retrieves context from external data systems and tools. Most production agentic systems will end up using both. MCP wires agents to their tools; A2A wires agents to each other.
Why the Linux Foundation move matters
The A2A protocol is a collaborative effort launched by Google in April and with growing support from more than 100 leading technology companies. But "Google-with-partners" and "Linux Foundation project" are different governance models with different implications for adoption.
The Linux Foundation handover in June 2025 was the inflection point. Before that, A2A was Google's. After, it became the kind of vendor-neutral standard that hyperscalers - AWS, Azure, GCP - and enterprise platforms like Salesforce, ServiceNow, and SAP could adopt without betting on a competitor.
Microsoft welcomed the announcement of A2A as a neutral nonprofit project , which is the diplomatic way of saying Microsoft will now participate in earnest. AWS said the same. Before A2A, enterprise AI teams building multi-agent systems faced a fragmentation problem: agents from one vendor could not reliably hand off work to agents from another vendor using a shared, open standard. Teams could write custom API integrations between specific agents, but every new agent pair required a new bespoke connector. Each framework had its own internal messaging format and task model, and there was no common discovery mechanism.
That last sentence describes a maintenance cliff most teams are already approaching. Every pair of agents that needs to talk is currently a bespoke bridge. Organizations that have more than three or four agents in flight are starting to feel it.
The version that's actually buildable
Google announced the release of version 0.3 of the A2A protocol, which brings a more stable interface to build against and is critical to accelerating enterprise adoption. This version introduces gRPC support, the ability to sign security cards, and extended client-side support in the Python SDK.
The signed Agent Cards deserve attention. Google introduced the ability to sign security cards - this ability is critical for developers and large enterprises, as they won't deploy agents that can't prove their identity cryptographically. Without this, A2A supports but does not enforce Agent Card signing. This allows spoofing by bad actors. Since there is no central registry for Agent Cards and spoofing is inexpensive, forged cards become part of the background noise of low-effort exploits. Signed cards shift that default.
The agent card is the border checkpoint. Without cryptographic signing, any process can claim to be the vendor agent your procurement system trusts.
What this means for a real team
The practical signal here is timing. AI agents are increasingly deployed across departments, products, and partner ecosystems. At that scale, the key question is no longer whether agents can coordinate within one stack, but whether they can collaborate reliably across organizational and platform boundaries. Open protocols determine whether organizations can compose best-of-breed systems or become locked into isolated stacks.
Teams that are still in single-agent territory don't feel this yet. But the moment you have an agent maintained by one team that needs to delegate to an agent maintained by another - or to a vendor-built agent in a SaaS platform - you have the exact coordination problem A2A addresses. The alternative is writing and owning that bridge yourself.
Many teams adopting A2A have struggled with blind spots, like losing track of which agents initiated sensitive operations or where tokens are reused across flows. Without built-in tracing and structured logs, auditing multi-agent systems becomes a fragmented, manual task. A2A's OpenTelemetry-based observability hooks are real, but they require deliberate integration - the protocol surfaces the data, it doesn't route it into your dashboards.
A teammate like Beagle sitting in Slack can help surface agent task status and failures to the humans who care, but the underlying interoperability layer still needs to be right before that visibility is meaningful.
The point is not that A2A solves everything. The protocol is young, signing is optional in v0.3 (and you should make it mandatory yourself), and the multi-agent coordination patterns teams will need haven't fully solidified. Excitement quickly collides with reality. Early adopters report compliance blind spots - who approved that token and when? - latency added by cross-agent orchestration, and the operational overhead of adding another standard into pipelines.
But the Linux Foundation move resolves the one concern that was actually blocking serious adoption: the question of whether this standard belongs to Google or to the industry. It belongs to the industry now. The teams that start understanding the protocol this quarter will be better positioned when the first cross-vendor agent handoff lands on their roadmap - and it will.