Skip to content

All lessons

Area 03 // AI AgentsLesson 62 / 14013 min read

The A2A protocol

A2A (Agent2Agent) is an open protocol that lets independent agents, built by different teams on different frameworks, discover each other through an Agent Card, send each other tasks, and get results back, without exposing their internal prompts, tools or memory.

Think of it like this

Analogy

Companies work with each other without seeing each other's internal processes. A travel agency calls an airline's business desk: the airline publishes what services it offers and how to contact it, the agency sends a request, the airline gives a reference number, says when it needs more details ("passport number please"), and finally sends the ticket. Neither sees the other's internal systems.

A2A is that business desk protocol for AI agents.

The problem it solves

Organisations now run many agents: HR's, finance's, a vendor's travel agent, a partner's logistics agent, each built on different frameworks and models. To get work done across them, agents need to find each other, ask for help, track long-running tasks and receive results, without every pair building a custom integration and without exposing their internals.

MCP connects agents to tools. Agents talking to other agents need something else.

How it works, step by step

  1. Publish an Agent Card: a JSON document at https://<host>/.well-known/agent-card.json describing the agent's name, description, version, provider, the skills it offers, its endpoint and protocol bindings, capabilities (streaming, push notifications), and how clients must authenticate.
  2. Discover: a client agent fetches the card (or finds it in a registry) and decides whether this agent can help.
  3. Send a message: the client calls SendMessage (or SendStreamingMessage) with a message made of parts (text, files, structured data).
  4. A task is created: the remote agent works on it, moving through states: SUBMITTED → WORKING → (INPUT_REQUIRED or AUTH_REQUIRED if it needs something) → COMPLETED, or FAILED, CANCELED, REJECTED.
  5. Get results as artifacts: outputs (documents, data, files) made of parts.
  6. Long tasks: stream updates, poll with GetTask, subscribe, or receive push notifications to a webhook.
  7. Transports: JSON-RPC, gRPC or HTTP+JSON bindings, over HTTPS with standard auth (OAuth, API keys) declared in the card.
  8. Governance: as of November 2026, the A2A protocol is at v1.0, governed under the Linux Foundation (and part of the Agentic AI Foundation), Apache 2.0 licensed, with SDKs in several languages.
A client agent discovers a remote agent, sends a task, and receives artifacts. Internals stay private.

See it in code

Needs
Nothing: plain Python 3. Shapes follow the A2A v1.0 spec (as of November 2026); use an official A2A SDK for real servers and clients.

An Agent Card and the JSON-RPC request a client sends.

a2a_shapes.py
import json
 
# An A2A Agent Card: published at https://<host>/.well-known/agent-card.json
agent_card = {
    "name": "Travel Booking Agent",
    "description": "Books flights and hotels within a company travel policy.",
    "version": "1.4.0",
    "supportedInterfaces": [{"url": "https://travel.example.com/a2a", "protocolBinding": "JSONRPC"}],
    "capabilities": {"streaming": True, "pushNotifications": False},
    "securitySchemes": {"oauth": {"type": "oauth2"}},
    "defaultInputModes": ["text/plain"],
    "defaultOutputModes": ["text/plain", "application/json"],
    "skills": [{"id": "book-flight", "name": "Book a flight",
                "description": "Find and book a flight that matches the travel policy."}],
}
 
# What a client agent sends: a JSON-RPC request with a message made of parts.
request = {
    "jsonrpc": "2.0", "id": 1, "method": "SendMessage",
    "params": {"message": {"role": "ROLE_USER", "messageId": "m-001",
                           "parts": [{"text": "Book LHR to MAD on 3 Dec, economy."}]}},
}
 
print("discover:", agent_card["name"], "| skills:", [s["id"] for s in agent_card["skills"]])
print("send    :", json.dumps(request)[:72], "...")
print("task goes through: SUBMITTED -> WORKING -> (INPUT_REQUIRED?) -> COMPLETED with artifacts")
Output
discover: Travel Booking Agent | skills: ['book-flight']
send    : {"jsonrpc": "2.0", "id": 1, "method": "SendMessage", "params": {"message ...
task goes through: SUBMITTED -> WORKING -> (INPUT_REQUIRED?) -> COMPLETED with artifacts

Field details evolve between spec versions, so generate cards and requests with an official SDK rather than by hand in production.

A real example

Example

An expenses agent that books travel through a partner's agent

A company's internal expenses agent handles trip requests. Rather than integrating with the travel agency's booking APIs, it discovers the agency's A2A agent through its Agent Card, sends "book this trip within policy", answers the agency agent's INPUT_REQUIRED question about the cost centre, and receives the booking confirmation as an artifact, which it attaches to the expense record.

The agency changed its internal booking systems twice that year; the expenses agent never noticed, because the A2A interface stayed the same.

The easy way

Start here

You'll mostly use A2A rather than design it: read an agent's card to see what it offers, and call it with an official SDK. Inside your own app, plain function calls or subagents are simpler; use A2A at boundaries between teams, products or companies.

When you grow: the production setup

Production A2A deployments authenticate both sides, authorise per skill, sign Agent Cards, keep registries of approved agents, set timeouts and budgets on delegated tasks, treat returned content as untrusted input (indirect prompt injection), trace across agents and log for audit.

Trade-offs

What you gain

  • Agents from different teams, vendors and frameworks can collaborate through one standard.
  • Internals stay private; only skills and results are shared.
  • Built for long-running tasks with states, streaming and notifications.

What it costs you

  • Another protocol and security surface to manage.
  • Delegating to opaque agents makes end-to-end debugging and evaluation harder.
  • Overkill inside a single application.

When not to use it

  • Everything runs inside one codebase you control: use function calls, subagents or workflows.
  • You only need tools and data access: use MCP.

Common mistakes

  • Confusing A2A with MCP and using one where the other fits.
  • Trusting content returned by a remote agent as instructions.
  • No timeouts or budgets on delegated tasks.
  • Hand-writing protocol messages instead of using an SDK.
  • Exposing internal details in the Agent Card.

Interview questions

Try answering out loud first, then open the model answer.

What is A2A and how does it complement MCP?

Model answer

A2A is an open agent-to-agent protocol: agents publish Agent Cards describing skills, endpoints and auth; clients send messages that create tasks with a defined lifecycle; results return as artifacts; long tasks use streaming, polling or push notifications. MCP connects an agent to tools and data it controls; A2A connects it to independent, opaque agents as collaborators. A system often uses MCP inside each agent and A2A between agents.

What security concerns arise when agents call other agents?

Model answer

Authenticating and authorising both parties, verifying Agent Card authenticity, limiting which skills each client may invoke, preventing data over-sharing in messages, treating returned artifacts as untrusted input that may contain injected instructions, bounding delegated tasks with timeouts and budgets, and auditing cross-agent interactions with shared trace IDs.

Describe the lifecycle of an A2A task.

Model answer

A client sends a message, creating a task in SUBMITTED, which moves to WORKING. It may pause in INPUT_REQUIRED or AUTH_REQUIRED until the client provides what's needed, then continue. It ends in a terminal state: COMPLETED with artifacts, FAILED, CANCELED or REJECTED. Clients follow progress via streaming, GetTask polling, subscriptions or push notifications.

Quiz

Pick an answer to see whether it’s right and why.

  1. 01What does A2A connect?
  2. 02Where does an agent publish its Agent Card?
  3. 03How is A2A different from MCP?
  4. 04A remote agent needs more information from the user to continue. Which task state signals that?
  5. 05Why is it useful that A2A agents are "opaque"?

0 of 5 answered

Key terms

A2A (Agent2Agent) protocol
An open protocol for independent agents to discover each other, send tasks and return results without exposing their internals.
Agent Card
A JSON document an A2A agent publishes at /.well-known/agent-card.json describing its skills, endpoint, capabilities and authentication.
A2A task
The unit of work in A2A, with states such as submitted, working, input required and completed, producing artifacts.
MCP (Model Context Protocol)
An open standard for connecting AI applications to tools, data and prompts through servers that any compatible client can use.

Before and after

Read first

Read next

Progress is saved in this browser only.