The A2A (Agent-to-Agent) Protocol

Introduction

Everything in this section so far has coordinated agents inside one system — a supervisor (L144) and handoffs/shared state (L145) all assume the agents share a codebase, a process, maybe a state object. But the agentic world isn't one codebase. Your support agent is built on LangGraph; your vendor's pricing agent runs on Google's stack; a partner's logistics agent is a black box on their servers. How do agents from different vendors, frameworks, and organizations talk to each other?

They can't share a Python object or call each other's functions. They need a common protocol — and that's A2A (Agent-to-Agent), the open standard for agents to discover, delegate to, and collaborate with one another across any boundary.

If this rhymes with MCP (L137–L142 — The MCP Ecosystem & Security Considerations), that's exactly right: MCP solved the N×M mess of connecting agents to tools; A2A solves the same mess for connecting agents to agents. It's the standardized, cross-organization form of the handoffs and shared context you just met (L145) — now between agents that don't even share a language.

In this lesson:

Why agents need their own protocol — the N×M problem for agents, and opaque peers
The Agent Card — how an agent advertises what it can do, and how others discover it
Tasks, Messages & Artifacts — the unit of work and its lifecycle, streamed over the wire (hands-on)
A2A vs MCP — horizontal meets vertical, and how they compose
Trust across orgs, and the honest question: do you actually need A2A?

Scope: this lesson is the protocol. The economics of all this delegation — coordination & cost — are next (L147 — Coordination & Cost); putting a whole system together is L148 (Designing a Multi-Agent System). Builds directly on L145 (Agent Handoffs & Shared State) (handoffs/shared context) and L137 (The Integration Problem MCP Solves) (the N×M argument).

An infographic titled 'The A2A (Agent-to-Agent) Protocol' showing how AI agents from different vendors and organizations talk to each other. The centerpiece is an auto-repair-shop example drawn as a graph. A customer talks to a Shop Manager agent; the Manager delegates to a Mechanic agent over A2A (a horizontal agent-to-agent link); the Mechanic in turn uses MCP (a vertical agent-to-tool link) to call a diagnostic scanner and a repair-manual database; and the Mechanic uses A2A again to negotiate with a Parts Supplier agent at another company. The key framing is shown as two axes: A2A is horizontal, connecting agents as autonomous peers, while MCP is vertical, connecting an agent down to its own tools and data, and the two are complementary layers used together. A panel explains A2A's building blocks: the Agent Card, a JSON business card served at a well-known URL that advertises an agent's name, skills, capabilities, and security schemes so other agents can discover it; the Task, a unit of work with a lifecycle of submitted, working, input-required, then completed or failed; Messages made of Parts; and Artifacts, the outputs streamed back over Server-Sent Events. It notes the transport is web-standard JSON-RPC 2.0 over HTTP with SSE, that agents are opaque peers exposing only their Agent Card and never their internal logic or tools, and that signed Agent Cards give cross-organization trust. A timeline notes A2A was released by Google in April 2025 and donated to the Linux Foundation under the same Agentic AI Foundation that governs MCP, reaching more than 150 organizations in production by 2026. Cards summarize the rules: A2A connects agents while MCP connects tools, and they compose; an Agent Card is how agents discover each other; and reach for A2A only across real trust boundaries, not inside one codebase. The takeaway: A2A is the open, horizontal standard that lets independent agents discover, delegate to, and collaborate with one another, the agent-to-agent complement to MCP's agent-to-tool layer.

The Problem — Agents Can't Talk Across Systems

Picture the near future: every company ships agents, and the valuable work happens when your agent enlists someone else's. Your travel agent books through an airline's agent; your procurement agent negotiates with a supplier's agent. But each of those agents is built differently — different framework, different model, different company, behind a different API.

Without a standard, every pair needs a bespoke integration: M agent platforms × N agent services = M×N custom connectors, each brittle and each maintained forever. It's the exact wall MCP hit for tools (L137) — and the fix is the same one computing always reaches for: a shared protocol in the middle, collapsing M×N → M+N.

The vision people give it a name: the "internet of agents." Just as HTTP let any browser talk to any server, A2A aims to let any agent talk to any agent — so an agent you've never heard of, written by a company you'll never meet, can do a piece of your work. For that to be safe, agents must stay opaque: you interact through a published contract, never by reaching into each other's code, memory, or tools.

A2A — The Standard

A2A (Agent2Agent) is an open protocol for exactly this. Introduced by Google in April 2025 with 50+ launch partners, it was donated to the Linux Foundation in June 2025 and now lives under the Agentic AI Foundation — the same neutral home as MCP (the connection L142 — The MCP Ecosystem & Security Considerations foreshadowed). By 2026 it's in production at 150+ organizations (Microsoft, AWS, Salesforce, SAP, ServiceNow), routing real tasks between agents on different platforms.

Like MCP, it's deliberately un-exotic — built entirely on web standards so it's easy to adopt:

Transport: JSON-RPC 2.0 messages over HTTP(S), with Server-Sent Events (SSE) for streaming and optional push notifications for long-running or disconnected work.
Design stance: agents are opaque peers (collaborate without exposing internal logic or tools), enterprise-ready (auth, authz, monitoring), async-native (tasks can run for minutes or hours), and modality-independent (text, files, structured data, audio/video).

Three primitives carry the whole protocol — a way to advertise (Agent Card), a unit of work (Task), and the content that flows (Messages → Parts, and Artifacts). The next sections take them in turn.

The Agent Card — Discovery

Before two agents can work together, the client has to find the remote agent and learn what it can do. A2A's answer is the Agent Card: a small JSON document — the agent's "business card" — served at a predictable, well-known URL (https://<host>/.well-known/agent-card.json). A simple HTTP GET retrieves it.

The card advertises everything a caller needs: identity (name, description, version, provider), the url to send requests to, the agent's skills (each with an id, description, and examples), its capabilities (does it support streaming? push?), the input/output modalities it accepts, and its securitySchemes (how to authenticate):

// An AGENT CARD — a remote agent's public "business card", served at a well-known URL:
//   GET https://parts.acme.com/.well-known/agent-card.json
{
  "name": "Acme Parts Supplier",
  "description": "Looks up and orders automotive parts.",
  "url": "https://parts.acme.com/a2a",            // where to send A2A requests
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "defaultInputModes":  ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "securitySchemes": { "bearer": { "type": "http", "scheme": "bearer" } },
  "skills": [
    { "id": "order_parts", "name": "Order parts",
      "description": "Find a part by vehicle + name and place an order.",
      "examples": ["order front brake pads for a 2019 Honda Civic"] }
  ]
}
// A client fetches this, reads the skills, and now knows HOW to call the agent — with
// zero shared code. (v1.2+ cards can be cryptographically SIGNED, so the client can
// verify the card really came from parts.acme.com — the basis of cross-org trust.)

This is discovery as a contract. The client never sees the supplier's code, prompts, or tools — only the card. That opacity is the point: it's what lets agents from rival companies cooperate. And because anyone can host a card, A2A v1.2 added signed Agent Cards — a cryptographic signature proving the card genuinely came from parts.acme.com — which is what makes cross-organization discovery trustworthy rather than just possible.

Tasks, Messages & Artifacts — The Flow

Once it has the card, the client sends a Message (made of Parts — text, a file, structured data). The remote agent decides the request needs real work and creates a Task: a unit of work with a unique id and a lifecycle — submitted → working → (maybe input-required) → completed (or failed/canceled). Because tasks can be long-running, the client subscribes (via message/stream) and the server streams updates back over SSE: TaskStatusUpdate events as the state changes, and TaskArtifactUpdate events carrying the Artifacts — the actual outputs (a chunk of text, a file, structured data).

On the wire it's plain JSON-RPC — request in, a stream of events out:

# A2A rides web standards: JSON-RPC 2.0 over HTTP, with SSE for streaming.
# The client sends a Message; the server creates a TASK and streams its lifecycle back.
POST https://parts.acme.com/a2a            # the `url` from the Agent Card
{ "jsonrpc": "2.0", "id": 1, "method": "message/stream",
  "params": { "message": { "role": "user", "parts": [
      { "kind": "text", "text": "Order front brake pads for a 2019 Honda Civic." } ] } } }

# ← server streams events (Content-Type: text/event-stream) until a TERMINAL state:
#   Task              { id: "t_92", status: { state: "submitted" } }
#   TaskStatusUpdate                   { state: "working" }
#   TaskArtifactUpdate { artifact: { parts: [{ text: "Order #4471 · pads · $89 · ships Tue" }] }}
#   TaskStatusUpdate                   { state: "completed" }   ← stream closes
# The remote agent did the work in ITS system; you got back a structured ARTIFACT —
# no shared memory, no shared codebase, just a task delegated over the wire.

Step through that exchange — discovery, delegation, and the streamed task lifecycle — end to end:

A full A2A exchange between a Shop Manager agent and a remote Parts Supplier agent at another company. Step through it: the client GETs the supplier's Agent Card from its well-known URL, reads its skills, decides to delegate, sends a message/stream request, and then receives the streamed task lifecycle — Task(submitted) → working → an Artifact (the order confirmation) → completed. The point: a remote agent, different company and different codebase, did the work and returned a structured artifact, with no shared memory or code — just a task delegated over the wire.

A2A vs MCP — Horizontal Meets Vertical

The question everyone asks: isn't this just MCP? No — and the distinction is the most important idea in the lesson. They sit on different axes:

MCP is vertical — an agent reaching down to its tools and data (a database, an API, a calculator). Stateless, well-defined capability calls. Agents using capabilities.
A2A is horizontal — an agent reaching across to another agent, a stateful, multi-turn peer that reasons and negotiates. Agents partnering on tasks.

They're complementary layers, and the canonical example shows them composing — an auto repair shop:

A customer talks to a Shop Manager agent (A2A).
The Manager delegates the diagnosis to a Mechanic agent (A2A).
The Mechanic uses MCP to call its own tools — a diagnostic scanner, a repair-manual database (MCP, vertical).
The Mechanic then uses A2A to negotiate parts with a Parts Supplier agent at another company (A2A, horizontal).

The rule of thumb: if the thing you're calling is a tool, use MCP; if it's an agent — an autonomous peer with its own reasoning, ownership, and trust boundary — use A2A. Production multi-agent systems use both: A2A to delegate across agents, MCP inside each agent to reach its tools. "Encapsulating an agent as a simple tool is fundamentally limiting" — a stateful, negotiating peer is not a stateless function call, and pretending otherwise is what A2A exists to fix.

Opaque Peers & Cross-Org Trust

A2A's defining stance — agents are opaque — is also its security model. A remote agent never exposes its prompts, memory, model, or tools; you interact only through its Agent Card and the tasks you exchange. That's what makes it safe to call an agent run by a company you don't control: there's a narrow, declared contract and nothing else leaks.

Trust is handled as part of that contract:

Discoverable auth. The Agent Card declares its securitySchemes (Bearer/OAuth/API-key) and which are required — the client learns how to authenticate before it ever sends a task.
Signed Agent Cards (v1.2+). A cryptographic signature lets the caller verify the card truly belongs to that domain — without it, cross-organization discovery isn't defensible (anyone could publish a card claiming to be your bank's agent).
Auditable delegation. Every task has an id and a lifecycle, so a delegation across orgs is recoverable and loggable — you can see what you asked for and what came back.

This is a different trust problem from MCP's (L142). There, the risk was an untrusted server/tool poisoning your agent. Here, you're handing a task to a peer across an org boundary — the questions are identity (is this really their agent?) and containment (it sees only what the task carries, never your internals). Opacity plus signed cards is A2A's answer.

The Honest Question — Do You Actually Need A2A?

A2A is real infrastructure, but it's also been over-reached for, so be precise about when it earns its keep:

Most systems don't need it. If your agents live in one codebase, a supervisor or handoffs + shared state (L144–L145 — Agent Handoffs & Shared State) is simpler, cheaper, and easier to debug — no HTTP, no discovery, no auth. Many 2025 "A2A" demos really needed better prompts, tools, retries, and logs.
It earns its keep across real boundaries. A2A pays off when agents are genuinely independent systems — different owners, different tools, separate trust boundaries — that must collaborate without sharing code. Cross-org and cross-team is the sweet spot; inside one app, it's overhead.
It standardizes wiring, not economics. A2A defines how agents talk, but not how to attribute, cap, or refuse cost when your agent delegates to a paid one — teams build that telemetry on top. (That's exactly the subject of the next lesson, L147 — Coordination & Cost.)

Same discipline as the whole section: reach for the protocol when the boundary is real. Inside your own system, coordinate with the in-process tools of L144–L145 (Supervisor / Hierarchical Architectures → Agent Handoffs & Shared State); cross an organizational line, and A2A is how you do it without bespoke glue.

🧪 Try It Yourself

Reason these through, then check with the flow stepper:

Your agent needs to (a) query your Postgres database and (b) delegate a sub-task to a partner company's logistics agent. Which protocol for each, and why?
What's the first thing a client does to work with a remote agent it's never met, and at what URL?
A task will take ten minutes to finish. Which A2A feature lets the client follow progress instead of blocking, and what events does it receive?
Why can't you just wrap the partner's agent as an MCP tool and call it a day? Give the core reason.
A teammate wants to use A2A between three agents that all live in the same Python service. Talk them out of it (or into it) — when is that wrong?

→ (1) (a) MCP — the database is a tool (vertical, capability call); (b) A2A — the logistics agent is an autonomous peer in another org (horizontal, task delegation). Production uses both. (2) GET the Agent Card at https://<host>/.well-known/agent-card.json — it advertises skills, capabilities, and securitySchemes, so the client learns how to call the agent. (3) Streaming via message/stream over SSE (or push notifications): the client receives TaskStatusUpdate events (submitted → working → completed) and TaskArtifactUpdate events (the outputs) until a terminal state. (4) An agent is a stateful, multi-turn, reasoning peer with its own ownership and trust boundary — "encapsulating an agent as a simple tool is fundamentally limiting"; MCP's stateless capability-call model can't express delegation, negotiation, or long-running tasks. (5) Inside one service it's usually wrong — you'd add HTTP, discovery, and auth overhead for agents that could just share a function call or state object (L144–L145 — Agent Handoffs & Shared State). A2A earns its keep across real trust boundaries (different owners/systems), not inside one codebase.

Mental-Model Corrections

"A2A is a competitor to MCP." They're complementary axes: MCP is vertical (agent → tools), A2A is horizontal (agent → agent). Real systems use both; an agent uses A2A to delegate, then MCP to reach its own tools.
"A2A means agents share their memory/code." The opposite — agents are opaque peers. You see only the Agent Card and the tasks you exchange; internals never leak. That opacity is what makes cross-org collaboration safe.
"It's a Google product." It started at Google (Apr 2025) but is now a vendor-neutral standard under the Linux Foundation (Agentic AI Foundation — MCP's home too), in production at 150+ orgs.
"A2A is a new transport / a new model API." It's JSON-RPC over HTTP with SSE — boring, proven web standards. The novelty is the agent semantics (Agent Card, Task lifecycle, Artifacts), not the pipes.
"I should use A2A for the agents in my app." If they share a codebase, don't — use a supervisor or handoffs (L144–L145 — Agent Handoffs & Shared State). A2A is for crossing real system/org boundaries.
"Discovering an agent means trusting it." Discovery (the card) and trust (signed cards + securitySchemes) are separate. A signed card proves identity; auth schemes gate access. Verify before you delegate.

Key Takeaways

A2A is the open standard for agents to talk to agents — across frameworks, vendors, and organizations. It solves the N×M integration problem for agents, exactly as MCP did for tools (L137).
Built on web standards: JSON-RPC 2.0 over HTTP, SSE for streaming, push for async. Google (Apr 2025) → Linux Foundation / Agentic AI Foundation (same home as MCP); 150+ orgs in production by 2026.
Three primitives: the Agent Card (a JSON "business card" at /.well-known/agent-card.json — skills, capabilities, securitySchemes — for discovery), the Task (a unit of work with a lifecycle: submitted → working → completed), and Messages/Parts → Artifacts (the content and outputs, streamed back).
A2A vs MCP = horizontal vs vertical, and they compose: agents partnering (A2A) vs agents using capabilities (MCP). An agent uses A2A to delegate to a peer; that peer uses MCP for its own tools (the repair-shop example).
Agents are opaque peers. You interact through the Agent Card and tasks only — never internals. Signed cards + discoverable securitySchemes make cross-org trust workable.
Reach for A2A only across real boundaries. Inside one codebase, a supervisor or handoffs (L144–L145 — Agent Handoffs & Shared State) is simpler. A2A standardizes the wiring, not the cost of delegation.
Next — L147: Coordination & Cost — the economics and overhead of all this delegation: tokens, latency, and how multi-agent coordination is paid for.