Hi,
Currently, when serving an AgentCard in protocol 1.0, the SDK automatically generates backward-compatible fields from version 0.3 (protocolVersion, url, preferredTransport, additionalInterfaces, supportsAuthenticatedExtendedCard) and merges them into the 1.0 card response.
I understand that the enable_v0_3_compat flag controls the generation of v0.3-compatible routes, but this behavior is not applied in the same way to the AgentCard. I have two questions:
-
Are there plans to extend enable_v0_3_compat control to the AgentCard? — In the same way the flag controls the generation of v0.3-compatible routes, it would be useful for it to also control whether legacy fields are merged into the 1.0 card or not. That is, with enable_v0_3_compat=False, the card should be served "clean" without any v0.3 fields merged in.
-
How long is this policy of merging both protocols into the same AgentCard expected to be maintained? — Is there any roadmap or estimated date for deprecating/removing the automatic generation of v0.3 fields in the 1.0 card?
Context: In our use case, we would prefer to manage the compatibility between both protocols in the card using the enable_v0_3_compat argument set to True or False, just as it is already done for route generation. This would bring consistency to the flag's behavior and semantic clarity to the discovery document.
Thanks in advance.
Hi,
Currently, when serving an AgentCard in protocol 1.0, the SDK automatically generates backward-compatible fields from version 0.3 (
protocolVersion,url,preferredTransport,additionalInterfaces,supportsAuthenticatedExtendedCard) and merges them into the 1.0 card response.I understand that the
enable_v0_3_compatflag controls the generation of v0.3-compatible routes, but this behavior is not applied in the same way to the AgentCard. I have two questions:Are there plans to extend
enable_v0_3_compatcontrol to the AgentCard? — In the same way the flag controls the generation of v0.3-compatible routes, it would be useful for it to also control whether legacy fields are merged into the 1.0 card or not. That is, withenable_v0_3_compat=False, the card should be served "clean" without any v0.3 fields merged in.How long is this policy of merging both protocols into the same AgentCard expected to be maintained? — Is there any roadmap or estimated date for deprecating/removing the automatic generation of v0.3 fields in the 1.0 card?
Context: In our use case, we would prefer to manage the compatibility between both protocols in the card using the
enable_v0_3_compatargument set toTrueorFalse, just as it is already done for route generation. This would bring consistency to the flag's behavior and semantic clarity to the discovery document.Thanks in advance.