Summary

This proposal establishes a framework for extending the A2A Protocol while maintaining interoperability and clear governance. It defines a tiered system for official and experimental extensions, along with a promotion pathway from community contributions to officially maintained extensions.

Motivation

A2A currently provides extension points in the specification, allowing agents to advertise and negotiate extended capabilities via the AgentCard.capabilities.extensions field. However, there is no formal guidance on:

• How extensions are proposed or adopted into the official A2A organization
• What governance applies to official vs. experimental extensions
• How community extensions can be promoted to official status
• What expectations exist around implementation, documentation, and maintenance

Without a defined process, the ecosystem risks fragmentation, with incompatible extensions emerging without clear ownership or quality standards.

Several community extensions already exist that demonstrate the need for this framework:

• A2UI - Agent-to-Agent UI extension for streaming interactive interfaces
• AP2 - Agent Payments Protocol extension
• Trajectory - Extension for tracking agent reasoning steps
• Approval - Human-in-the-loop approval extension

This proposal encompasses a similar governance model to MCP Extensions which was recently adopted.

Proposal

Extension Definition

An A2A extension is an optional addition to the specification that defines capabilities beyond the core protocol. Extensions enable functionality that may be:

• Modular: Distinct features like UI rendering or payments
• Specialized: Industry-specific logic (e.g., commerce, healthcare)
• Experimental: Features being incubated for potential core inclusion

Extensions are identified using a unique extension identifier (URI), as already defined in the A2A specification. For example:

• https://a2ui.org/a2a-extension/a2ui/v0.9
• https://github.com/google-agentic-commerce/ap2/tree/v0.1

For official extensions maintained under the A2A organization, identifiers MUST use the https://a2a-protocol.org/extensions/ prefix, e.g., https://a2a-protocol.org/extensions/ui/v1.

Breaking changes MUST use a new identifier. A breaking change is any modification that would cause existing compliant implementations to fail or behave incorrectly.

Extension Tiers

This proposal defines two tiers of extensions within the A2A organization:

Official Extensions

Official extensions are developed and maintained under the a2aproject GitHub organization, officially recommended by the TSC, and use the https://a2a-protocol.org/extensions/ URI prefix.

Repository Structure:

• Extension repositories use the ext- prefix: github.com/a2aproject/ext-{name}
• Examples: ext-ui, ext-payments, ext-auth
• Each repository has designated maintainers identified in MAINTAINERS.md

Requirements:

• Extension specifications MUST use the same language as the core specification (RFC2119)
• Extensions MUST be licensed under Apache 2.0
• Extensions MUST have at least one reference implementation
• Extensions SHOULD have associated documentation on the A2A website

Experimental Extensions

Experimental extensions provide an incubation pathway for community contributors to prototype and collaborate on extension ideas before graduation to official status.

Repository Structure:

• Experimental repositories use the experimental-ext- prefix: github.com/a2aproject/experimental-ext-{name}
• Example: experimental-ext-orchestration

Creation Requirements:

• An experimental extension repository can ONLY be created with sponsorship from an A2A Maintainer
• The sponsoring Maintainer is responsible for initial oversight of the experimental extension
• Experimental repositories MUST clearly indicate their experimental/non-official status in the README
• Any published packages MUST use naming that clearly indicates experimental status
• The TSC retains oversight, including the ability to archive or remove experimental repositories

Lifecycle

1. Proposal Phase

Any community member may propose an extension:

1. Open an Issue: Create an issue in the main a2aproject/A2A repository describing:
   • Abstract describing the extension's purpose
   • Motivation explaining why this cannot be achieved with the core protocol
   • Initial technical approach or specification draft
2. Community Discussion: The proposal is open for community feedback and refinement

2. Maintainer Sponsorship

For a proposal to proceed to experimental status:

1. Secure a Sponsor: An A2A Maintainer must agree to sponsor the extension proposal
2. Repository Creation: The sponsoring Maintainer creates the experimental-ext-* repository under a2aproject
3. Oversight: The sponsoring Maintainer provides initial oversight and ensures alignment with A2A design principles

3. Experimental Development

While in experimental status:

• Contributors iterate on the specification and reference implementations
• The experimental extension MAY be used by early adopters with the understanding that breaking changes are expected
• Community feedback is gathered and incorporated
• The experimental repository MUST clearly indicate its non-official status

4. Graduation to Official Extension

To graduate an experimental extension to official status:

1. Maturity Requirements:

   • At least one production-quality reference implementation
   • Documentation meeting A2A standards
   • Evidence of community adoption or interest
   • Clear maintainer commitment for ongoing maintenance

2. Graduation Proposal: Open an issue in a2aproject/A2A with:

   • Reference to the experimental repository and its implementations
   • Summary of community feedback and adoption
   • Proposed maintainers for the official extension

3. TSC Vote:

   • The proposal is added to the TSC meeting agenda
   • Quorum Requirement: At least 50% of TSC voting members must be present
   • Approval: Requires majority vote of those in attendance (per A2A governance)
   • The TSC may request revisions before a final vote

4. Acceptance:

   • Upon approval, the repository is renamed from experimental-ext-* to ext-*
   • Documentation is added to the A2A website's extensions page

5. Official Extension Iteration

Once official, extensions may be iterated on without further TSC review for non-breaking changes:

• Extension repository maintainers are responsible for day-to-day governance
• Changes SHOULD be coordinated via the relevant working group if one exists
• Breaking changes require a new extension identifier
• Maintainers SHOULD coordinate with SDK maintainers for implementation updates

6. Promotion to Core Protocol (Optional)

Some extensions may eventually transition to core protocol features. This is governed through the existing A2A specification enhancement process:

• A proposal is submitted following the standard specification change process
• The proposal references the official extension and its adoption
• TSC vote with standard quorum and majority requirements applies
• Not all extensions are suitable for core inclusion; many will remain as extensions indefinitely

Specification Recommendations

Extensions will be referenced from a new page on the A2A website at a2a-protocol.org/extensions with:

• List of official extensions with status and links
• List of experimental extensions with clear status indicators

The core specification MAY link to relevant extensions where appropriate (e.g., the extensions section could reference official extensions), but such links MUST clearly indicate the optional nature of extensions.

SDK Implementation

A2A SDKs MAY implement extensions:

• Where implemented, extensions MUST be disabled by default and require explicit opt-in
• SDK documentation SHOULD list supported extensions
• SDK maintainers have full autonomy over extension support decisions
• Extension support is not required for protocol conformance

Capability Negotiation

Extensions continue to use the existing A2A capability negotiation mechanism:

Agent Card Advertisement:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://a2a-protocol.org/extensions/ui/v1",
        "description": "Ability to render interactive UI",
        "required": false,
        "params": { ... }
      }
    ]
  }
}

Activation: Extensions are activated via the transport-defined mechanism (e.g., A2A-Extensions header for HTTP/JSON-RPC).

Graceful Degradation: If one party supports an extension but the other does not, the supporting party MUST either fall back to core protocol behavior or clearly indicate that the extension is required.

Legal Requirements

Licensing

Official extensions MUST be available under the Apache 2.0 license, consistent with the core A2A project.

Contributor License Grant

By submitting a contribution to an official A2A extension repository, contributors represent that:

1. They have the legal authority to grant the rights
2. The contribution is original work or they have sufficient rights to submit it
3. They grant to the Linux Foundation and recipients a perpetual, worldwide, non-exclusive, royalty-free license to use, reproduce, modify, and distribute the contribution

Antitrust

Extension developers acknowledge that:

• They may compete with other participants
• They have no obligation to implement any extension
• They are free to develop competing extensions
• Status as an official extension does not create an exclusive relationship

Not Specified

This proposal intentionally does not address:

• Schema validation: How extensions advertise schema modifications
• Dependencies: Inter-extension dependencies or core version requirements
• Profiles: Grouping extensions into capability profiles

These may be addressed in future proposals as the extension ecosystem matures.

Rationale

This design follows these principles:

• Alignment with A2A Governance: The TSC maintains authority over official extensions through the voting process, consistent with existing governance
• Clear Tiering: Separating official from experimental extensions sets appropriate expectations
• Community Pathway: Experimental extensions allow community innovation while maintaining quality standards for official status
• Delegated Maintenance: Day-to-day extension governance is delegated to maintainers, reducing TSC burden
• Compatibility with Existing Extensions: Current community extensions (A2UI, AP2, etc.) can follow this process to become official

Backward Compatibility

This proposal is purely additive and does not modify the core protocol. Existing community extensions continue to work unchanged. The extension capability negotiation mechanism already exists in the specification.

References

• A2A Extensions Specification
• MCP SEP-2133: Extensions Framework
• MCP ext-apps (Official Extension Example)
• MCP experimental-ext-interceptors (Experimental Extension Example)

Example Extensions for Initial Consideration

The following community extensions could be candidates for the graduation process once this framework is adopted: