Agent2Agent Protocol (A2A)
A2A is a standard way for one AI agent to ask a completely different agent to do something for it. "Completely different" is the important part: built by another team, running on another framework, hosted somewhere you don't control. Instead of every pair of agents needing its own custom integration code, both sides build to the same protocol once.
Booking a hotel room, agent to agent
Say your company's travel-booking agent needs a hotel chain's own agent to check room availability and place a hold — a system the hotel built and runs, not you.
- Your agent fetches the hotel agent's "Agent Card," a published description of what it can do and how to reach it. That's discovery, not a phone call to their engineering team.
- Your agent sends a message describing what it needs: dates, room type, number of guests.
- The hotel's agent opens a task to handle the request. Because it's a real agent and not a fixed function, it can ask back for anything it's missing before proceeding.
- It works the request, possibly sending updates as it progresses — checking availability, then confirming a hold.
- It returns a result: booked, unavailable, or a clarifying question, whichever actually applies.
Neither company had to learn anything about the other's internal framework or codebase. That's what A2A actually standardizes.
A2A vs MCP — different axes, not competitors
The protocol's own blog puts it plainly: MCP is the vertical layer connecting an agent to its own tools and data. A2A is the horizontal layer connecting one agent to another. A single system can use both at once — MCP for what the agent looks up or acts on directly, A2A for the other agents it hands work to.
How this differs from a subagent
A subagent is delegation inside one system you control — the same orchestrator (the program deciding which agent runs and when), usually the same framework, spun up and torn down by the parent agent that owns it. A2A exists for the case a subagent can't cover: an agent you didn't build, don't control the internals of, and can't just call like a function in your own codebase.
Who governs A2A
Google announced A2A in April 2025 with over 50 launch partners. That June, it donated it to the Linux Foundation as an independent, vendor-neutral project, with AWS, Microsoft, Cisco, and Salesforce among its founding members. In August 2026, A2A joined the Agentic AI Foundation, the same neutral home that also governs MCP. The two remain separate, distinct projects rather than one merged standard.
When A2A is the right choice
Reach for A2A when your system needs to hand work to an agent you don't control the internals of. That's a different team's agent, a different vendor's product, or a partner's system entirely. Skip it when every agent involved lives inside one system you own end to end. Plain function calls or the subagent pattern already handle that case, and a cross-organization protocol adds nothing when there's no organizational boundary to cross.
In this guide
FAQ
Do both agents need to use the same model or framework?
No. That's what the protocol is for. Each side can run whatever model, framework, and infrastructure it wants, because the only thing both have to agree on is how they talk to each other. Neither needs to know what the other is built from.
What stops an agent from overstating what it can do in its Agent Card?
Nothing in the protocol itself. An Agent Card is a published claim about capabilities, not a verified guarantee, so treat a remote agent's stated abilities the way you'd treat any external service's documentation: check the result you actually get back rather than assuming the claim held. The same caution that applies to any untrusted external system applies here.