New Feature - Add Ability for Server/Client to Specify Supported A2A Protocol Versions

[izzymsft]

A couple of days ago, I created this issue but I would love to check what the community thinks about adding this capability to the protocol.

Right now, I am recommending specifying the supported protocol versions in the AgentCard but the clients can send it in the request header. A colleague was suggesting that it should be in the payload itself. I would love to know what you think about these recommendations and share you ideas here. I think this should be added in the next version 0.3.0 and beyond.

After some discussion, I could submit a draft PR for the community to review.

These are my initial thoughts and here are my reasons for making this recommendation:

Backward and Forward Compatibility

• Agents evolve - new protocol versions introduce features and clients may not be ready for it yet.
• Clients may not upgrade immediately; they must still interoperate with servers using older protocol versions.
• Supporting multiple protocol versions ensures cross-version communication, enabling broader adoption.

Interoperability Across Multiple Instances of Clients/Servers

In a federated multi-agent ecosystem, agents may be:

• Built using different frameworks
• Managed by different organizations
• Evolving at different paces.

Supporting multiple protocol versions ensures agents from different teams and organizations can still collaborate.

Graceful Feature Negotiation

• Later versions may introduce optional capabilities
• Clients and servers that can detect and negotiate features based on the AgentCard metadata can dynamically downgrade behavior.
• This enables progressive enhancements - clients can use advanced features if supported, but fall back gracefully otherwise.

Enterprise Stability and Security

In regulated or mission-critical environments:

• Servers may lock to specific protocol versions for compliance reasons.
• Clients may need to validate protocol version support before transmitting sensitive data.
• Version support for the protocol enables auditable, policy-driven deployments for both clients and servers.

Testing, Migration, and Compatibility Assurance

Developers and DevOps teams need to test new protocol versions while still supporting production traffic using older ones.
Supporting versioning lets systems:

• Run A/B tests
• Perform blue/green deployments
• Roll out changes incrementally.

Extensibility Without Breakage

A stable versioning model allows the A2A clients and servers to:

• Introduce experimental features safely,
• Avoid breaking older clients with newer schemas and data structures.

[izzymsft]

#652 and #653 documents the need for this discussion.