The Agent2Agent (A2A) protocol released version 1.0 on March 12, 2026, its first stable, production-ready specification. A2A defines how independent AI agents discover each other and exchange tasks, and the 1.0 release adds cryptographically signed Agent Cards, native multi-tenancy and formally equivalent JSON-RPC, gRPC and HTTP+JSON bindings. It also renames operations and restructures core objects, so anyone who built on earlier versions has migration work ahead. For teams connecting agents across vendors and services, 1.0 is the signal that the protocol is ready to depend on.

Key Facts#

  • Release date: Version 1.0.0 was published on March 12, 2026, and a 1.0.1 patch followed on May 28, 2026, according to the project's GitHub releases.
  • Governance: A2A is hosted by the Linux Foundation, which took over stewardship of the Google-originated project in June 2025.
  • Adoption: The 1.0 announcement says more than 150 organizations support the protocol and that it is used across the AWS, Microsoft and Google cloud platforms.
  • Security: Agent Cards can carry JWS signatures (RFC 7515) over canonicalized JSON (RFC 8785), so a client can verify that a card really comes from the domain that publishes it.
  • Multi-tenancy: A tenant field on requests lets a single endpoint host many agents, for example one per customer of a SaaS provider.
  • Bindings: JSON-RPC 2.0, gRPC and HTTP+JSON/REST are formally specified with equivalence guarantees, and a new A2A-Version header supports explicit version negotiation.
  • .NET support: The official A2A .NET SDK supports the 1.0 specification through the A2A and A2A.AspNetCore packages, with an A2A.V0_3 package for older peers.

What Happened#

The 1.0 release was less about new concepts than about hardening. The specification now builds on established standards: JSON canonicalization and JWS for signatures, and google.rpc.Status for errors across all bindings. Agent Cards, the JSON documents that describe what an agent can do and how to reach it, gained a signatures array so that clients can check authenticity before trusting a card's endpoints or claimed skills.

Versioning also became explicit. Each entry in an Agent Card's new supportedInterfaces list names its URL, protocol binding and protocol version, so one agent can serve several versions or bindings side by side. Clients send an A2A-Version header to state which version they speak.

The release added features that production users had asked for. A new ListTasks operation supports filtering and cursor-based pagination. A returnImmediately parameter gives callers control over how a task executes relative to the request. OAuth support was modernized: the implicit and password flows were removed because of token-leakage and credential-exposure risks, a device code flow (RFC 8628) was added for command-line and constrained devices, and authorization code flows can now require PKCE.

The cost is a set of breaking changes. The table below summarizes some of the most visible ones.

AreaBefore 1.0 (v0.3)In 1.0
Send a messagemessage/sendSendMessage
Get or cancel a tasktasks/get, tasks/cancelGetTask, CancelTask
List tasksNot availableListTasks with cursor pagination
Task state values"input-required""TASK_STATE_INPUT_REQUIRED"
Message roles"user", "agent""ROLE_USER", "ROLE_AGENT"
Message partsTextPart, FilePart, DataPart with kindOne Part type, identified by which field is present
REST pathsPOST /v1/message:sendPOST /message:send
HTTP errorsRFC 9457 problem detailsgoogle.rpc.Status with ErrorInfo

Streaming changed as well. Status and artifact events are now wrapped as statusUpdate and artifactUpdate objects, and the old final flag is gone: the end of the stream signals that the task reached a terminal state.

Background#

Google introduced A2A in April 2025 as an open protocol for agent-to-agent communication. It targets a different layer than the Model Context Protocol: MCP connects an agent to tools and data. A2A connects agents to other agents, each potentially built on a different framework or run by a different organization, through a task-oriented exchange with discovery via Agent Cards. In June 2025 the project moved to the Linux Foundation for neutral governance.

The 0.x releases moved quickly. Version 0.3.0, published on July 30, 2025, added signature support to Agent Cards, an operation for retrieving extended cards and mutual TLS, and changed the well-known path for cards from agent.json to agent-card.json. By the protocol's first anniversary in April 2026, Google's Open Source Blog was celebrating a year of open collaboration around it.

Why It Matters for Developers#

For .NET developers, the most important detail is that the official A2A .NET SDK already targets 1.0. Its README says it supports the JSON-RPC binding and the HTTP+JSON REST binding, including Server-Sent Events streaming, and it provides a migration guide from the v0.3 SDK. The separate A2A.V0_3 package covers peers that have not upgraded.

Planning points for teams with A2A in production or in design:

  • Upgrade parsers first. The project's own migration guidance ranks the new Part structure, stream event parsing, the Agent Card layout and the A2A-Version header as critical. Contract tests that replay real payloads catch most of these breaks.
  • Verify Agent Card signatures. Signed cards close an obvious spoofing gap in agent discovery. Treat an unsigned or invalid card as untrusted, in the same way you would treat an unverified JWT. Our OAuth, OIDC and JWT interview guide covers the underlying concepts.
  • Pick the binding that fits. gRPC suits high-throughput service-to-service traffic, while HTTP+JSON is easiest for web stacks and gateways. See our gRPC in .NET guide for the trade-offs.
  • Design for tenants explicitly. If you expose agents to multiple customers, use the tenant field and keep authorization decisions per tenant rather than per endpoint.

When you evaluate agent frameworks, including the ones covered in our Microsoft Agent Framework guide, check which A2A version their integrations target. Our AI agent patterns guide covers when a multi-agent design is worth the added complexity in the first place.

What's Next#

The 1.0.1 patch in May 2026 showed the project settling into maintenance releases on a stable base. The version negotiation design means future revisions can be adopted gradually, with agents advertising several protocol versions through separate interfaces.

Open questions are mostly operational. Signed Agent Cards help only if clients actually verify them, and discovery across organizational boundaries still depends on trust decisions each team must make. It also remains to be seen how clearly the ecosystem will separate A2A's role from MCP's as both protocols add features for long-running work.

Sources#