Agent-to-Agent Protocol (A2A)
How do AI agents find each other and coordinate work?
A2A is the TCP of agents — the transport layer that lets any agent discover, message, and delegate tasks to any other agent, regardless of who built them. Launched by Google with 50+ partners, now governed by the Linux Foundation.
Agent Cards
Every A2A-capable agent publishes a JSON metadata document at /.well-known/agent.json. This is the agent's business card — what it does, how to talk to it, what auth it requires.
| Field | Purpose | Example |
|---|---|---|
name | Human-readable identity | "Sales Research Agent" |
description | What the agent does | "Researches companies and qualifies leads" |
url | Agent's A2A endpoint | https://agent.example.com/a2a |
capabilities | What the agent supports | Streaming, push notifications, state transitions |
authentication | Required auth method | OAuth2, API key, mTLS |
skills | Specific tasks the agent performs | Each skill has its own input/output schema |
defaultInputModes | Accepted input types | text/plain, application/json, image/* |
defaultOutputModes | Response types | text/plain, application/json |
Discovery works like DNS for agents. Any client hits /.well-known/agent.json on a domain and learns what that agent can do.
Tasks
Tasks are the unit of work. A client creates a task, the agent processes it, both sides track lifecycle.
| State | Meaning | Transitions To |
|---|---|---|
SUBMITTED | Task received, not yet started | WORKING, REJECTED |
WORKING | Agent is processing | COMPLETED, FAILED, CANCELED, INPUT_REQUIRED, AUTH_REQUIRED |
INPUT_REQUIRED | Agent needs more information | WORKING (after input provided) |
AUTH_REQUIRED | Agent needs authorization | WORKING (after auth provided) |
COMPLETED | Task finished successfully | Terminal |
FAILED | Task failed | Terminal |
CANCELED | Task canceled by client | Terminal |
REJECTED | Agent refused the task | Terminal |
Tasks persist. Clients can poll status, resume after disconnection, or subscribe to updates via streaming.
Messages and Parts
Communication happens through Messages. Each Message contains Parts — typed content blocks.
| Part Type | Content | Use Case |
|---|---|---|
TextPart | Plain text or structured text | Instructions, responses, reasoning |
FilePart | Binary data with MIME type | Documents, images, audio |
DataPart | Structured JSON | API responses, form data, schemas |
Messages have roles (user or agent) and can contain multiple Parts. This mirrors how humans communicate — mixing text, files, and structured data in a single exchange.
Artifacts
Artifacts are the outputs — what the agent produces. Unlike messages (conversational), artifacts are the deliverables.
| Property | Purpose |
|---|---|
name | What this artifact is |
parts | Content (same Part types as messages) |
append | Whether this extends a previous artifact |
lastChunk | Whether this is the final piece |
Artifacts can stream incrementally. A research agent might produce findings as they're discovered, not just as a final report.
Streaming
Two transport options for real-time updates:
| Method | Protocol | Best For |
|---|---|---|
| SSE | HTTP Server-Sent Events | Web clients, simple streaming |
| gRPC | HTTP/2 bidirectional | High-throughput, low-latency agent networks |
Streaming lets clients watch task progress, receive partial artifacts, and respond to INPUT_REQUIRED states in real time.
Push Notifications
For long-running tasks, agents push updates to clients via webhooks.
Client creates task → disconnects → agent works for hours
Agent completes → pushes notification to client's webhook URL
Client reconnects → retrieves artifacts
The client registers a pushNotificationConfig with the task. The agent sends updates when state changes. This decouples task submission from result retrieval.
Authentication
Four auth methods, negotiated via Agent Card:
| Method | Use Case | Security |
|---|---|---|
| API Key | Simple integrations, internal agents | Basic |
| OAuth 2.0 | Third-party agents, user-delegated access | Standard |
| mTLS | Enterprise agent-to-agent | High |
| OIDC | Identity federation, SSO | Standard |
Auth requirements are declared in the Agent Card. Clients inspect before connecting — no trial-and-error.
Protocol Bindings
A2A is transport-agnostic. Three official bindings:
| Binding | Transport | When to Use |
|---|---|---|
| JSON-RPC 2.0 | HTTP/HTTPS | Default — most compatible |
| gRPC | HTTP/2 | High-throughput agent networks |
| HTTP REST | HTTP/HTTPS | Simple integrations |
All bindings support the same operations: create task, get task, cancel task, send message, set push config.
Governance
A2A moved from Google to the Linux Foundation — same governance model as Kubernetes, Node.js, and Linux itself.
- No single company controls the spec
- Changes go through open RFC process
- Multiple implementations can compete on quality
- The protocol outlives any company's strategic pivot
SDKs
| Language | Status |
|---|---|
| Python | Stable |
| JavaScript/TypeScript | Stable |
| Java | Stable |
| C# | Stable |
| Go | Stable |
Where A2A Sits
| Layer | Protocol | Function |
|---|---|---|
| Discovery + Communication | A2A | How agents find and talk to each other |
| Tool Access | MCP | How agents access external tools and data |
| Commerce | UCP | How agents buy and sell |
| Payment | AP2 | How agents authorize and settle payments |
| Attribution | PCP | How agents attribute creative IP |
A2A and MCP are complementary. MCP connects an agent to tools. A2A connects an agent to other agents. An agent might use MCP to access a database, then use A2A to delegate analysis to a specialist agent.
Context
- Agent Protocols — The protocol landscape
- UCP — Commerce layer: how agents buy and sell on A2A rails
- AP2 — Payment layer: how agents authorize payments
- MCP — Model Context Protocol for tool access
- Agent Commerce — The standards war for agent transactions
- Payment Rails — Intent-based payment infrastructure
Links
- A2A Protocol Specification — Full spec (Linux Foundation)
- A2A GitHub — Reference implementations and SDKs
- A2A vs MCP — Complementary, not competing
- A2A Launch Blog — 50+ launch partners
- Google AP2 Announcement — Payment layer extension
- A2A x402 Extension — Crypto-native agent payments
Questions
When every agent publishes a card and every task has a lifecycle, what's left that requires a human coordinator?
- If A2A becomes the TCP of agents, does the value accrue to the protocol or to the agents that speak it best?
- What breaks when two agents disagree on task state — and who arbitrates?
- At what agent density does discovery become the bottleneck, not communication?