The A2A protocol: how it works, step by step, and how it compares with MCP

AI systems are no longer just a single model answering questions. We now build specialised agents (an HR agent, a booking agent, a code-review agent), often developed by different teams, on different frameworks (LangGraph, CrewAI, ADK, OpenAI Agents SDK…), and hosted by different providers. That raises a new question: how do these agents talk to each other?

That is the question A2A (Agent2Agent) answers. This article introduces the protocol, walks through how it works step by step, and then compares it with MCP (Model Context Protocol), with which it is often confused.

Contents

1. What is A2A?
2. History and governance
3. Key concepts
4. A three-layer architecture
5. How it works, step by step
6. Task lifecycle
7. Security
8. A2A vs MCP
9. Using A2A and MCP together
10. Current limitations and best practices
11. Conclusion

1. What is A2A?

A2A is an open specification that defines how independent AI agents:

• discover each other (who can do what, and how to reach them),
• delegate tasks to one another, including long-running, multi-step ones,
• exchange data (text, JSON, files) securely,
• track progress on work in flight (streaming, notifications).

The core idea: every agent is treated as a black box. A client agent does not need to know the remote agent's model, prompt, tools or memory. It hands over a task, the way you would hand a file to a colleague in another department, and gets a result back.

In one sentence: MCP connects an agent to its tools; A2A connects an agent to other agents.

2. History and governance

Version 1.0 introduced several breaking changes compared with 0.x (method names, state names, removed fields). If you are reading tutorials from 2025, check which version they target.

3. Key concepts

A2A relies on a small vocabulary:

4. A three-layer architecture

The v1.0 specification is split into three layers, so you can change transport without rewriting the agent's logic:

┌─────────────────────────────────────────────────────────┐
│ Layer 3 — Protocol bindings                             │
│   JSON-RPC 2.0 over HTTPS  │  gRPC  │  HTTP+JSON (REST) │
├─────────────────────────────────────────────────────────┤
│ Layer 2 — Abstract operations                           │
│   SendMessage, SendStreamingMessage, GetTask,           │
│   ListTasks, CancelTask, SubscribeToTask,               │
│   push notification config, Agent Card retrieval        │
├─────────────────────────────────────────────────────────┤
│ Layer 1 — Canonical data model                          │
│   AgentCard, AgentSkill, Task, Message, Part,           │
│   Artifact, Extension (Protocol Buffers + JSON Schema)  │
└─────────────────────────────────────────────────────────┘

Each agent advertises the binding(s) it supports in its Agent Card (the supportedInterfaces field). JSON-RPC is the most common for publicly exposed agents; gRPC is attractive for low-latency internal traffic.

5. How it works, step by step

Let's take a concrete scenario: an HR agent needs to organise an interview and delegates the booking to a travel agent run by another team.

![A2A task delegation sequence: discovery, authentication, sending, tracking, multi-turn exchange and result]

Step 1 — Discovery via the Agent Card

The remote agent publishes its card at a standard URL: https://<domain>/.well-known/agent-card.json (an RFC 8615 convention). A simplified, v1.0-compliant example:

{
  "name": "Travel booking agent",
  "description": "Books flights and hotels for employees.",
  "version": "1.2.0",
  "provider": {
    "organization": "MyCompany",
    "url": "https://mycompany.example"
  },
  "supportedInterfaces": [
    {
      "url": "https://travel.mycompany.example/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "book_flight",
      "name": "Book a flight",
      "description": "Books a flight given an origin, a destination and dates.",
      "tags": ["travel", "booking"],
      "examples": [
        "Book a Paris–Lyon flight on 12 November for employee 4432"
      ]
    }
  ],
  "securitySchemes": {
    "corp_oauth": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.mycompany.example/token",
          "scopes": { "flights:write": "Book flights" }
        }
      }
    }
  },
  "security": [{ "corp_oauth": ["flights:write"] }]
}

The client reads the card, checks that the book_flight skill exists, picks an interface and identifies the expected authentication method.

Discovery can also go through an internal registry (a catalogue of vetted agents) or direct configuration (a hard-coded URL) for tightly coupled systems.

Step 2 — Authentication

Credentials never travel in the body of the A2A message: they are sent in HTTP headers (Authorization: Bearer …). Here, the client runs an OAuth2 client credentials flow against the declared tokenUrl.

Step 3 — Sending the task (SendMessage)

POST /a2a HTTP/1.1
Host: travel.mycompany.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Book a direct Paris–Lyon flight on 12 November for employee 4432."
        }
      ]
    },
    "configuration": { "returnImmediately": true }
  }
}

Things to note:

• The client does not supply a task identifier: the server generates it and returns it.
• For a trivial answer, the server can return a Message directly instead of creating a Task.
• returnImmediately: true asks the server to hand back the newly created task right away, so the client can follow progress in parallel (in v1.0 the default behaviour is blocking).

Step 4 — Tracking progress

Three mechanisms, depending on duration and topology:

Example of a received SSE stream:

data: {"task": {"id": "task-9876", "status": {"state": "TASK_STATE_SUBMITTED"}}}

data: {"statusUpdate": {"taskId": "task-9876", "status": {"state": "TASK_STATE_WORKING"}}}

data: {"artifactUpdate": {"taskId": "task-9876", "artifact": {"artifactId": "a1", "name": "itinerary", "parts": [ ... ]}}}

data: {"statusUpdate": {"taskId": "task-9876", "status": {"state": "TASK_STATE_COMPLETED"}}}

The stream closes automatically when the task reaches a terminal state.

Step 5 — Multi-turn exchange (if needed)

If the remote agent needs clarification ("economy or business class?"), the task moves to INPUT_REQUIRED. The client replies with a new SendMessage carrying the same task identifier, and work resumes.

Step 6 — Retrieving the result

Artifacts hold the final deliverable. A client that missed the stream can always call GetTask to fetch the full task, with its history and artifacts.

Bonus: a minimal Python client

import requests

BASE = "https://travel.mycompany.example"

# 1. Discovery
card = requests.get(f"{BASE}/.well-known/agent-card.json", timeout=10).json()
if "book_flight" not in {s["id"] for s in card.get("skills", [])}:
    raise RuntimeError("The agent does not offer the book_flight skill")

endpoint = card["supportedInterfaces"][0]["url"]
headers = {"Authorization": "Bearer <token>", "Content-Type": "application/json"}

# 2. Send the task
payload = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "SendMessage",
    "params": {
        "message": {
            "role": "ROLE_USER",
            "parts": [{"text": "Book a Paris–Lyon flight on 12/11 for employee 4432."}],
        },
        "configuration": {"returnImmediately": True},
    },
}
task = requests.post(endpoint, json=payload, headers=headers, timeout=30).json()["result"]

# 3. Read the state (simple polling)
status = requests.post(
    endpoint,
    json={"jsonrpc": "2.0", "id": 2, "method": "GetTask",
          "params": {"taskId": task["task"]["id"]}},
    headers=headers, timeout=30,
).json()
print(status)

In production, prefer the official SDKs (Python, JavaScript, Java, Go, .NET) published by the A2A project over hand-written HTTP calls. The exact shape of result depends on the server's response (task or message).

6. Task lifecycle

![A2A task lifecycle: in-progress, interrupted and terminal states]

7. Security

A2A builds on web standards rather than inventing its own:

• Encrypted transport: HTTPS (TLS 1.2 minimum) is mandatory in production.
• Authentication schemes aligned with OpenAPI: OAuth 2.0, OpenID Connect, API key, mTLS. Declared in securitySchemes and required via security.
• Signed Agent Cards: a JWS signature (RFC 7515) computed over a canonical form of the card (RFC 8785) makes any tampering detectable. Otherwise, a modified card could redirect calls or inject malicious content into the client agent's prompt.
• Extended Agent Card: an agent can expose a minimal public card and a more detailed one, available only after authentication.
• Traceability: the specification recommends OpenTelemetry and propagating W3C Trace Context headers (traceparent) to follow a request across the whole chain of agents.

For high assurance: combine mTLS and OAuth2, or use sender-constrained tokens (DPoP, RFC 9449), so that a stolen token is useless from another machine.

8. A2A vs MCP

Reminder: what is MCP?

MCP (Model Context Protocol), launched by Anthropic in late 2024 and now widely adopted, standardises the connection between an AI application (the client/host) and servers that expose tools, resources (data) and prompts. It runs on JSON-RPC 2.0, locally over stdio or remotely over HTTP. Its specifications are named by date; the 2026-07-28 revision notably made the protocol stateless (sessions and the initialisation handshake were removed), which makes horizontal scaling of servers easier.

Comparison table

The right question to ask

"Do I want to perform a precise action, or hand over a goal to someone who will figure out how to reach it?"

• A precise, deterministic action (an SQL query, reading a file, calling a weather API) → MCP.
• A goal to reach by a system that reasons, can ask questions, and whose implementation you don't want to know about → A2A.

There is a grey area: you can expose a whole agent as an MCP "tool". That works for simple cases, but you lose what makes A2A strong: state tracking, multi-turn exchanges, long-running tasks and cross-organisation discovery.

9. Using A2A and MCP together

The two protocols are complementary and together form the communication stack of multi-agent systems:

Scenario:

1. The user asks the orchestrator: "Organise Marie's interview in Lyon on Thursday."
2. The orchestrator delegates via A2A to the HR agent ("schedule the interview") and to the travel agent ("book the trip").
3. Each of these agents uses MCP internally to query its own tools: calendar, HRIS, booking API.
4. The agents return their artifacts (confirmed slot, ticket) to the orchestrator via A2A.

Rule of thumb: A2A between agents, MCP between an agent and its tools.

10. Current limitations and best practices

Limitations to be aware of:

• Per-skill data schema: a skill declares that it accepts application/json, but the specification does not standardise the exact schema expected. Workaround: publish a JSON Schema in the skill description or through an Extension declared in the Agent Card.
• Downscoping across delegation chains: A2A says how to pass credentials, not how to narrow them when a highly privileged orchestrator delegates to a less privileged agent. Workaround: OAuth 2.0 Token Exchange (RFC 8693) to issue short-lived, narrowly scoped tokens.
• No standard registry: discovery through a central catalogue is still something you build yourself.
• Migrating from 0.x to 1.0: method names (message/send → SendMessage), prefixed state names, removal of the kind and final fields.

Best practices:

• Treat the Agent Card as a contract: any change to a skill, URL or capability must bump the version.
• Sign Agent Cards and verify signatures on the client side.
• Serve the card with Content-Type: application/json.
• Put an API gateway in front of agents to centralise authentication, quotas, logging and long-lived connection handling.
• Instrument with OpenTelemetry from day one: debugging a chain of five agents without distributed traces is painful.
• Never blindly trust content received from another agent: it is data, not instructions (prompt-injection risk).

11. Conclusion

A2A does for agents what HTTP did for documents or SMTP for email: it provides a common, neutral language that lets heterogeneous systems cooperate without bespoke integration. With a stable v1.0, Linux Foundation governance and adoption by the major platforms, it is now ready for production use.

MCP and A2A are not competitors: MCP gives an agent hands; A2A gives it colleagues. A modern multi-agent architecture uses both.

Further reading

• Official A2A specification
• A2A and MCP: how the two protocols relate (official A2A site)
• MCP specification
• A2A v1.0 technical guide — Tyk
• MCP vs A2A — Metorial

Originally published on my blog. Une version française est disponible ici.