Before A2A existed, connecting a Salesforce agent to a ServiceNow agent required a custom connector. Then another one for the next pair. Five agents, ten tools - you're writing fifty bespoke integrations, each one fragile, each one useless the moment a framework version changes. That was the state of multi-agent systems as recently as late 2024.
The Agent2Agent Protocol (A2A) is an open communication standard, developed by Google and released on April 9, 2025, that enables AI agents to discover, authenticate, and delegate tasks to other AI agents across different platforms and frameworks. It has since moved fast enough that the hype is, for once, reasonably proportionate to the technical substance. That deserves a careful look.
What A2A actually does - and what it leaves to you
The protocol has a deliberately small surface area. A2A standardises how one AI agent asks another to do work on its behalf. It defines three things: a way for agents to advertise what they can do, a shape for the tasks they exchange, and a transport for sending those tasks over the wire. That is deliberately a small surface area.
The three primitives worth understanding are Agent Cards, Tasks, and the wire protocol.
Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements - analogous to a service descriptor in microservice architectures.
An Agent Card lives at a well-known URL (/.well-known/agent-card.json) and is the first thing a calling agent fetches before it sends any work.
Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed, and carrying structured payloads that can include text, files, and structured data. That task-state machine is what makes A2A useful for long-running workflows rather than simple synchronous calls.
A2A uses HTTP, SSE, and JSON-RPC 2.0 - with Agent Cards for capability discovery and Tasks for work delegation. The transport choice is intentional: standard web infrastructure means your existing load balancers, gateways, and observability tooling works out of the box.
What the protocol deliberately does not define: retry logic, circuit-breaking, and registry standardisation are left to the implementer. Architects should still expect to engineer application-level workarounds for the gaps named above - per-skill body schemas, token downscoping, registry standardisation - but the protocol itself is no longer a moving target.
The protocol is the wire. Everything above the wire is still your problem.
A2A versus MCP - the distinction that actually matters
A lot of coverage conflates these two. They solve different things.
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. Production multi-agent systems typically use both - A2A routes the task to the right agent; MCP gives that agent the context it needs to execute the task.
A useful way to hold the distinction: MCP is the lower layer - the connection between agents and the tools they need. A2A is the upper layer - the connection between agents themselves. One gives your agents capabilities. The other gives them collaboration.
Concretely: an enterprise supply chain where specialised agents coordinate through A2A while each accesses ERP systems through MCP is the full stack - and that's where production systems are heading.
What changed at v1.0, and why the ACP merger matters
Signed Agent Cards provide cryptographic verification of agent identity and metadata, establishing trust before interaction across organisational boundaries. Improved security posture modernises security flows and removes legacy patterns no longer aligned with current best practices. Together, these changes move A2A from early-adopter implementations toward broader enterprise confidence, especially in regulated or multi-party scenarios.
Before signed cards, a rogue agent could impersonate a legitimate one. Trustwave SpiderLabs researchers demonstrated a significant attack class in 2025: a rogue agent presents an inflated Agent Card with a description crafted to manipulate the orchestrator's LLM-based selection logic. Because most orchestrators choose specialist agents by reasoning over card descriptions, injecting persuasive natural language into a card's description field can hijack task routing. This is a form of prompt injection operating at the infrastructure layer. Signed cards are a direct response to that class of attack, though they are not a complete solution - A2A uses Agent Cards to advertise capabilities and declare supported authentication schemes, but it does not mandate how those cards are verified for authenticity. The protocol delegates credential management entirely to implementers, meaning agent impersonation, card tampering, and replay attacks are real risks without additional controls.
The IBM ACP merger is the other significant event. In September 2025, IBM announced that ACP would officially merge with A2A under the Linux Foundation umbrella. This wasn't an acquisition or abandonment, but a true convergence of efforts.
The merger preserved ACP's RESTful simplicity while incorporating A2A's enterprise-grade features like Agent Cards and task lifecycle management.
IBM's ACP had genuine strengths - simpler REST endpoints, offline-friendly discovery - and some of that DNA is now in A2A. IBM didn't quietly sunset ACP; it actively merged it into A2A, which is a different signal entirely. It's the protocol equivalent of competing network standards consolidating around TCP/IP in the 1990s.
At the April 2026 one-year mark, v1.0 is stable with signed Agent Cards, 150+ orgs running it in production - including Microsoft, AWS, Google, IBM, Salesforce, SAP, ServiceNow, and Deutsche Bank - and native support shipping in Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen, and Microsoft Agent Framework for .NET.
What teams building agents should actually do with this
MCP is the only one that matters for 90% of teams right now. A2A becomes important when you're coordinating agents across organisational boundaries. That framing is honest. If you're still building your first internal agent, A2A is not the blocking problem.
When it does become relevant, the implementation path is cleaner than it was a year ago. A2A v1.0 added cryptographic signatures for Agent Cards, so you can verify an agent is who it says it is, plus multi-tenancy support and multi-protocol bindings. The spec and SDK references live under the Linux Foundation's A2A project on GitHub, which is where the authoritative source of truth sits.
Three things worth holding in parallel as you evaluate:
First, the protocol gap A2A closes is real. 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.
Second, A2A is not a trust system. It is a communication standard. Security - mTLS, token scoping, allowlisting agent identities - is layered on top by you. A2A tells two agents how to talk. Whether they should trust what they hear is your architecture decision.
Third, the governance trajectory matters. The Linux Foundation governance model matters here. It's the same structure that legitimised Kubernetes and OpenTelemetry. Linux Foundation backing signals that A2A is infrastructure, not a product - meant to be depended on by everyone rather than controlled by anyone.
A teammate like Beagle, which lives in Slack and Teams and already handles task routing between humans and automated workflows, will eventually need to speak A2A natively as more of those workflows become agent-to-agent rather than human-to-agent. The protocol is worth understanding now so you're not learning it under deadline pressure when that day arrives.
The spec is stable. The security model still has gaps your team has to close. The ecosystem is real. That's an unusual combination in this space - and worth taking seriously.