05 Jan 2026 AI Engineering 5 min read

A2A Heads for 1.0: What to Build Now

A2A is approaching its first production-ready release. We trace the protocol from Google's April 2025 announcement to the v1.0 Release Candidate: signed Agent Cards, the task lifecycle, multi-tenancy, and the JSON-RPC and gRPC bindings. Plus concrete guidance on what to build on v0.3.0 today and which wire-format changes to isolate before 1.0 lands.

Agents That Cannot Talk to Each Other

Every agent framework of 2025 defines its own interface. LangGraph, CrewAI, Semantic Kernel and Google's ADK each expose agents differently. Connecting two of them requires a bespoke adapter; connecting n frameworks requires n×(n−1) adapters. The Model Context Protocol standardized how a model calls tools. It did not standardize how one autonomous agent finds, authenticates and delegates work to another — across process, vendor and organizational boundaries.

The Agent2Agent protocol (A2A) targets exactly this layer. Agents remain opaque: they exchange messages and tasks, not internal state, memory or prompts. A2A defines discovery, authentication schemes, task delegation and streaming. It does not define how an agent reasons, how work is orchestrated, or whether the result is correct. Those remain engineering problems on both sides of the wire.

An agent reaches its tools over MCP — one standard surface. 1/4

From Google Project to Linux Foundation Standard

Google announced A2A on April 9, 2025 with more than 50 technology partners. On June 23, 2025 the project was donated to the Linux Foundation at the Open Source Summit in Denver. Founding members include AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow; a Technical Steering Committee has governed the specification since. Vendor neutrality was a precondition for enterprise adoption; it is now an organizational fact.

The current release is v0.3.0 from July 30, 2025. Official SDKs exist for Python, JavaScript, Java, Go and .NET. Since November 2025 the project has been working towards v1.0 — the first release the maintainers label production-ready. This article describes what is stable, what will break, and what should be built now.

Signed Agent Cards Establish Verifiable Identity

An Agent Card is a JSON manifest served at /.well-known/agent-card.json. It declares the agent's name, skills, supported transports and security requirements. v0.3.0 made identity verifiable: the card carries a signatures array with JSON Web Signatures per RFC 7515, and mutual TLS was added to the security schemes. A client can verify that a card was published by a specific key holder before sending the first request.

The signature proves provenance of the metadata. It does not prove that the agent behaves as advertised, and it does not solve key distribution or revocation. Which signers you accept remains a policy decision. Treat a signed Agent Card like a signed container image: necessary for supply-chain hygiene, not sufficient for trust.

The Task Lifecycle Is the Core Abstraction

A2A distinguishes stateless messages from stateful tasks. A task is the unit of delegated work. Its core states are submitted, working, input-required and auth-required; terminal states are completed, canceled, failed and rejected. Updates stream over Server-Sent Events or gRPC streams; push notifications cover long-running work when no connection is held open. This lifecycle is the contract every A2A integration is built against.

The specification defines state transitions, not persistence. Task storage, retries, idempotency and timeout budgets are the implementer's responsibility. In our integration projects the most engineering effort lands in the task store, not in the transport. Plan for it before the first demo.

One Protocol With Three Bindings

v0.3.0 defines three transports: JSON-RPC 2.0 over HTTP is mandatory; gRPC over HTTP/2 and plain HTTP+JSON are optional. The Agent Card declares which combinations of URL and transport an agent serves. Functional equivalence is required — every method must behave identically regardless of binding. The choice is pragmatic: JSON-RPC for reach, gRPC for performance and streaming in controlled environments.

On November 20, 2025 the steering committee merged pull request #1160, a rewrite of the specification: 4,328 lines added, 7,042 removed, across 32 files. It separates the abstract protocol — operations, data model, semantics — from three formal protocol bindings, with a2a.proto as the normative source of truth. The TSC declared this the baseline for the v1.0 Release Candidate.

What the 1.0 Release Candidate Changes

The release pull request for 1.0.0 has been open since November 21, 2025, and concrete changes have already landed. Multi-tenancy was merged on December 4, 2025: every request carries an optional tenant routing field, so a single endpoint can securely serve many agents. The transport fields of the Agent Card are consolidated into a supportedInterfaces list, and each interface declares its own protocol version — enabling progressive migration instead of a hard cutover.

Two breaking changes are decided or pending. JSON serialization is moving to ProtoJSON conventions, which turns enum values like "input-required" into TASK_STATE_INPUT_REQUIRED. And a proposal opened on December 11, 2025 removes the OAuth implicit and password flows, adding Device Code (RFC 8628) and PKCE instead; it is still under TSC vote as we write this. Expect 1.0 to break wire formats while keeping concepts stable.

What to Build Now and What to Isolate

Our recommendation is to build on v0.3.0 today and treat the wire format as unstable. Map A2A types into your own domain model at the boundary. Do not hardcode enum strings, method names or card field paths. Keep the transport pluggable. Verify card signatures at ingestion, not at call time. This costs one mapping layer and buys a cheap 1.0 migration.

Area	Stable today (v0.3.0)	Changes ahead in 1.0
Agent Card	Discovery via well-known URI; skills; JWS signatures	Fields consolidated into supportedInterfaces
Task lifecycle	State set and semantics	Enum casing per ProtoJSON (breaking)
Bindings	JSON-RPC 2.0 mandatory; gRPC and HTTP+JSON optional	Formal bindings with equivalence guarantees; renames
Security	mTLS schemes; signed cards	OAuth flows modernized (Device Code, PKCE) — pending vote
Tenancy	Not in the protocol	tenant routing field (merged Dec 4, 2025)

Outlook: A2A 1.0 in Early 2026

We expect A2A 1.0 in the first quarter of 2026. The release pull request is open, the RC baseline is merged, and the remaining votes concern tightening scope, not adding features. The maintainers' stated goal is a stable, unambiguous, multi-protocol specification before new capabilities are accepted. That is the right order. For client projects we calculate with migration within one quarter after release.

Two predictions. First, multi-tenancy will make hosted agent platforms practical: one endpoint, many agents, one operational surface. Registries and gateways that resolve and verify signed Agent Cards will follow, analogous to container registries. Second, A2A and MCP will settle into complementary roles — MCP connects a model to tools, A2A connects agents to agents. Whether the industry converges on one task lifecycle or several remains open. We are building on the assumption that this one holds.