Upgrade a2a-sdk dependency to support A2A 1.0 spec

Summary

The A2A Python SDK (a2a-sdk) has released v1.0.0-alpha.0 (2026-03-17) which upgrades to the A2A 1.0 spec with proto-based types.

Currently, ADK 1.28 depends on a2a-sdk 0.3.24 which uses protocol_version: "0.3.0".

Request

Upgrade the a2a-sdk dependency in google-adk[a2a] to support the A2A 1.0 specification, including:

Proto-based types from a2a-sdk >= 1.0.0
Updated protocol_version default to 1.0.0
Any breaking changes in AgentCard, AgentSkill, and related types

References

A2A SDK release: https://github.com/google/a2a-python/releases/tag/v1.0.0-alpha.0
Breaking changes commit: spec upgrade SDK to A2A 1.0 spec and use proto-based types (Request for CMEK Support in Vertex AI Agent Engine #572, Error with multiple function calls when token streaming via LiteLLM and adk web #665, VertexAiSessionService list sessions always returns empty list #804, Problem with retrive live conversation using sessions. #765)

@kaligautier

Hi @kaligautier , Thanks for reporting!
Your request is being reviewed, and we will update if further information is needed. Thanks for your patience.

@sanketpatil06

@sanketpatil06 @kaligautier I Implemented the upgrade to a2a-sdk >= 1.0.0a0 so I'm creating a PR

a2a v1 was released yesterday.

a2a v1 was released yesterday.

hello sir ,can you provide me documentation for a2a latest version I'll implement with updated version

a2a v1 was released yesterday.

https://github.com/a2aproject/A2A/releases 12 march

Also, the python sdk (which i mean that was released yesterday) and that is relevant for this project

https://github.com/a2aproject/a2a-python/releases/tag/v1.0.0

@gustavomonarin

can I try to update according to latest a2a or is it an internal team work ?? @gustavomonarin @kaligautier ??

I am not maintainer nor contributor, so can't really answer.

But looking at ur previous pr, it seems it was very well accepted, no?

@ankursharmas

@ankursharmas @llalitkumarrr any chance this could be part of the v2 release?

how could we help?

Is this issue still being worked on?

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

a2a-sdk is currently on version 1.0.3

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

a2a-sdk is currently on version 1.0.3

I see at pyproject.toml that is set to <0.4 (https://github.com/google/adk-python/blob/main/pyproject.toml#L65)

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

a2a-sdk is currently on version 1.0.3

I see at pyproject.toml that is set to <0.4 (https://github.com/google/adk-python/blob/main/pyproject.toml#L65)

yes, but the 1.0 sdk has some breaking changes and This is the migration guide.
https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

a2a-sdk is currently on version 1.0.3

I see at pyproject.toml that is set to <0.4 (https://github.com/google/adk-python/blob/main/pyproject.toml#L65)

yes, but the 1.0 sdk has some breaking changes and This is the migration guide. https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md

that is what I'm asking if/when we are targeting to move adk-python to a2a-sdk >= 1.0 (which will require adaptations as stated in the migration doc)

Submitted PR #5917 implementing this upgrade.

any estimated timeline about when/if a2a-sdk is going to be bumpd to >= 1.0?

a2a-sdk is currently on version 1.0.3

I see at pyproject.toml that is set to <0.4 (https://github.com/google/adk-python/blob/main/pyproject.toml#L65)

yes, but the 1.0 sdk has some breaking changes and This is the migration guide. https://github.com/a2aproject/a2a-python/blob/main/docs/migrations/v1_0/README.md

that is what I'm asking if/when we are targeting to move adk-python to a2a-sdk >= 1.0 (which will require adaptations as stated in the migration doc)

A PR has been raised for this.

feat(a2a): upgrade a2a-sdk dependency from >=0.3.4,<0.4 to >=1.0,<2

Hi everyone, thanks for raising this issue!
We want to let the community know that the Google A2A engineering team is actively working on bringing a2a-sdk 1.0 support to ADK. We want to make sure the integration is done in a way that aligns with our best practices - in particular, we're targeting a non-breaking dual-version approach that keeps existing a2a-sdk 0.3.x users fully functional while enabling 1.0 at the same time.

Adding a capability-gap perspective from a downstream user, in case it helps prioritize this.

We hit this building an ADK orchestrator that acts as an A2A client (RemoteA2aAgent) delegating to a second ADK agent exposed as an A2A server (to_a2a), fronted by the AG-UI middleware. Two angles:

1. It's not only "missing features" — mixed environments break at import

google-adk[a2a] 2.3.0 pins a2a-sdk>=0.3.4,<0.4. In an environment where a2a-sdk 1.1.0 ended up installed, both public A2A entry points fail hard at import time (not a graceful degradation):

from google.adk.agents.remote_a2a_agent import RemoteA2aAgent
  → ImportError: cannot import name 'ClientEvent' from 'a2a.client'

from google.adk.a2a.utils.agent_to_a2a import to_a2a
  → ModuleNotFoundError: No module named 'a2a.server.apps'

Root cause is the 1.x refactor: ClientEvent / ClientTaskManager / Consumers were removed from a2a.client, and the A2AStarletteApplication wrapper under a2a.server.apps was replaced by route-based endpoints (add_routes_to_app → Starlette routes). So the current pin isn't just conservative — it actively strands anyone who co-installs a modern a2a-sdk.

2. Concrete capabilities the 0.3.x pin blocks

Pinned to <0.4, ADK A2A users can't reach any of the following that a2a-sdk 1.x ships:

Multi-transport clients. 1.x has a real transport abstraction (a2a.client.transports: jsonrpc.py, rest.py, grpc.py) selectable via ClientConfig.supported_protocol_bindings / grpc_channel_factory. Today ADK is effectively JSON-RPC + http+json only — no gRPC, which matters for high-throughput / streaming agent-to-agent links and for enterprises standardizing on gRPC meshes.
Proto-based types (a2a.types.a2a_pb2). Cross-language schema parity (same AgentCard/Task/Message protos across Python/Java/Go) and the foundation for the gRPC binding.
Agent Extensions. The A2A-Extensions header + AgentExtension on the card + with_a2a_extensions let agents advertise and negotiate capabilities beyond the base spec — the intended path for adding features without forking the protocol. Not reachable on 0.3.x.
Richer client config. ClientFactory/Client/ClientConfig with use_client_preference, polling, and per-call push_notification_config (now singular).
Push notifications across all owners and multi-tenant server support (tenant_decorator), plus DefaultContextBuilder.build_user for custom A2A user resolution — useful for multi-user/multi-tenant orchestrators.

3. Migration cost is real but bounded

The breaking surface is mostly on the server-construction side (A2AStarletteApplication wrapper → add_routes_to_app routes) and a few renames (push_notification_config plural→singular; removal of ClientEvent/ClientTaskManager/Consumers). ADK's own to_a2a / A2aAgentExecutor are the main touch points; RemoteA2aAgent already reads AGENT_CARD_WELL_KNOWN_PATH from the SDK with a fallback, so the well-known path change (/.well-known/agent.json → /.well-known/agent-card.json) is partly absorbed.

Given #5056 is already tracking the version bump (and there's a v1.0.0-alpha.0 branch), the main asks from a consumer standpoint would be:

Land the bump so gRPC/extensions become reachable, and
Consider a slightly wider version range or a clearer runtime error when an incompatible a2a-sdk is present, so co-installed environments fail with a helpful message instead of a raw ImportError.

Happy to test the [a2a] extra against a real orchestrator↔A2A-server ADK setup once the bump lands.

Important

A2A 1.x.x support has landed in ADK 2.5.0 - ADK now supports both a2a-sdk 0.3.x and 1.x.x via a version-compatibility layer.

Rather than a hard cutover from a2a-sdk 0.3.x to 1.x.x (a breaking change for everyone still on 0.3.x), we implemented a compatibility layer so ADK works against both a2a-sdk majors from the same codebase. The active version is detected at import time, and every diverging API is routed through version-agnostic helpers.

Shipped in 930e472 - see the commit for details.

Note

What this means for you

a2a-sdk 0.3.x is deprecated and won't receive further updates, so we recommend migrating to a2a-sdk 1.x.x. For most agents this is just a dependency constraint change, but if you have custom A2A logic (e.g. interceptors, custom transports, or direct use of a2a imports) you'll need to migrate it.

See the A2A 1.0 migration guide.

Navigation Menu

Repository navigation

Upgrade a2a-sdk dependency to support A2A 1.0 spec #5056

Summary

Request

References

1. It's not only "missing features" — mixed environments break at import

2. Concrete capabilities the 0.3.x pin blocks

3. Migration cost is real but bounded

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Upgrade a2a-sdk dependency to support A2A 1.0 spec #5056

Description

Summary

Request

References

Activity

sanketpatil06 commented on Mar 31, 2026

Sravan1011 commented on Apr 5, 2026

gustavomonarin commented on Apr 21, 2026

Sravan1011 commented on Apr 21, 2026

kaligautier commented on Apr 21, 2026

gustavomonarin commented on Apr 21, 2026

Sravan1011 commented on Apr 22, 2026

gustavomonarin commented on Apr 22, 2026

gustavomonarin commented on May 13, 2026

waadarsh commented on May 21, 2026

luis5tb commented on May 29, 2026

waadarsh commented on May 29, 2026

luis5tb commented on May 29, 2026

waadarsh commented on May 29, 2026

luis5tb commented on May 29, 2026

waadarsh commented on May 31, 2026

waadarsh commented on Jun 2, 2026

mykytanetipa commented on Jun 19, 2026

ferponse commented on Jul 2, 2026

1. It's not only "missing features" — mixed environments break at import

2. Concrete capabilities the 0.3.x pin blocks

3. Migration cost is real but bounded

mykytanetipa commented on Jul 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions