05 Jan 2026 AI Engineering5 min read

A2A Heads for 1.0: What to Build Now

A2A is approaching its first production-ready release. We trace the path from Google’s April 2025 announcement to the v1.0 Release Candidate and separate stable concepts from moving wire formats. From that distinction, we derive what to build on v0.3.0 today and what to isolate before 1.0.

Agents That Cannot Talk to Each Other

Every agent framework in 2025 comes with its own interface. LangGraph, CrewAI, Semantic Kernel, and Google's ADK each expose agents differently. Even two frameworks require an adapter; with n frameworks, the count grows to n×(n−1). The Model Context Protocol standardizes how a model calls tools, but not how one autonomous agent discovers, authenticates, and assigns work to another across process, vendor, and organizational boundaries.

The Agent2Agent protocol (A2A) addresses precisely that layer. Agents remain opaque to one another: they exchange messages and tasks, not internal state, memory, or prompts. A2A defines discovery, authentication schemes, task delegation, and streaming. How an agent reasons, how work is orchestrated, and whether the result is correct remain outside its scope. Those are still engineering problems on both sides of the connection.

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, with official SDKs for Python, JavaScript, Java, Go, and .NET. Since November, the project has been working toward v1.0, the first release the maintainers describe as production-ready. The practical question is now concrete: which concepts are already durable, which formats will break, and what can you build today?

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 and their semantics, but not persistence. Task storage, retries, idempotency, and timeout budgets remain the implementer's responsibility. In our integration projects, most of the engineering effort therefore goes into the task store, not the transport. Design that component before the first demo; added later, it becomes the costliest part of the integration.

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 either decided or still under review. JSON serialization is moving to ProtoJSON conventions, turning enum values such as "input-required" into TASK_STATE_INPUT_REQUIRED. A second proposal, opened on December 11, 2025, removes the OAuth implicit and password flows and adds Device Code (RFC 8628) and PKCE; the TSC vote is still open as we write. The sound planning assumption is therefore that 1.0 will stabilize concepts while breaking wire formats.

What to Build Now and What to Isolate

Our recommendation follows directly from that distinction: build on v0.3.0 today, but 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 transport pluggable and verify card signatures at ingestion rather than on every call. One extra mapping layer costs little and keeps the 1.0 migration small.

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 tighten scope rather than add features. The maintainers want to establish a stable, unambiguous, multi-protocol specification first. That is the right order. For client projects, we budget for migration within the first quarter after release.

We draw two predictions from this direction. 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, much like container registries. Second, A2A and MCP will take complementary roles: MCP connects a model to tools, while A2A connects agents to one another. Whether the industry converges on this single task lifecycle or establishes several remains open. Our architecture assumes this one will endure while still isolating its wire format.