What's New in A2A: v1.0

Originally published on dev.to / Medium.

A2A Documentations & New Updates.

🎉 A2A reached v1.0 — a production-ready, open standard for agents to talk to each other. It was created by Google but now it’s maintained under the Linux Foundation by a Technical Steering Committee(TSC) spanning eight companies (AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow).

I have been attending these TSC meetings and met Google’s Software Engineers who are working on A2A. Based on what I saw and understood, this v1.0 is really big news and we are planning more cool and exiting things 😀. For today let us focus on what’s new under the hood in A2A’s v1.0, a Python ( 📦 a2a-python SDK) developer-experience glow-up worth getting excited about, and a fresh new look on the surface to match. ✨

What’s new in v1.0

v1.0 is about making A2A protocol stable, standardized, and enterprise-grade — and building it so the A2A SDKs can keep evolving without breaking everyone down the line. The changes group into four themes: 1️⃣ protocol maturity, 2️⃣ stronger type safety, 3️⃣ a better developer experience, and 4️⃣ enterprise-ready features.

Here’s what’s worth your attention.

→ Enterprise-ready security and identity. Agent Cards can now be cryptographically signed and verified (JWS, per RFC 7515, with JSON Canonicalization per RFC 8785), so you can trust that an agent is who it claims to be. OAuth 2.0 support was modernized too: the Device Code flow (RFC 8628) is in for CLI, IoT, and headless agents, PKCE is supported, and the insecure implicit and password flows are gone.

→ Multi-tenancy, built in. A native tenant field means a single endpoint can serve multiple agents or tenants — no more bolting it on yourself.

→ Listing that scales. A new ListTasks operation adds filtering and cursor-based pagination, so task listing holds up as your agents get busy.

→ Consistent behavior across every transport. Errors are now standardized on google.rpc.Status / ErrorInfo, so you get the same error shape whether you're on JSON-RPC, gRPC, or HTTP+JSON. And version negotiation via the A2A-Version header — with the protocol version declared per interface — means a single agent can support multiple protocol versions at once. That's the mechanism that makes graceful, backward-compatible upgrades possible.

→ A cleaner data model. The big one: text, file, and data are unified into a single Part type — no more separate TextPart / FilePart / DataPart, and no kind discriminator to carry around. Enum values are standardized to SCREAMING_SNAKE_CASE for ProtoJSON compliance, timestamps are ISO-8601 with milliseconds, and tasks now carry createdAt / lastModified. IDs are simple UUIDs (no compound tasks/{id}), and the /v1 HTTP path prefix is gone.

Straight talk: yes, several of these are breaking changes. v1.0 is a genuine version bump, not a coat of paint. The payoff is a protocol that’s stable, standardized, and designed so that future versions won’t keep breaking your integrations.

Want more details? Three links cover it: the What’s new in v1.0 guide (five minutes to find out if anything affects you), the full specification for the canonical reference, and — if you’re on Python — the v1.0 migration guide. Stuck on something? The community hangs out in GitHub Discussions — a good place to ask.

Provably interoperable — the Integration Test Kit

The whole promise of A2A is that agents built by different teams, in different languages, actually interoperate — and the A2A Integration Test Kit (ITK) is how that gets proven rather than asserted. If you ship across SDKs or languages, the public ITK dashboard shows you which combinations are known-good — a daily snapshot of nightly cross-SDK runs (not a live or real-time view). For the full story on how it works, the ITK dashboard deep-dive covers it.

https://a2aproject.github.io/a2a-itk/dashboard/

The Python DX glow-up

Here’s the part I’m genuinely excited about. v1.0 didn’t just tighten the protocol — it gave the Python SDK a real developer-experience glow-up, and most of it lives in one new module: a2a.helpers.

Instead of hunting through scattered a2a.utils.* imports, you get a single consolidated import with friendly factory functions for the things you do all day: building messages, parts, tasks, and artifacts (new_text_message, new_task, new_text_artifact, …); creating the status and artifact update events you enqueue while streaming (new_text_status_update_event, new_text_artifact_update_event, plus data/raw/url variants); and pulling content back out (get_message_text, get_text_parts, get_stream_response_text). One import, far less boilerplate.

The before/after says it best — and spinning up a client got the same treatment, with create_client() (from a2a.client) collapsing the old ClientFactory dance into a single await:

##############################################################
# Before — v0.3: wrapper types by hand, and a client factory
##############################################################
message = Message(role=Role.user, parts=[Part(TextPart(text="hi"))])

factory = ClientFactory()
client = factory.create_client(url)

##############################################################
# After - v1.0: one helper each
##############################################################
from a2a.helpers import new_text_message
from a2a.client import create_client

message = new_text_message("hi", role=Role.ROLE_USER)
client = await create_client(url)

That’s the flavor of the whole release: fewer wrapper types, fewer lines, less to remember. Upgrading an existing agent? The v1.0 migration guide walks you through it — and you can run a v1.0 server with v0.3 compatibility enabled, so you don’t have to migrate every client at once.

A fresh look to match

A milestone like this deserves a face — so the parts you see first got attention too.

A friendlier home. a2a-protocol.org has a redesigned home page and navigation, reorganized around one question: what do you want to do next? Less overwhelming, easier to find your starting point — whether that’s a five-minute “what is A2A?”, the full spec, or the hands-on Python tutorial.

# New Homepage\ At the top of the home page, we’ve added Get started and Read the spec buttons, allowing you to instantly jump straight to the resources you need based on your immediate goals.

A2A Home Page — https://a2a-protocol.org/latest/

# Restructured Navigation\ We’ve reorganized our previous layout into highly focused, grouped sections, making it effortless to pinpoint your specific topic of interest and dive right into development.

A2A — restructured navigation

# New A2A logo\ A cleaner, more consistent mark across the docs, the repo, and everywhere A2A shows up.

A2A New Logo

# Lastly, our new A2A Mascot

A2A now has one: a friendly orange-and-cream, a puppy — sitting, tongue out, wearing a collar with an “A2A” dog tag. It’s the warmth a spec and a governance doc can’t quite carry on their own: approachable, a little playful, and (fittingly for an interoperability protocol) happy to make friends with anyone.

The protocol is grown-up and production-ready; the project should still feel like somewhere you’d want to hang out and contribute.

A2A Mascot

Coming next

One more thing worth flagging: the next post digs into A2A multi-tenancy — how the native tenant model dramatically simplifies building multi-agent applications, letting a single deployment serve many agents and tenants cleanly. If you’re building anything beyond a single agent, it’ll be worth your time. More soon.

What to do next

To see what changed, check What’s new in v1.0 guide — five minutes to find out if anything affects you.
Need to upgrade your Python A2A Agent? Start with the migration guide — and remember you can run a v1.0 server with v0.3 compatibility while you transition.
To check inter-op for A2A app, start with ITK compatibility dashboard.

Community Request: We are actively looking to grow our A2A community and expand our A2A blog content. If you have ideas, feedback, or unique insights, your suggestions are incredibly welcome!