# A2A Protocol (Agent2Agent): Agent Card, Operations, Task States, Bindings > Wire-level reference for the A2A (Agent2Agent) protocol v1.0: the Agent Card at /.well-known/agent-card.json, the 11 operations, the 8 task states, three protocol bindings, security schemes, version negotiation, and what changed from v0.3. Category: Guide · Updated: 2026-10-09 · Tags: a2a, agent2agent, protocols, agent-card, interoperability, agents, multi-agent Canonical: https://changegamer.ai/resources/a2a-protocol Variants: [HTML](https://changegamer.ai/resources/a2a-protocol) · [JSON](https://changegamer.ai/api/resources/a2a-protocol.json) License: https://changegamer.ai/license.xml · Access: free A2A (Agent2Agent) is an open protocol for communication between opaque agentic applications: agents built on different frameworks discover each other through an Agent Card, exchange messages, and track work as tasks. This entry is the wire-level reference; for the MCP-vs-A2A decision see /resources/mcp-vs-a2a. ## Key facts - Released versions per the project releases page: v1.0.0 (2026-03-12), v1.0.1 (2026-05-28, bug fixes, prefers `application/a2a+json` in the HTTP binding), earlier v0.3.0 (2025-07-30). - Licence Apache 2.0; an open source project under the Linux Foundation, contributed by Google. SDKs listed in the README: Python, Go, JavaScript, Java, .NET, Rust. - Discovery: an agent MUST publish an Agent Card at `https://{server_domain}/.well-known/agent-card.json` (v0.3.0 renamed this from `agent.json`). - Three bindings: JSON-RPC 2.0, gRPC, HTTP+JSON/REST (custom bindings are also allowed). - Clients send an `A2A-Version` header (format `Major.Minor`, or the same name as a request parameter); servers answer with `VersionNotSupportedError` for versions they do not support. Patch numbers are not part of negotiation. An empty header value is interpreted as `0.3`, so a v1.0 client that sends an empty header gets v0.3 semantics. - The a2a-protocol.org specification page labels 1.0.0 as the latest released version; the GitHub releases page also lists the v1.0.1 patch. ## What are the A2A operations? The specification defines eleven operations: Send Message, Send Streaming Message, Get Task, List Tasks, Cancel Task, Subscribe to Task, Create / Get / List / Delete Push Notification Config, and Get Extended Agent Card. `List Tasks` (filtering and pagination) arrived with v1.0.0. | Binding | Spelling (spec main branch, at time of fetch) | |---|---| | JSON-RPC | PascalCase: `SendMessage`, `SendStreamingMessage`, `GetTask`, `ListTasks`, `CancelTask`, `SubscribeToTask`, `GetExtendedAgentCard` | | HTTP+JSON | `POST /message:send`, `POST /message:stream`, `GET /tasks/{id}`, `GET /tasks`, `POST /tasks/{id}:cancel`, `POST /tasks/{id}:subscribe`, `GET /extendedAgentCard` | | gRPC | normative `A2AService`, Protocol Buffers v3 over HTTP/2 with TLS | Older docs and posts show `message/send` and `message/stream`; those are the v0.3-era JSON-RPC spellings, so check the `A2A-Version` you target. HTTP+JSON bodies use `application/a2a+json`. ## What are the A2A task states? Eight `TaskState` values: `TASK_STATE_SUBMITTED`, `TASK_STATE_WORKING`, `TASK_STATE_COMPLETED`, `TASK_STATE_FAILED`, `TASK_STATE_CANCELED`, `TASK_STATE_REJECTED`, `TASK_STATE_INPUT_REQUIRED`, `TASK_STATE_AUTH_REQUIRED`. Terminal: completed, failed, canceled, rejected; Subscribe to Task on a terminal task returns `UnsupportedOperationError`. The two `*_REQUIRED` states pause the task for the client. Spelling is American ("canceled") as of v1.0. ## What is in an Agent Card? - Identity: `name`, `description`, `provider`, `version`, `documentationUrl`, `iconUrl`. - `supportedInterfaces`: which protocol bindings and endpoints the agent serves. - `capabilities`: `streaming`, `pushNotifications`, `extensions`, `extendedAgentCard`. - `skills`: array describing what the agent can do. - `securitySchemes` plus security requirements: API key, HTTP auth, OAuth 2.0, OpenID Connect, mutual TLS. v1.0.0 modernised OAuth 2.0 flows (device code, PKCE). - Signing: a card MAY be signed with JSON Web Signature (RFC 7515) using RFC 8785 canonicalisation. Signing is optional, so an unsigned card proves nothing about who published it. - If `extendedAgentCard` is true, an authenticated client can fetch fuller details; it SHOULD replace its cached public card. ## Messages and parts A message carries `Part` objects: text, file, or structured data. In v1.0+ parts are discriminated by member name (`{"text": "..."}`) instead of an explicit `kind` field, a breaking change for v0.3 clients. ## Security note (inference) Inference, not spec text: an Agent Card is self-published, so treat its skill descriptions as untrusted input to your model, the same way as MCP tool descriptions (see /resources/mcp-tool-poisoning), and prefer verifying a signed card before delegating. See also: /resources/mcp-vs-a2a, /resources/agent-delegation-chains, /resources/multi-agent-orchestration-patterns, /resources/agent-identity-authentication, /resources/a2ui-protocol ## Verified sources Fetched directly 2026-10-07 and re-verified 2026-10-09: - A2A specification (rendered, v1.0): https://a2a-protocol.org/latest/specification/ - A2A specification (docs/specification.md, main branch, which may be ahead of v1.0.1): https://raw.githubusercontent.com/a2aproject/A2A/main/docs/specification.md - A2A README: https://raw.githubusercontent.com/a2aproject/A2A/main/README.md - A2A releases (versions and dates): https://github.com/a2aproject/A2A/releases Re-verified 2026-10-09 against the rendered specification: method names, the eight task states, terminal vs interrupted states, and the `A2A-Version` rules above match it. --- ## Related resources - [MCP vs A2A: Two Protocols, Two Roles](https://changegamer.ai/resources/mcp-vs-a2a.md): Compact comparison of the Model Context Protocol (agent↔tool) and the Agent2Agent Protocol (agent↔agent): purpose, topology, transport, discovery, auth, governance, and when to use each. - [A2UI: Google's Declarative Agent-to-UI Protocol (vs AG-UI, MCP Apps)](https://changegamer.ai/resources/a2ui-protocol.md): What A2UI is: the open, Apache-2.0 standard in which agents send declarative JSON describing the intent of a UI and the client renders it from a catalog it controls; the four v0.9 message types, transport requirements, renderer status, and how A2UI relates to AG-UI, A2A and MCP Apps. - [Agent Client Protocol (ACP): How Editors Talk to Coding Agents](https://changegamer.ai/resources/agent-client-protocol.md): Reference for the Agent Client Protocol (ACP), the open protocol that connects code editors and IDEs to coding agents over JSON-RPC: session lifecycle, MCP server hand-off, transports, tool calls, permissions, and how ACP differs from MCP and A2A. - [Building an MCP Server](https://changegamer.ai/resources/building-mcp-servers.md): Implementation guide for MCP servers: architecture roles, the three server primitives, stdio vs Streamable HTTP transports, official SDKs, server lifecycle, remote-server concerns, testing with MCP Inspector, and publishing to the official registry. --- ## Further reading - [Distributed Tracing for Multi-Agent AI Systems](https://changegamer.ai/articles/multi-agent-trace-propagation.md): How trace ID propagation actually works across a multi-agent handoff, why handoff and delegation need different trace shapes, and why an orchestrator-level trace can hide a failed leg of a fan-out. - [How to Implement OAuth 2.1 for an MCP Server](https://changegamer.ai/articles/mcp-oauth-implementation.md): A wire-level implementation walkthrough for OAuth 2.1 on a remote MCP server: what the discovery documents actually contain, CIMD vs. Dynamic Client Registration in your server code, per-SEP detail from the 2026-07-28 hardening set, and token-validation mechanics. --- Index of all resources: https://changegamer.ai/llms.txt · Full corpus: https://changegamer.ai/llms-full.txt · Corpus data (NDJSON): https://changegamer.ai/api/corpus.jsonl · Offers: https://changegamer.ai/api/pricing.json License the full corpus for RAG / fine-tuning (AI-use grant): https://changegamer.ai/corpus-license