refactor(spec)!: Move `extendedAgentCard` field to `AgentCapabilities` by madankumarpichamuthu · Pull Request #1307 · a2aproject/A2A

madankumarpichamuthu · 2025-12-11T19:22:47Z

Relocates supports_extended_agent_card from AgentCard to AgentCapabilities for architectural consistency. All optional features that enable specific operations now reside in the capabilities object.

Rationale:

Consistent placement: streaming, push_notifications, and state_transition_history are all in AgentCapabilities
Improved discoverability: developers naturally check capabilities for optional features
Semantic correctness: extended agent card support is a capability

Changes:

Proto: Removed field 13 from AgentCard, added field 5 to AgentCapabilities
Field renamed: supports_extended_agent_card → extended_agent_card
Updated all references: AgentCard.supportsExtendedAgentCard → AgentCard.capabilities.extendedAgentCard
Updated JSON examples to reflect new structure
Added migration guidance in Appendix A.2.2 of specification

Breaking change: Clients and agents must update capability checking logic. See specification Appendix A.2.2 for migration steps.

Fixes #1229

Relocates `supports_extended_agent_card` from AgentCard to AgentCapabilities for architectural consistency. All optional features that enable specific operations now reside in the capabilities object. Rationale: - Consistent placement: streaming, push_notifications, and state_transition_history are all in AgentCapabilities - Improved discoverability: developers naturally check capabilities for optional features - Semantic correctness: extended agent card support is a capability Changes: - Proto: Removed field 13 from AgentCard, added field 5 to AgentCapabilities - Field renamed: supports_extended_agent_card → extended_agent_card - Updated all references: AgentCard.supportsExtendedAgentCard → AgentCard.capabilities.extendedAgentCard - Updated JSON examples to reflect new structure - Added migration guidance in Appendix A.2.2 of specification Breaking change: Clients and agents must update capability checking logic. See specification Appendix A.2.2 for migration steps. Fixes a2aproject#1229

gemini-code-assist · 2025-12-11T19:23:02Z

Summary of Changes

Hello @madankumarpichamuthu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the agent specification by moving the supports_extended_agent_card field into the AgentCapabilities object. This change enhances architectural consistency, improves discoverability of optional features, and aligns with semantic correctness by grouping all capabilities in one place. The update involves modifications to the proto definition, documentation, and JSON examples, along with comprehensive migration guidance for implementers.

Highlights

Architectural Consistency: The supports_extended_agent_card field has been relocated from AgentCard to AgentCapabilities to ensure all optional features enabling specific operations reside in the AgentCapabilities object.
Field Renaming: The field name has been updated from supports_extended_agent_card to extended_agent_card for improved clarity and consistency within the AgentCapabilities structure.
Specification Updates: All documentation, including JSON examples and references within the specification, has been updated to reflect the new field location and name. A new section (Appendix A.2.2) has been added to docs/specification.md providing detailed migration guidance for clients, agents, and SDK developers.
Breaking Change: This change is a breaking change, requiring clients and agents to update their capability checking logic. Temporary fallback guidance is provided for a transition period.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request effectively refactors the supports_extended_agent_card capability by moving it into the AgentCapabilities object for better architectural consistency. The changes are applied consistently across the protocol specification, documentation, and examples. The addition of a detailed migration guide for this breaking change is particularly commendable and will be very helpful for developers. I found one minor omission in the documentation, which I've commented on. Overall, this is a high-quality contribution that improves the protocol's structure.

docs/llms.txt

Complete the list of supported features in AgentCapabilities description to include all capability fields: streaming, push notifications, state transition history, extended agent card, and extensions.

Add proper spacing around code blocks in numbered lists and consistent blank lines after section headers to satisfy markdown linter requirements.

Fix MD032 markdown linting error - lists must be surrounded by blank lines.

amye · 2025-12-15T01:59:00Z

/vote

git-vote · 2025-12-15T01:59:03Z

Vote created

@amye has called for a vote on refactor(spec)!: Move extendedAgentCardfield toAgentCapabilities`` (#1307).

The members of the following teams have binding votes:

Team
@a2aproject/a2a-tsc

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 11months 29days 3h 50m 24s. It will pass if at least 51% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

git-vote · 2025-12-16T01:59:33Z

Vote status

So far 0.00% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
0	0	0	8

Binding votes (0)

User	Vote	Timestamp
@muscariello	Pending
@darrelmiller	Pending
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@ToddSegal	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

git-vote · 2025-12-17T02:11:05Z

Vote status

So far 12.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
1	0	0	7

Binding votes (1)

User	Vote	Timestamp
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@darrelmiller	Pending
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@ToddSegal	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

git-vote · 2025-12-18T02:29:33Z

Vote status

So far 12.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
1	0	0	7

Binding votes (1)

User	Vote	Timestamp
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@darrelmiller	Pending
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@ToddSegal	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2025-12-19T02:48:30Z

Vote status

So far 12.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
1	0	0	7

Binding votes (1)

User	Vote	Timestamp
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@darrelmiller	Pending
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@ToddSegal	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

herczyn · 2025-12-19T09:57:38Z

i think this field should be removed altogether and extended agent card should return a normal card. otherwise there is no way of getting the agentcard from an agent that does not support extended agent card, which makes providing an agent just with an url impossible

Tehsmash · 2025-12-19T11:27:43Z

As discussed on discord, I agree with @herczyn.

If we go this route though, it opens up a few more questions in my mind:

Is "GetExtendedCard" still the right name?
Should all agents always call this method as part of their handshake? So the flow would always be:
1. get public agent card (could be very limited, i.e. just the supportedInterfaces)
2. call GetExtendedAgentCard (may return updated card or might return identical card, depending on user auth)
3. store and use card returned by GetExtendedAgentCard
Should this still be optional but for different reasons? For example not wanting to maintain a copy of the AgentCard (extended or not) inside of the Agent code.

IMO the "GetExtendedCard" name implies that the card will be extended, but even today it might not be extended depending on the auth of the user, but "GetPotentiallyExtendedCard" doesn't roll off the tongue 😂
Perhaps "capabilties.dynamic_card" and "GetDynamicCard" better describe this feature.

git-vote · 2025-12-20T02:49:50Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2025-12-21T03:18:30Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

darrelmiller · 2025-12-22T00:55:49Z

@herczyn @Tehsmash

This is how I am thinking about the discovery flow:

All clients will discover the agent URL from an Agent Card.
If a signature is present in the Agent Card, clients MUST verify the card contents against the signature before calling the Agent.
If an Agent Card supports an extended card, the Agent SHOULD use the provided authentication details to access the Extended Card and use that information as a replacement for the original Agent Card used for discovery.
The Extended Card MAY have additional information not included in the original card. That information MAY be specific to the authenticated caller.

I don't really have a problem with getExtendedCard just returning the same card as is publicly available if there is no extra information. There may not be today, but there may be tomorrow. e.g. an agent might add a skill but a client uses an older cached agent card. When a an agent updates, it is going to take a some time for all registries to get updated with the latest version of the card.
Also, a client may choose to block access to an updated agent until a registry administrator approves access.

I don't think we should be encouraging the sharing of direct Agent URLs, bypassing the Agent Card. There are just too many variables between protocol bindings, security config, protocol versions and all the security risks of bypassing card signatures.

git-vote · 2025-12-22T03:19:50Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2025-12-30T05:19:52Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2025-12-31T05:40:35Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-01T05:49:52Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-02T06:10:35Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-03T06:19:53Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-04T06:40:35Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-05T06:49:53Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

Tehsmash · 2026-01-05T09:25:24Z

@darrelmiller I think that makes sense to me, in this case the extended card capability just saves a round trip for clients when the agent knows that it'll always return the public card.

git-vote · 2026-01-06T07:10:36Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-07T07:19:54Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-08T07:40:36Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-09T07:49:54Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-10T08:10:36Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-11T08:19:54Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-12T08:40:37Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-13T08:49:55Z

Vote status

So far 37.50% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	5

Binding votes (3)

User	Vote	Timestamp
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@lerhaupt	Pending
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@SivaNSAP	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-14T09:10:37Z

Vote status

So far 55.56% of the users with binding vote are in favor and 0.00% are against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
5	0	0	4

Binding votes (5)

User	Vote	Timestamp
SivaNSAP	In favor	2026-01-13 16:16:56.0 +00:00:00
ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
lerhaupt	In favor	2026-01-13 21:54:53.0 +00:00:00
muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00
@geneknit	Pending
@hughesthe1st	Pending
@000-000-000-000-000	Pending
@spetschulatSFDC	Pending

Non-binding votes (1)

User	Vote	Timestamp
Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

git-vote · 2026-01-14T12:52:34Z

Vote closed

The vote passed! 🎉

55.56% of the users with binding vote were in favor and 0.00% were against (passing threshold: 51%).

Summary

In favor	Against	Abstain	Not voted
5	0	0	4

Binding votes (5)

User	Vote	Timestamp
@SivaNSAP	In favor	2026-01-13 16:16:56.0 +00:00:00
@ToddSegal	In favor	2025-12-19 19:26:14.0 +00:00:00
@darrelmiller	In favor	2025-12-20 0:14:13.0 +00:00:00
@lerhaupt	In favor	2026-01-13 21:54:53.0 +00:00:00
@muscariello	In favor	2025-12-16 12:41:24.0 +00:00:00

Non-binding votes (1)

User	Vote	Timestamp
@Tehsmash	In favor	2025-12-17 9:13:03.0 +00:00:00

🤖 I have created a release *beep* *boop* --- ## [1.0.0](v0.3.0...v1.0.0) (2026-03-12) ### ⚠ BREAKING CHANGES * **spec:** Combine `TaskPushNotificationConfig` and `PushNotificationConfig` ([#1500](#1500)) * **spec:** remove duplicated ID from the create task push config request ([#1487](#1487)) * **spec:** pluralize configs in `ListTaskPushNotificationConfigs` ([#1486](#1486)) * **spec:** Add LF prefix to the package. ([#1474](#1474)) * **spec:** Switch to non-complex IDs in requests ([#1389](#1389)) * **spec:** Standardize spelling of "canceled" to use American Spelling throughout ([#1283](#1283)) * **spec:** Align enum format with ADR-001 ProtoJSON specification ([#1384](#1384)) * **spec:** Remove redundant `final` field from `TaskStatusUpdateEvent` ([#1308](#1308)) * **spec:** Move `extendedAgentCard` field to `AgentCapabilities` ([#1307](#1307)) * **spec:** Fixes for the last_updated_after field ([#1358](#1358)) * **spec:** modernize oauth 2.0 flows - remove implicit/password, add device code / pkce ([#1303](#1303)) * **spec:** Make "message" field name consistent between protocol bindings ([#1302](#1302)) * **spec:** Remove deprecated fields from a2a.proto for v1.0 release ([#1301](#1301)) * **spec:** Rename `supportsAuthenticatedExtendedCard` to `supportsExtendedAgentCard` ([#1222](#1222)) * **spec:** Remove v1s from a2a url http bindings * **spec:** Large refactor of specification to separate application protocol definition from mapping to transports ### Features * **spec:** Add `tasks/list` method with filtering and pagination to the specification ([0a9f629](0a9f629)) * **spec:** modernize oauth 2.0 flows - remove implicit/password, add device code / pkce ([#1303](#1303)) ([525ff38](525ff38)) * **spec:** Natively Support Multi-tenancy on gRPC through an additional scope field on the request. ([#1195](#1195)) ([cfbce32](cfbce32)), closes [#1148](#1148) * **spec:** Provide ability for SDKs to be backwards compatible. ([#1401](#1401)) ([227e249](227e249)) * **spec:** Remove v1s from a2a url http bindings ([1bd263f](1bd263f)) ### Bug Fixes * Add missing metadata field to Part message in gRPC specification ([#1019](#1019)) ([b3b266d](b3b266d)), closes [#1005](#1005) * Add name field to FilePart protobuf message ([#983](#983)) ([2b7cb6f](2b7cb6f)), closes [#984](#984) * Clarify blocking calls return on interrupted states ([#1403](#1403)) ([0655ff3](0655ff3)) * **doc:** Makes JSON-RPC SendMessage response clearer ([#1241](#1241)) ([5792804](5792804)) * **docs:** Clearer wording around context id. ([#1588](#1588)) ([dec790a](dec790a)) * **grpc:** Fix inconsistent property name between gRPC and JSON-RPC in Message object ([#1100](#1100)) ([2a1f819](2a1f819)) * **grpc:** missing field in gRPC spec - state_transition_history ([#1138](#1138)) ([a2de798](a2de798)), closes [#1139](#1139) * **grpc:** Update `CreateTaskPushNotificationConfig` endpoint to `/v1/{parent=tasks/*/pushNotificationConfigs}` ([#979](#979)) ([911f9b0](911f9b0)) * **proto:** Add icon_url to a2a.proto ([#986](#986)) ([17e7f62](17e7f62)) * **proto:** Adds metadata field to A2A DataPart proto ([#1004](#1004)) ([a8b45dc](a8b45dc)) * Remove unimplemented state_transition_history capability field ([#1396](#1396)) ([c768a44](c768a44)), closes [#1228](#1228) * Restore CreateTaskPushNotificationConfig method naming ([#1402](#1402)) ([d14f410](d14f410)) * Revert "chore(gRPC): Update a2a.proto to include metadata on GetTaskRequest" ([#1000](#1000)) ([e6b8c65](e6b8c65)) * Simplify Part message structure by flattening FilePart and DataPart ([#1411](#1411)) ([bfae8f7](bfae8f7)) * **spec:** Add LF prefix to the package. ([#1474](#1474)) ([a54e809](a54e809)) * **spec:** add metadata to `CancelTaskRequest` ([#1485](#1485)) ([c441b91](c441b91)), closes [#1484](#1484) * **spec:** Added clarification on timestamps in HTTP query params ([#1425](#1425)) ([6292104](6292104)) * **spec:** Added clarifying text around messages and artifacts ([#1424](#1424)) ([b03d141](b03d141)) * **spec:** Adjust field number for `ListTasksRequest.tenant` to prevent missing number ([#1470](#1470)) ([cd16c52](cd16c52)) * **spec:** Clarify contextId behavior when message is sent with taskId but without contextId ([#1309](#1309)) ([a336a5a](a336a5a)) * **spec:** Clarify versioning strategy and client responsibilities in protocol specification ([#1259](#1259)) ([a4afeea](a4afeea)) * **spec:** Fix/1251 clarify authentication scheme ([#1256](#1256)) ([3e6c7db](3e6c7db)) * **spec:** Fixes for the last_updated_after field ([#1358](#1358)) ([0e204bf](0e204bf)) * **spec:** Make "message" field name consistent between protocol bindings ([#1302](#1302)) ([1e5f462](1e5f462)), closes [#1230](#1230) * **spec:** make `history_length` optional ([#1071](#1071)) ([0572953](0572953)) * **spec:** pluralize configs in `ListTaskPushNotificationConfigs` ([#1486](#1486)) ([cf735cb](cf735cb)) * **spec:** Remove config from binding. ([#1587](#1587)) ([010b9cc](010b9cc)) * **spec:** Remove deprecated fields from a2a.proto for v1.0 release ([#1301](#1301)) ([60f83c3](60f83c3)), closes [#1227](#1227) * **spec:** remove duplicated ID from the create task push config request ([#1487](#1487)) ([393898d](393898d)) * **spec:** Remove metadata field from ListTasksRequest ([#1235](#1235)) ([b6ef9ee](b6ef9ee)) * **spec:** Remove reserved and fix tags ordering ([#1494](#1494)) ([1997c9d](1997c9d)) * **spec:** Rename `supportsAuthenticatedExtendedCard` to `supportsExtendedAgentCard` ([#1222](#1222)) ([c196824](c196824)), closes [#1215](#1215) * **spec:** Standardize spelling of "canceled" to use American Spelling throughout ([#1283](#1283)) ([4dd980f](4dd980f)) * **spec:** Suggest Unique Identifier fields to be UUID ([#966](#966)) ([00cf76e](00cf76e)) * **spec:** Switch to non-complex IDs in requests ([#1389](#1389)) ([2596c1c](2596c1c)), closes [#1390](#1390) * **spec:** Update security schemes example ([#1364](#1364)) ([f9a8f5b](f9a8f5b)) * Update the Java tutorials and descriptions ([#1181](#1181)) ([202aa06](202aa06)) ### Documentation * **spec:** Align enum format with ADR-001 ProtoJSON specification ([#1384](#1384)) ([810eaa1](810eaa1)), closes [#1344](#1344) ### Code Refactoring * **spec:** Combine `TaskPushNotificationConfig` and `PushNotificationConfig` ([#1500](#1500)) ([d1ed0da](d1ed0da)) * **spec:** Large refactor of specification to separate application protocol definition from mapping to transports ([b078419](b078419)) * **spec:** Move `extendedAgentCard` field to `AgentCapabilities` ([#1307](#1307)) ([40d6286](40d6286)) * **spec:** Remove redundant `final` field from `TaskStatusUpdateEvent` ([#1308](#1308)) ([5b101cc](5b101cc)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: Amye Scavarda Perrin <amye@amye.org> Co-authored-by: Holt Skinner <13262395+holtskinner@users.noreply.github.com>

madankumarpichamuthu requested review from a team as code owners December 11, 2025 19:22

gemini-code-assist bot reviewed Dec 11, 2025

View reviewed changes

docs/llms.txt Outdated Show resolved Hide resolved

madankumarpichamuthu added 3 commits December 11, 2025 12:13

docs: Add state transition history to AgentCapabilities feature list

30dd629

Complete the list of supported features in AgentCapabilities description to include all capability fields: streaming, push notifications, state transition history, extended agent card, and extensions.

docs: Fix markdown formatting in Appendix A.2.2

361113b

Add proper spacing around code blocks in numbered lists and consistent blank lines after section headers to satisfy markdown linter requirements.

docs: Add blank line before bulleted list in Rationale section

92bd391

Fix MD032 markdown linting error - lists must be surrounded by blank lines.

holtskinner changed the title ~~fix(spec): refactor: Move extended agent card field to AgentCapabilities~~ refactor(spec)!: Move extendedAgentCard field to AgentCapabilities Dec 12, 2025

holtskinner added the TSC Review To be reviewed by the Technical Steering Committee label Dec 12, 2025

github-project-automation bot added this to TSC Review Dec 12, 2025

github-project-automation bot moved this to Backlog in TSC Review Dec 12, 2025

madankumarpichamuthu mentioned this pull request Dec 15, 2025

[Question] Why is ExtendedAgentCard not a capability? #1229

Closed

git-vote bot added gitvote gitvote/open labels Dec 15, 2025

Tehsmash approved these changes Dec 15, 2025

View reviewed changes

Merge branch 'main' into fix/1229-move-extended-card-to-capabilities

ea3ba0c

darrelmiller approved these changes Dec 20, 2025

View reviewed changes

Merge branch 'main' into fix/1229-move-extended-card-to-capabilities

2ab87db

Merge branch 'main' into fix/1229-move-extended-card-to-capabilities

5c42d68

git-vote bot added gitvote/closed gitvote/passed and removed gitvote/open labels Jan 14, 2026

darrelmiller added 2 commits January 14, 2026 08:23

Merge branch 'main' into fix/1229-move-extended-card-to-capabilities

001fa24

Merge branch 'main' into fix/1229-move-extended-card-to-capabilities

235c04a

darrelmiller merged commit 40d6286 into a2aproject:main Jan 14, 2026
7 checks passed

github-project-automation bot moved this from Backlog to Done in TSC Review Jan 14, 2026

a2a-bot mentioned this pull request Jan 14, 2026

chore(main): release 1.0.0 #1221

Merged

jmesnil mentioned this pull request Jan 14, 2026

[Feat]: Move the support of extended agent card to the capabilities a2aproject/a2a-java#586

Closed

1 task

Conversation

madankumarpichamuthu commented Dec 11, 2025

Uh oh!

gemini-code-assist bot commented Dec 11, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

amye commented Dec 15, 2025

Uh oh!

git-vote bot commented Dec 15, 2025

Vote created

How to vote

Uh oh!

git-vote bot commented Dec 16, 2025

Vote status

Summary

Binding votes (0)

Uh oh!

git-vote bot commented Dec 17, 2025

Vote status

Summary

Binding votes (1)

Uh oh!

git-vote bot commented Dec 18, 2025

Vote status

Summary

Binding votes (1)

Non-binding votes (1)

Uh oh!

git-vote bot commented Dec 19, 2025

Vote status

Summary

Binding votes (1)

Non-binding votes (1)

Uh oh!

herczyn commented Dec 19, 2025

Uh oh!

Tehsmash commented Dec 19, 2025

Uh oh!

git-vote bot commented Dec 20, 2025

Vote status

Summary

Binding votes (3)

Non-binding votes (1)

Uh oh!

git-vote bot commented Dec 21, 2025

Vote status

Summary

Binding votes (3)

Non-binding votes (1)

Uh oh!

darrelmiller commented Dec 22, 2025

Uh oh!

git-vote bot commented Dec 22, 2025

Vote status

Summary

Binding votes (3)

Non-binding votes (1)

Uh oh!

git-vote bot commented Dec 30, 2025

Vote status

Summary

Binding votes (3)

Non-binding votes (1)

Uh oh!

git-vote bot commented Dec 31, 2025

Vote status

Summary

Binding votes (3)

Non-binding votes (1)

Uh oh!

git-vote bot commented Jan 1, 2026

Vote status

Summary