Learn A2A - Modern Features & Roadmap

#Introduction

Episode 20 brought you to operational discipline: CI/CD, contract testing, and SLA governance. All those practices presuppose a stable protocol — and that's finally what happened. After a year-long journey from an experimental protocol, A2A now has a stable v1.0 release under the Linux Foundation.

Episode 21 is a current snapshot: what v1.0 brings (signed agent cards, multi-tenancy, version negotiation), cross-language SDK support, who sponsors and uses the protocol, and where the roadmap goes next. This is a "state of the ecosystem" episode — the material you need before deciding to build on top of A2A.

#The Journey to v1.0

A quick recap of the history from episode 1: A2A was announced by Google in April 2025, donated to the Linux Foundation in June 2025, then iterated quickly from v0.1, v0.2, to v0.3 which added gRPC and signable security cards. Until finally v1.0 was released in March 2026 — the first stable version, followed by v1.0.1 (May 2026) as a patch.

What makes v1.0 meaningful isn't just a number, but a promise of stability: APIs and semantics already used in production won't change in a breaking way without version negotiation. This is what vendors were waiting for before making big investments — and its governance rests with the Linux Foundation, with a TSC made up of big names: AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. This cross-vendor stewardship is what distinguishes A2A from a protocol owned by a single company.

#Signed Agent Cards: Verifiable Identity

The most substantial feature in v1.0 is signed agent cards. Previously (v0.3) there were already signable security cards; now signing is extended to the entire agent card — so clients can verify two things: who issued the card, and whether the card's contents are still intact.

# Ambil agent card + signature dari endpoint /well-known
curl -s https://agent.example.com/agent-card \
  -H "Accept: application/json" > card.json
curl -s https://agent.example.com/agent-card/signature > card.sig
 
# Verifikasi dengan public key issuer
openssl dgst -sha256 -verify issuer-pub.pem \
  -signature card.sig card.json

This verification changes how clients judge a remote agent: no longer "the card says so", but "the card is guaranteed by a party we trust". In an ecosystem of 150+ organizations, the ability to verify the issuer becomes the foundation of the agent-to-agent trust model — we covered it in full in episode 9, and now it becomes the default standard.

A recommended practice: store the issuer's public keys in a central keystore, then run verification every time a card is fetched (or cache it together with the result, like the caching strategy in episode 18). That way, the curl to fetch the card above is just the first step — what truly matters is the issuer policy you decide on the client side.

#Multi-Tenancy and Version Negotiation

Two other v1.0 features solve real operational problems:

Multi-tenancy lets a single agent service serve many tenants with isolated contexts — tenant A can't read tenant B's tasks or history. At the implementation level, this means per-request context headers, state storage partitioned by tenant id, and rate limit policies computed per tenant, not in aggregate.

header-tenant.py

async def send_task_tenant(agent_url: str, tenant_id: str, task: dict):
    headers = {"A2A-Tenant-Id": tenant_id, "Authorization": bearer(tenant_id)}
    async with httpx.AsyncClient(headers=headers) as client:
        return await client.post(agent_url, json=task)

The tenant header is injected into every request, while task state is stored with the tenant id partition as the primary key. With this pattern, one deployment can serve a hundred clients without them seeing each other — as long as isolation is verified through cross-tenant tests like we discussed in episode 20.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "client/versions",
  "params": {
    "supportedVersions": ["1.0", "0.3"]
  }
}

Version negotiation answers the question "the client says 1.0, the server runs 0.3, what now?" Through a version handshake at the start of the connection, both sides agree to use the highest version supported by both. This is what makes the v0.3 to v1.0 migration gradual: old clients and new clients can ride the same server during the transition, with no shared downtime window.

#Cross-Language Bindings and SDKs

v1.0 stability also means consistency across bindings and SDKs. The three official bindings remain — JSON-RPC over HTTP, gRPC, and HTTP + SSE for streaming — and the official SDKs now cover five major languages. All are installed via their respective package managers, for example pip install a2a-sdk for Python and npm install @a2a-protocol/a2a for TypeScript:

# Python
pip install a2a-sdk
 
# JavaScript / TypeScript (Node)
npm install @a2a-protocol/a2a
 
# Go, Java, .NET
go get github.com/a2aproject/a2a-sdk-go
dotnet add package A2A.SDK

Cross-language consistency makes technical decisions easier: the backend team can write a client in Python, the platform team in Go, and the frontend agent team in TypeScript — all speaking the same protocol with identical semantics. You're no longer locked into one language just because it's the only mature SDK.

#The Enterprise Ecosystem and Roadmap

Behind the specification, there's a growing ecosystem. Google's ADK (Agent Development Kit) now supports A2A natively — an ADK agent can be exposed as a remote A2A agent and vice versa (we practiced this in episode 12). More than 150 organizations are part of the ecosystem, with production adoption at enterprise companies — not just proofs of concept.

The value of the heterogeneous TSC membership (AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow) shouldn't be underestimated: every standards decision goes through cross-vendor consideration, so no single company can steer the protocol's direction for its own benefit. For those of you working at a company that has to choose a standard, this kind of governance argument is often the main differentiator between a protocol that survives and one that fades.

Where is it heading? The official roadmap names three axes:

• Discovery improvement — finding the right agent from a large catalog more efficiently, strengthening cooperation with the registries discussed in episode 16.
• Advanced security — deepening the trust model, handling prompt injection, and zero-trust policies between agents.
• Ecosystem interop expansion — broadening interoperation with surrounding protocols (MCP, AG-UI, and the commerce layers we covered in episode 19).

#Conclusion

Episode 21 sums up A2A's state today: a stable v1.0 with signed agent cards, multi-tenancy, and version negotiation as its three new pillars; three bindings and five official SDKs guaranteeing portability; and a Linux Foundation ecosystem inhabited by big vendors providing cross-company legitimacy. The forward roadmap promises smarter discovery, deeper security, and broader interop.

Here's the core takeaway:

• v1.0 (March 2026) is the first stable release; v1.0.1 is a maintenance patch.
• Signed agent cards move trust from claims to cryptographic verification.
• Multi-tenancy and version negotiation solve two major operational problems.
• Official SDKs exist for Python, Go, JavaScript/TypeScript, Java, and .NET.
• The roadmap focuses on discovery, security, and broadening ecosystem interop.

Episode 22 closes the series: we'll compare A2A with alternatives like MCP and AG-UI, decide when A2A is the right choice, and close the whole 0-22 journey with a complete production checklist. See you there!