For the past two years, most enterprises built AI agents the way they once built early software: in isolation. A support agent here, a finance agent there, each one a silo with its own memory, its own tools, and no way to talk to the others. As soon as a company has more than one agent, the obvious question appears: how do they work together without someone hand-coding a custom integration for every pair?
That is the problem the Agent2Agent (A2A) protocol was created to solve. Google announced A2A on April 9, 2025, and on June 23, 2025 donated it to the Linux Foundation as a vendor-neutral, community-governed standard. By its first anniversary the project had grown to more than 150 organizations, with integrations across Google, Microsoft, and AWS, and shipped its first stable release, A2A v1.0 (with v1.0.1 following on May 28, 2026).
The problem: an integration graph that explodes
The reason a standard matters is combinatorial. If you have n agents and every pair needs a bespoke integration, you are on the hook for roughly n-squared connections. Ten agents is not ten integrations; it is closer to forty-five. This is the same wall that networking hit before TCP/IP and that the web hit before HTTP: without a shared protocol, every connection is a custom project, and the cost of adding one more participant grows until the system stops growing.
Economists have a name for what a standard removes: transaction costs. Ronald Coase argued that the boundaries of a firm are set by the cost of coordinating. A2A lowers the cost of coordination between agents to near zero, which changes what is worth building in-house versus buying from a specialist. When any agent can call any other agent through one protocol, the integration graph collapses from n-squared to n.
How A2A works
A2A rests on a few concepts that map cleanly onto how the web already works.
The Agent Card is how an agent describes itself: a machine-readable document, served at a well-known URL, that lists the agent's skills, endpoints, and authentication requirements. This is discovery. One agent reads another's card the way a browser reads a page, and knows what it can ask for.
{
"name": "invoice-collector",
"version": "1.4.0",
"url": "https://agents.acme.com/invoice-collector",
"skills": [
{ "id": "chase_overdue", "description": "Follow up on overdue invoices" }
],
"authentication": { "schemes": ["oauth2"] },
"capabilities": { "streaming": true, "pushNotifications": true }
}In v1.0, cards can be cryptographically signed (using JWS, RFC 7515, with JSON Canonicalization, RFC 8785), so an agent can verify who it is really talking to.
Tasks are the unit of work. A client agent sends a task to a remote agent, which works on it and streams back updates and results. Tasks have a defined lifecycle, and because they can be long-running, A2A supports streaming and push notifications rather than assuming an instant reply.
Opaque agents are the key design choice. Agents collaborate without exposing their internal memory, prompts, or reasoning to each other. A remote agent is a black box that accepts a task and returns a result. That is what lets a LangGraph agent and a CrewAI agent cooperate without sharing internals or being rewritten.
Version negotiation keeps the ecosystem stable as it evolves: clients send an A2A-Version header, and servers reject incompatible versions explicitly rather than failing in confusing ways.
A2A and MCP are not competitors
The most common confusion is between A2A and the Model Context Protocol (MCP), introduced by Anthropic in late 2024. They solve different halves of the same problem, and the A2A team's anniversary post makes the split explicit: MCP connects an agent to its tools and data (the vertical relationship), while A2A connects an agent to other agents (the horizontal relationship).
Put simply, MCP is how an agent reaches its hands to a database or an API. A2A is how one agent asks another agent to do something. A real system uses both: each agent uses MCP internally to reach its tools, and A2A externally to delegate to peers.
The business case for interoperability
Interoperability is not a technical detail. It is a procurement and strategy decision with three consequences.
First, it removes vendor lock-in. When agents speak a common protocol, you are not trapped in one vendor's ecosystem. You can combine a best-of-breed finance agent from one provider with a CRM agent from another, and replace either without rewiring everything. That optionality is leverage in every negotiation.
Second, it changes buy versus build. If integrating an external specialist agent is a standard protocol call rather than a six-month project, buying a capability becomes realistic where before you would have built a worse version yourself. This is the productivity J-curve in fast-forward: the complementary investment (integration) drops, so value arrives sooner.
Third, it creates an ecosystem, and ecosystems have network effects. The value of a protocol grows with the number of agents that speak it, which is why crossing 150 organizations matters more than any single feature. A capability you cannot build today may simply be a call to someone else's agent tomorrow.
The caveat: interoperability needs an operating layer
A word of caution, because this is where enterprises stumble. Letting agents from different vendors delegate work to each other multiplies capability, but it also multiplies the surface where things can go wrong. An agent you did not build, acting on your data, taking actions in your name, raises exactly the questions we write about constantly: who approved this action, what did it cost, what data did it touch, and can you reconstruct what happened? A protocol solves connectivity. It does not, by itself, solve identity, approvals, cost control, guardrails, or tracing. Those live in the operating layer around the agents, and they matter more, not less, once your agents start talking to agents you do not control.
Conclusion
A2A is doing for AI agents what HTTP did for documents and TCP/IP did for networks: turning a pile of incompatible silos into an interoperable system. The technical mechanics (agent cards, tasks, opaque agents, signed identity) are elegant, but the real story is economic. When coordination between agents becomes cheap, the integration graph collapses, lock-in weakens, and buying beats building more often. The winners will not be the teams with the single best agent. They will be the teams that can safely compose many, and safely is the operative word.
Thinking about how to connect agents across vendors without losing control of approvals, cost, and audit? Book a 30-minute call and we'll map it with you.