In this guide
  1. Booking a hotel room, agent to agent
  2. A2A vs MCP — different axes, not competitors
  3. How this differs from a subagent
  4. Who governs A2A
  5. When A2A is the right choice

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.

  1. 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.
  2. Your agent sends a message describing what it needs: dates, room type, number of guests.
  3. 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.
  4. It works the request, possibly sending updates as it progresses — checking availability, then confirming a hold.
  5. 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.