What Is the Agent2Agent Protocol?
Tools are one half of an agent's world and other agents are the other half, and A2A is the open standard that lets agents built by different teams, in different frameworks, discover and delegate to each other as peers.
The Model Context Protocol solved how an agent reaches its tools and context. But agents increasingly need something else: to work with other agents — a scheduling agent handing off to a travel agent, a research agent delegating to a coding agent, agents built by different vendors in different frameworks collaborating on one goal. The Agent2Agent protocol (A2A) is the open standard for exactly that. This post opens a series that builds A2A up from first principles; here we cover the problem it solves, where it came from, and the mental model that makes the rest click.
The problem: agents that cannot talk to each other
Inside one framework, getting two agents to cooperate is easy — they share a runtime, memory, and types. Across frameworks and organizations, it is a mess. An agent written with one vendor’s SDK has no standard way to discover an agent hosted by another company, learn what it can do, hand it a task, or receive the result. Every integration is bespoke, and the moment you want a third agent, the wiring grows again. It is the same M×N problem MCP faced, one level up: instead of apps × tools, it is agents × agents.
A2A standardizes the seam between agents. An agent exposes an A2A interface once; any A2A-speaking client agent can then discover it, understand its capabilities, delegate tasks to it, and collect results — regardless of what framework or model powers either side. Collaboration becomes additive instead of combinatorial.
Where A2A came from
A2A was introduced by Google in 2025 and shortly after donated, along with its specification and SDKs, to the Linux Foundation, which now governs it as a vendor-neutral open project. It has since gathered broad industry support — many organizations and major cloud platforms back it — and reached a 1.0 specification. The governance detail matters for adoption: a protocol meant to connect agents from competing vendors is far more credible as a neutral standard than as one company’s format. That is the same logic that made MCP an open protocol, applied to the agent-to-agent layer.
The mental model: client agent and remote agent
A2A has two roles in any interaction, and they are relational, not fixed:
- A client agent initiates — it wants something done and reaches out.
- A remote agent (an A2A server) receives the request, does the work, and responds.
The same agent can be a remote agent in one conversation and a client agent in another, delegating onward. A2A does not impose a hierarchy; it defines how any two agents exchange work.
Crucially, A2A treats remote agents as opaque. A client agent does not need to know the remote agent’s internal prompts, tools, memory, or model — only its advertised capabilities and how to talk to it. This opacity is a deliberate feature: it lets organizations collaborate without exposing proprietary internals, and it lets each agent evolve independently behind a stable interface. You interact with what an agent offers, not how it works.
What A2A defines
The rest of the series unpacks each piece, but here is the shape of the standard:
- Agent Cards — how an agent advertises its identity, capabilities, skills, endpoint, and authentication requirements, so others can discover and understand it.
- Tasks — the unit of work, with a defined lifecycle (submitted, working, completed, and more) that supports long-running, asynchronous collaboration, not just quick request/response.
- Messages, Parts, and Artifacts — the content model for what agents send each other and the outputs they produce, including multi-modal content.
- Transports and methods — A2A is binding-flexible (JSON-RPC 2.0 over HTTP, gRPC, and HTTP+JSON/REST) with a consistent set of operations like sending a message and getting a task.
- Streaming and push notifications — real-time updates over Server-Sent Events and webhook callbacks for long-running work.
- Security — enterprise-grade authentication declared in the Agent Card and enforced on every request.
A2A and MCP are complementary, not competing
The single most common point of confusion is worth settling immediately: A2A does not replace MCP, and they are not rivals. They operate at different layers.
- MCP connects an agent to its tools and context — the model reaching functions, data, and resources.
- A2A connects an agent to other agents — peers delegating tasks to one another.
A mature system uses both. An agent might use MCP to call a database and a code interpreter, and use A2A to hand a subtask to a specialist agent in another department. Tools are things an agent uses; agents are collaborators it delegates to. The final post in this series builds a system that uses the two together, because in practice that is how they show up.
Where the series goes
From here we go component by component: Agent Cards and discovery, tasks and their lifecycle, the message/part/artifact content model, transports and methods, streaming and push notifications, security and authentication, and finally A2A and MCP working together in one architecture. By the end you will understand how independent agents find each other, delegate work, and collaborate securely across organizational and framework boundaries.
Key takeaways
- A2A solves the agent-to-agent version of MCP’s integration problem: instead of apps × tools, it standardizes agent × agent collaboration so cooperation is additive, not combinatorial.
- It was introduced by Google in 2025 and donated to the Linux Foundation, which governs it as a neutral open standard now backed by many organizations and cloud platforms.
- Interactions have a client agent (initiator) and a remote agent (server); roles are relational, and remote agents are treated as opaque — you use what they advertise, not their internals.
- A2A defines Agent Cards (discovery), Tasks (lifecycle), Messages/Parts/Artifacts (content), flexible transports, streaming/push updates, and security.
- A2A and MCP are complementary: MCP connects agents to tools and context, A2A connects agents to each other, and real systems use both.