You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
My ecosystem has a bunch of agents talking A2A, primarily 0.3.0. I'd like to evolve the ecosystem to export services for 0.3.0 and 1.0.0. Is there a plan to support both in the same library?
Describe the solution you'd like
It would be useful to have APIs that convert between 0.3.0 and 1.0.0. I believe that most systems would start exposing 1.0.0 as a proxy for 0.3.0 and then migrate their implementation to be 1.0.0 compliant with a proxy that serves 0.3.0.
Hi @sduskis thank you for flagging this. We made a conscious decision in the run-up to 1.0 to not support 0.3.0 of the spec.
However, we realise now that this might have been the wrong decision. Also, as the spec evolves beyond 1.0 we will need to support multiple protocols anyway. So we will look into this, and use this issue to discuss between ourselves.
It might not make it in time for our 1.0 release, but we think we can include it in a later 1.0.x release.
Hi, we just had a long meeting about this this morning, and will work on this next :-)
I'm currently looking at #757 which is a big breaking change, but think we can release a beta once this works.
Then we have a few TCK issues to sort out, but hopefully the 1.0 final release isn't too far away
@cammckenzie-atlassian@sduskis FYI we have started working on this, and the WIP is in https://github.com/a2aproject/a2a-java/pulls.
We've almost got the 0.3 TCK working against a server provisioned with the 0.3 protocol.
Next step will be to look into what we need to do to be able to use both protocols at the same time.
@kabir I have just had a chance to look at this. My hope was that the conversion of types etc. was going to be handled by the compatibility layer, but unless I'm misinterpreting it seems like we would need to explicitly use a different client when communicating with a legacy server (0.3) and deal with all the 0.3 types in the code?
This means essentially we have to duplicate any interactions with the A2A client (or write our own wrapper that maps 0.3 types into 1.0 types) until we can be sure that all of the servers we communicate with have moved to 1.0.
I can see from what you say that this might be a bit tricky from a user perspective now that you mention it.
One rough idea is that perhaps an option could be to create a compatibility mode for the main client, so that it delegates to the 0.3 client?
Then it could do similar conversion to how we do it on the server between the 0.3 and 1.0 types.
However, some of the methods changed names between the protocol versions, and names of things in the nested parameters and return types might have changed too. But since we're able to do this in the server conversion layer, that might not be an issue.
But there are some big proposed changes in the spec which I haven't digested yet, but might cause some problems going forward for this approach.
I haven't looked deeply at this, and won't be able to for a while.
If you have time to look/propose something, we'd be happy to provide guidance/review :-)
Activity
kabir commentedon Mar 23, 2026
Hi @sduskis thank you for flagging this. We made a conscious decision in the run-up to 1.0 to not support 0.3.0 of the spec.
However, we realise now that this might have been the wrong decision. Also, as the spec evolves beyond 1.0 we will need to support multiple protocols anyway. So we will look into this, and use this issue to discuss between ourselves.
It might not make it in time for our 1.0 release, but we think we can include it in a later 1.0.x release.
cammckenzie-atlassian commentedon Apr 8, 2026
hey @kabir ,
Have there been any more thoughts about this? We are in the process of working out how we will support the migration from 0.3 to 1.0.
Also, are there any ETAs on when there will be a stable 1.0 release?
Cheers
[-][Feat]: A2A v0.3.0 and v1.0.0 Coexistance[/-][+][Feat]: A2A v0.3.0 and v1.0.0 Coexistence[/+]kabir commentedon Apr 9, 2026
Hi, we just had a long meeting about this this morning, and will work on this next :-)
I'm currently looking at #757 which is a big breaking change, but think we can release a beta once this works.
Then we have a few TCK issues to sort out, but hopefully the 1.0 final release isn't too far away
kabir commentedon Apr 21, 2026
@cammckenzie-atlassian @sduskis FYI we have started working on this, and the WIP is in https://github.com/a2aproject/a2a-java/pulls.
We've almost got the 0.3 TCK working against a server provisioned with the 0.3 protocol.
Next step will be to look into what we need to do to be able to use both protocols at the same time.
cammckenzie-atlassian commentedon Apr 21, 2026
Amazing, thanks @kabir
kabir commentedon May 6, 2026
@sduskis @cammckenzie-atlassian The bulk of it is done in #805. Note there are a few followup issues in #854, #855, #856 and #857
cammckenzie-atlassian commentedon May 6, 2026
Great, thanks for the updates @kabir
kabir commentedon May 21, 2026
Done by #805 #859 #857
cammckenzie-atlassian commentedon Jul 7, 2026
@kabir I have just had a chance to look at this. My hope was that the conversion of types etc. was going to be handled by the compatibility layer, but unless I'm misinterpreting it seems like we would need to explicitly use a different client when communicating with a legacy server (0.3) and deal with all the 0.3 types in the code?
This means essentially we have to duplicate any interactions with the A2A client (or write our own wrapper that maps 0.3 types into 1.0 types) until we can be sure that all of the servers we communicate with have moved to 1.0.
Am I missing something?
Cheers
kabir commentedon Jul 7, 2026
Hi, yes that is the way it works at the moment.
I can see from what you say that this might be a bit tricky from a user perspective now that you mention it.
One rough idea is that perhaps an option could be to create a compatibility mode for the main client, so that it delegates to the 0.3 client?
Then it could do similar conversion to how we do it on the server between the 0.3 and 1.0 types.
However, some of the methods changed names between the protocol versions, and names of things in the nested parameters and return types might have changed too. But since we're able to do this in the server conversion layer, that might not be an issue.
But there are some big proposed changes in the spec which I haven't digested yet, but might cause some problems going forward for this approach.
I haven't looked deeply at this, and won't be able to for a while.
If you have time to look/propose something, we'd be happy to provide guidance/review :-)
kabir commentedon Sep 16, 2026
@cammckenzie-atlassian Please see #1151. It isn't totally finished yet, but I hope it will be later this week.