What is Agent2Agent protocol? It is an open standard proposed by Google that lets independent AI agents discover each other’s capabilities and cooperate on tasks over HTTP using JSON-RPC. The spec defines a lightweight metadata format (Agent Card), a task-oriented message exchange, and streaming or push semantics so agents built on different frameworks can interoperate without custom glue code.
How A2A Works
A2A is deliberately boring infrastructure. It does not try to define how agents think. It defines how they talk.
Agent Cards and Discovery
Every A2A-compliant agent publishes an Agent Card, a JSON document that describes what it does and how to reach it. The conventional location is /.well-known/agent.json on the agent’s origin, but the URL can be supplied out-of-band.
{
"name": "InvoiceProcessor",
"description": "Extracts line items from PDF invoices",
"version": "1.0.0",
"protocol": "a2a/0.1",
"capabilities": {
"streaming": false,
"push": false
},
"auth": { "type": "bearer" },
"endpoint": "https://agents.example.com/a2a"
}The card carries no code, only contract. A client agent fetches the card, reads capabilities, and decides whether to delegate work. This is the first step in answering what is Agent2Agent protocol at the mechanical level: it is capability negotiation via static metadata.
Task Lifecycle and Messages
Agents exchange tasks. A task is a unit of work with a stable ID and a state machine: submitted, working, completed, failed, canceled. The client starts a task with a tasks/send JSON-RPC call.
{
"jsonrpc": "2.0",
"id": "req-1",
"method": "tasks/send",
"params": {
"task": {
"id": "task-123",
"message": {
"role": "user",
"parts": [
{ "type": "text", "text": "Process invoice.pdf" },
{ "type": "file", "file": { "name": "invoice.pdf", "mimeType": "application/pdf", "data": "base64..." } }
]
}
}
}
}Messages are composed of parts. A part is either text, file, or structured data. This polymorphic payload avoids forcing every agent to speak the same document schema. The server returns the task with its current state and any produced message parts.
If the agent supports streaming, the client can open an SSE channel to receive incremental updates. If it supports push, the server can POST results to a client-provided webhook when a long-running task finishes. That is the entire interaction model.
Transport and Auth
A2A runs on plain HTTP POST with JSON-RPC 2.0 bodies. There is no custom binary protocol, no gRPC requirement, no new port. Authentication is delegated to standard schemes: bearer tokens, API keys, or OAuth as declared in the Agent Card. This keeps the protocol implementable in an afternoon in any language with an HTTP client.
Why the Protocol Matters
Interoperability Without Lock-in
Most teams building agents in 2025 have at least two frameworks in play: a research prototype in LangGraph, a production service in a custom FastAPI app, maybe a third-party vendor bot. Without a shared dialect, each integration is a one-off adapter. A2A gives a baseline contract so a travel agent can delegate currency conversion to a separate forex agent without knowing its implementation language.
Complementing MCP
The other protocol in this space is Anthropic’s Model Context Protocol (MCP). MCP connects an agent to tools and data sources: a database, a Slack API, a vector store. A2A connects an agent to other agents. They operate at different layers. You use MCP to give your agent hands; you use A2A to give it colleagues. Conflating them is the fastest way to build the wrong abstraction.
A Concrete Example
Scenario: Procurement Agent and Logistics Agent
Imagine a procurement agent that receives a purchase order and needs a shipping quote. It does not implement logistics math itself. It discovers a logistics agent via the card, then delegates.
import requests
# Step 1: discover capability
card = requests.get(
"https://logistics.example.com/.well-known/agent.json"
).json()
endpoint = card["endpoint"]
# Step 2: send a task
payload = {
"jsonrpc": "2.0",
"id": "1",
"method": "tasks/send",
"params": {
"task": {
"id": "t-1",
"message": {
"role": "user",
"parts": [
{"type": "text", "text": "Quote shipping for 10kg to Berlin"}
]
}
}
}
}
resp = requests.post(
endpoint,
json=payload,
headers={"Authorization": "Bearer token"}
)
print(resp.json())The logistics agent processes the task and returns a message part with structured data:
{
"task": {
"id": "t-1",
"state": "completed",
"message": {
"role": "agent",
"parts": [
{ "type": "data", "data": { "costUsd": 42.10, "etaDays": 3 } }
]
}
}
}Inside the Agent
The logistics agent might use an LLM to parse free-text addresses or to reason about carrier trade-offs. When that agent needs model inference, routing through a gateway such as n4n.ai gives one OpenAI-compatible endpoint across 240+ models with automatic fallback on provider degradation, while honoring routing directives and cache-control hints. The A2A layer stays agnostic to that choice; the agent card only advertises “I return quotes.”
Common Misconceptions
A2A Replaces MCP
No. MCP is about tools; A2A is about peers. An agent can simultaneously be an MCP server (exposing a calculator tool) and an A2A participant (negotiating with a scheduling agent). The protocols are designed to be used together.
A2A Is a Model-Serving Protocol
It is not. A2A never mentions tokens, sampling, or inference endpoints. If you want to call GPT-4o or Claude, you use your existing LLM client. A2A only standardizes the envelope for agent-to-agent task handoff. Treating it as an OpenAI substitute will lead you to bolt on the wrong features.
A2A Is Google-Only
Google authored the initial draft, but the protocol is published as an open standard with a permissive license and multiple non-Google implementations already exist. Nothing in the spec requires Google infrastructure. Any agent, anywhere, that speaks JSON-RPC over HTTP can join.
A2A Is a Message Queue
It is not a durable pub/sub system. Tasks are request/response oriented, with optional async push. There is no topic exchange, no replay, no broker. If you need event streaming between agents, run Kafka or NATS alongside A2A; do not misuse the push capability as a substitute.
Implementing Your First A2A Agent
If you are landing here from search wondering how to start, the path is short:
- Write an Agent Card JSON and serve it at
/.well-known/agent.json. - Stand up an HTTP POST endpoint that accepts
tasks/sendand returns a task object. - Implement the minimal state machine: accept, mark
working, produce a result, markcompleted. - Have a second agent fetch the card and call the endpoint with a typed message.
You will spend more time defining your parts schema than writing the transport. That is the point. The protocol gets out of your way so you can focus on agent logic.
What is Agent2Agent protocol in one line? A JSON-RPC contract for agents to discover each other and delegate tasks without sharing a codebase. The rest is just disciplined HTTP.