Picture a procurement task that should be simple. A buying agent inside one company needs a quote, a lead time, and a compliance attestation from a supplier. The supplier runs its own agent. The buying agent was built on LangGraph and runs on Google Cloud. The supplier's agent was built with CrewAI and runs on AWS. They have never met. There is no shared codebase, no shared employer, no human in the room to translate.
How do they talk?
Until early 2025, the honest answer was that they did not. Every cross-vendor agent integration was a bespoke project: a custom API, a custom message shape, a custom way to ask one agent what it could even do. Two agents talking was a software project, not a feature. That is the gap the Agent2Agent protocol set out to close, and it is a different gap from the one MCP closed. MCP standardised how an agent reaches a tool. A2A standardises how an agent reaches a peer.
Origin: why agents needed their own protocol
The Model Context Protocol solved one half of the interoperability problem. It gave an agent a standard way to call a database, a file store, or an API. But a tool is a passive thing. It does not plan, it does not hold its own context, it does not push back. You call it and it returns.
Another agent is not passive. It reasons, it keeps state across a long task, it may need to come back with a clarifying question, and it might take minutes or hours to finish. Treating a peer agent as if it were a tool throws away everything that makes it an agent. You cannot model a multi-step negotiation as a single function call. So the industry had a second integration problem, structurally similar to the one MCP faced and just as expensive: without a shared standard, connecting agent A to agent B is a one-off, and connecting M agents to N agents is M times N one-offs that never compound.
Google moved first. On April 9, 2025, at Google Cloud Next, it announced A2A as an open protocol for agent-to-agent communication, with more than 50 partners signed on at launch, including Atlassian, Box, Cohere, Intuit, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and Workday, plus the major consultancies. Google was explicit that A2A was not a rival to MCP. It described A2A as a protocol that complements Anthropic's MCP, which supplies tools and context to a single agent. Two layers, two problems.
The design followed five stated principles. Build on existing web standards rather than invent new ones. Be secure by default. Support long-running tasks, not just quick request and response. Stay modality agnostic, so agents can exchange text, files, and structured data or even audio and video. And, the one that matters most, embrace agentic capabilities: let agents collaborate without forcing them to share memory, tools, or internal reasoning. That last principle is the whole philosophy. An agent should be able to use another agent the way you use a contractor, by its declared output, not by reading its mind.
Present: how A2A works, and how far it has spread
Strip A2A to its parts and three ideas carry the protocol.
The first is the agent card. Every A2A-capable agent publishes a small JSON document, by convention at https://{domain}/.well-known/agent-card.json, that describes itself: its identity, its skills, its service endpoint, which content types it handles, and which authentication schemes it requires. The card is how an agent answers the question "what can you do" before any work begins. It is the equivalent of a service finding out another service's API shape, except the consumer is an autonomous agent reading it at runtime.
The second is the task. A2A is task-centric, not message-centric. When one agent delegates work, it opens a task with a server-generated ID, and that task moves through a defined lifecycle: submitted, working, then a terminal state of completed, failed, rejected, or canceled, with two interrupt states, input-required and auth-required, for when the task needs a human answer or a credential mid-flight. This is the part that treats a peer as a peer. A task can run long, it can pause to ask a question, and the calling agent can subscribe for streaming updates or register a webhook to be notified later. Results come back as artifacts, kept deliberately separate from the conversational messages, so the data output and the chatter never get confused.
The third is opaque execution. Two agents collaborate purely on declared capabilities. The supplier's agent never has to expose its prompts, its model, its tools, or its plan. It accepts a task and returns a result. For enterprises this is the part that makes A2A usable: you can call a partner's agent without auditing its internals or trusting it with yours, the same way you consume a SaaS API without seeing its source.
Underneath, A2A is deliberately boring technology. It runs over HTTP, with bindings for JSON-RPC 2.0, gRPC, and plain REST, and it reuses Server-Sent Events for streaming. Security is not bolted on: the agent card declares standard schemes, API keys, HTTP bearer tokens, OAuth 2.0, OpenID Connect, or mutual TLS, and the spec is firm that an agent card must not carry static secrets. Picking proven standards over novel ones is the same bet MCP made, and it is why a backend team can read the spec and recognise everything in it.
The adoption curve says the bet worked. On June 23, 2025, Google handed A2A to the Linux Foundation, which launched the Agent2Agent Protocol Project with founding members AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow. That puts A2A under neutral governance, the same move MCP made when Anthropic donated it to the Linux Foundation's new Agentic AI Foundation in December 2025. Both protocols the agent stack leans on are now stewarded by a body with no model to sell. By its first anniversary, the Linux Foundation reported A2A had passed 150 supporting organisations, up from 50 at launch, with the core repository over 22,000 GitHub stars and SDKs across five languages: Python, JavaScript, Java, Go, and .NET. The project shipped a production-ready spec and landed inside Microsoft Azure AI Foundry and Copilot Studio, Amazon Bedrock AgentCore, and Google Cloud. Production use shows up in supply chain, financial services, insurance, and IT operations, where companies use it to coordinate agents across vendors they do not control.
A standard authored by one cloud vendor and adopted by its direct rivals is the strongest signal a standard can give. Fragmenting the market with a competing protocol was the obvious move, and AWS, Microsoft, Cisco, and the rest declined it.
A2A and MCP: peers versus tools, not a contest
Because both arrived inside a year and both standardise agent communication, A2A and MCP get framed as competitors. They are not. They are layers.
MCP is vertical. It connects one agent down to its tools and data through a host-client-server model: structured, typed, auditable tool access. A2A is horizontal. It connects agents across to one another as peers, handling discovery, delegation, and long-running task coordination. The clean way to hold it: MCP is how an agent uses a tool, A2A is how an agent works with a colleague.
A single workflow uses both. DigitalOcean's worked example is a good one. A support orchestrator agent receives a customer issue and, over A2A, delegates the billing question to a billing agent, the defect to a technical agent, and the refund to a policy agent. Each specialist then uses MCP internally to reach its own CRM, policy store, or shipping API. A2A routes the work between agents; MCP fetches what each agent needs to do that work. Pull either layer out and the system breaks in a different place. This is also why the multi-agent debate and A2A are connected but separate questions: the debate is about whether to split a job across agents at all, while A2A is the wire those agents use once you have, especially when they were built by different teams.
Future and impact: the Internet of Agents, and the parts that are not solved
Stack the pieces and a picture appears that the industry has started calling the Internet of Agents: not one monolithic assistant, but a web of specialised agents that discover each other, delegate, and transact across organisational lines, the way websites link across domains today.
The commercial stakes are large enough that analysts have put numbers on them. Gartner predicts that by 2028, 90 percent of B2B buying will be agent-intermediated, with agents negotiating, contracting, and executing more than 15 trillion dollars of spend at high frequency and with minimal human involvement. If that is even directionally right, the buyer in most B2B transactions stops being a person clicking through a portal and becomes an agent calling another agent. Procurement cycles that took weeks compress toward minutes. A market that size cannot run on bespoke point-to-point integrations, which is the entire argument for a protocol.
Payment is moving to meet it. In September 2025, Google and Coinbase, with more than 60 launch partners including Mastercard, American Express, and PayPal, introduced the Agent Payments Protocol, AP2, an A2A extension that lets agents settle transactions with a verifiable, cryptographically signed trail of user authorisation. Cisco's AGNTCY project, donated to the Linux Foundation in July 2025, is building the discovery, identity, messaging, and observability layers, an agent directory and a decentralised identity scheme among them, that a genuine Internet of Agents needs and that A2A on its own does not provide.
That last clause is the honest part, and a practitioner should sit with it. A2A is real and useful, but the vision around it has open holes.
Trust is the first. When agent A reads agent B's card, A2A gives it no protocol-level way to verify the card is authentic or that B is who it claims. The protocol was designed for communication, and credential provisioning and identity verification sit, by the spec's own admission, outside its scope. Cards can be signed, but a signature proves a key, not a trustworthy counterparty.
Discovery is the second. The well-known URI works when you already know the domain. It does not answer the open question, "find me any agent, anywhere, that can do X." A2A explicitly does not standardise a registry API, which leaves the actual discovery layer to AGNTCY, to private catalogs, and to vendors, and an unstandardised discovery layer is a fragmentation risk all over again.
Security compounds both. A2A's discovery can be turned around by an attacker to locate agents and probe the MCP tools behind them. A malicious agent can advertise capabilities it does not safely have. The point-to-point HTTP model grows brittle as the agent count climbs.
Accountability is the hardest, because it is not a protocol problem at all. When an autonomous buying agent commits a company to a contract and the deal goes wrong, who is liable? The agent's vendor, the framework, the deploying company, the human who set the agent's goal weeks earlier? AP2's authorisation trail is a start, but the legal and governance answers lag the technical ones badly. Push that question across the trillions of dollars Gartner expects to flow through agents and it stops being a footnote.
None of this is a reason to dismiss A2A. It is a reason to be precise about what it is. A2A solved the syntactic problem, the wire format for one agent to call another across a vendor boundary, and solved it well enough that the major clouds standardised on it inside a year. The semantic problems, trust, discovery at scale, and accountability, are still open, and they are where the next few years of work will go. For teams putting multi-agent systems into production now, the practical read is the same as it was for MCP: build on A2A, because it is the settled wire, and treat trust and identity as your own responsibility on top of it, because the protocol does not yet carry them. The Internet of Agents is being wired. It is not yet governed.
Council summary
This post argues that A2A is the missing horizontal layer of the agent stack: where MCP standardised how one agent reaches its tools, A2A standardises how one agent reaches a peer built by someone else, and that distinction is the difference between a single capable agent and an Internet of Agents. It traces a clean arc, from Google's April 2025 launch through the Linux Foundation handover to production use across 150-plus organisations, and it earns trust by being concrete about the mechanics: the agent card, the task lifecycle, opaque execution, and a deliberately boring HTTP transport. Its strongest move is refusing to oversell. The closing section is precise that A2A solved the syntactic problem of agent-to-agent calls while trust, discovery at scale, and accountability remain open, with AGNTCY and AP2 named as the work filling those gaps. The reader's takeaway is practical and unambiguous: build on A2A now because it is the settled wire, but own identity and trust yourself, because the protocol does not yet carry them.
Comments