A2A Protocol (Agent2Agent)

How independent AI agents talk to each other, explained for a developer new to the agent world. This is the third note in a sequence: LLM Tool Calling (how a model calls a function), Model-Context-Protocol-MCP (how tools are published so any app can use them), and now A2A (how whole agents delegate work to other agents). Read those two first — the contrast with MCP is most of what makes A2A click.

1. The problem A2A solves

MCP answered “how does my agent reach tools?” But some capabilities aren’t tools — they’re other agents: a travel-booking agent run by an airline, a background-check agent run by a vendor, a research agent run by another team. You don’t own them, you can’t import them, and they aren’t functions — they’re autonomous systems with their own models, their own tools, and their own opinions about how to do the job.

Could you wrap another agent as a tool and call it through MCP? Sometimes, and people do. But a tool call assumes the wrong shape for agent work:

A tool call is request → response in one shot. An agent-sized job (“find me three candidate flights and hold the best one”) may run for minutes or days.
A tool never asks you anything. An agent may need clarification mid-task (“the 6 a.m. departure saves $200 — acceptable?”).
A tool returns one value. An agent produces artifacts — documents, bookings, reports — possibly several, possibly streamed as they’re ready.
A tool is code you trust in-process. A remote agent belongs to someone else — it needs discovery, authentication, and a real network boundary.

A2A (Agent2Agent) is an open protocol for exactly that shape: delegating a task to a remote agent you don’t control, and managing its lifecycle. Google introduced it in April 2025; like MCP, it now lives vendor-neutral under the Linux Foundation. The two protocols are deliberately complementary, and the standard shorthand is worth memorizing: MCP is vertical (an agent reaching down to its tools and data), A2A is horizontal (an agent reaching across to a peer).

2. The two roles

Every A2A interaction has a client agent (the one that needs work done — the requester) and a remote agent (the one advertising a skill — the provider). These are roles, not identities: the same agent can be a client in one conversation and a remote agent in another, exactly like a program can be both an HTTP client and an HTTP server.

Crucially, the remote agent is opaque. The client sees its advertised skills and its results — never its model, its prompts, its tools, or its internal state. That’s a feature: an airline will let your concierge agent book flights; it will not show you how its pricing agent thinks. Compare MCP, where the client sees every tool schema in detail. A2A’s unit of exchange is the task, not the capability internals.

3. Discovery: the Agent Card

How does a client agent even find out what a remote agent can do? Every A2A agent publishes an Agent Card — a JSON document at a well-known URL on its domain (/.well-known/agent.json, the same convention as robots.txt or /.well-known/security.txt). The card is the agent’s résumé:

{
  "name": "flight-booking-agent",
  "description": "Searches, holds, and books commercial flights.",
  "url": "https://agents.example-airline.com/a2a",
  "skills": [
    {"id": "search_flights", "description": "Find flights matching route, dates, budget."},
    {"id": "book_flight", "description": "Hold or purchase a specific fare."}
  ],
  "capabilities": {"streaming": true, "pushNotifications": true},
  "authentication": {"schemes": ["oauth2"]}
}

A client fetches the card, decides whether the skills fit, authenticates per the card’s requirements, and starts sending tasks. It’s service discovery in the DNS-SD/mDNS spirit — “here’s what I offer and how to reach me” — but for agent skills. Note the parallel with everything else in this sequence: the descriptions are prompts. A client agent’s model chooses remote agents by reading these cards, so a vague card means your agent never gets picked.

4. The unit of work: the Task

Where MCP’s central verb is tools/call (an instant), A2A’s central noun is the task (a lifecycle). A client sends a message (“book me SFO→AUS on the 14th, under $400”) and the remote agent creates a task with an ID and a state that moves through:

submitted → working → completed
                    ↘ failed / canceled
          ↘ input-required ↗

input-required is the state that makes A2A more than RPC: the remote agent can pause and ask the client a question (“only red-eye flights are under $400 — proceed?”), the client answers, and work resumes — a genuine multi-turn conversation between agents, tied to one task ID. Results arrive as artifacts (documents, structured data, images — anything), and messages/artifacts are built from typed parts (text, file, data), so the protocol is multimodal from the ground up.

Because tasks can be long-running, the protocol has three delivery modes matched to duration, and the systems analogies are exact:

Duration	Mechanism	Analogy
Seconds	Synchronous request/response	a blocking function call
Minutes	SSE streaming — server pushes status/artifact updates over a held-open HTTP connection	`tail -f` on the task
Hours/days	Push notifications — remote agent calls a webhook URL you registered when the state changes	“don’t call us, we’ll call you” — an interrupt instead of polling

5. The wire, briefly

Transport is JSON-RPC 2.0 over HTTPS — same message format as MCP, different vocabulary (message/send, tasks/get, tasks/cancel instead of tools/list, tools/call). Authentication rides on standard web machinery (OAuth2, API keys, mTLS) as declared in the Agent Card, which is exactly what you want: agent-to-agent security reduces to web-service security, a solved problem, rather than something novel.

6. A worked example

Your travel-concierge agent (client) gets: “Get me to Austin for the conference, cheap.”

It already knows (or discovers) the airline’s Agent Card, checks skills, authenticates via OAuth2.
Sends message/send → the airline agent opens task T1, state submitted, then working. Internally that agent uses MCP to hit its fare-search tools — vertical and horizontal composing, invisible to your concierge.
Your concierge subscribes to SSE updates; partial results stream in as artifacts (three candidate itineraries).
Task flips to input-required: “Cheapest option departs 5:50 a.m. Confirm?” Your concierge — depending on its autonomy rules — answers itself or bubbles the question up to you.
On “yes,” state returns to working, then completed, with a booking-confirmation artifact. Your concierge moves on to the hotel agent.

Notice what the protocol bought: neither side shared internals; the long wait didn’t block anyone; the mid-task question had a first-class home instead of being crammed into a tool-return value.

7. A2A or MCP? The decision rule

The line “agent vs. tool” is genuinely blurry — anything with an API can be wrapped either way. A practical rule:

Request/response, stateless, you own or trust it in-process → tool (MCP).
Long-running, needs clarification mid-flight, produces artifacts, owned by someone else → agent (A2A).

And a caution learned from every premature-abstraction story: if you have one application and everything it needs fits in tools, you need neither protocol beyond what your framework gives you. A2A pays off at organizational boundaries — different vendors, teams, or trust domains — the same way MCP pays off at application boundaries.

8. Security: the boundary is the point

Everything a remote agent sends is untrusted input. Its messages and artifacts flow into your agent’s context, so the prompt-injection lesson from LLM Tool Calling §7 and MCP tool poisoning applies with more force — you’re ingesting output from someone else’s model, which may itself have been manipulated. Treat inter-agent traffic like user-supplied data, always.
Delegation is a trust decision. input-required means a remote agent can ask your agent questions — including leading ones. Decide policy up front: which questions your agent may answer autonomously, and which must surface to a human.
Authenticate both directions and pin your peers. The Agent Card tells you how to authenticate to the remote agent; you still need to decide which agents you’ll talk to at all. An open client that discovers and trusts arbitrary cards is the agent version of piping curl into sh.
The ecosystem is young. MCP had a year’s head start and orders of magnitude more deployment; A2A implementations and security tooling are correspondingly less battle-tested. Design as if bugs exist, because they do.

9. Where this goes next

The vertical half it composes with: Model-Context-Protocol-MCP.
The foundation both build on: LLM Tool Calling.
Multi-agent systems built without a cross-vendor protocol (one framework orchestrating its own agents in-process — the common case today): LangGraph vs CrewAI Research.
A shipping consumer example of both protocols composing: Gemini Spark uses MCP vertically (OpenTable, Canva, Instacart connectors) and A2A horizontally (talking to other specialized agents).