A2A Agent Card Proto Field Numbers: v0.3.0 vs v1.0.1

In protobuf the field number, not the name, identifies a field on the wire. That matters for the gRPC binding and for any code generated from a2a.proto. The JSON-RPC and HTTP+JSON bindings use camelCase names instead, so for them the renames below matter and the numbers do not.

The official migration guide lists the field changes by name. This page adds the numbers, taken from the two a2a.proto files themselves (the v0.3.0 tag and the v1.0.1 tag). The v1.0.0 tag defines the same messages as v1.0.1 for everything on this page.

Where did the extended Agent Card flag go?

v0.3.0: AgentCard.supports_authenticated_extended_card, a bool, field 13.
v1.0.0 and v1.0.1: AgentCapabilities.extended_agent_card, an optional bool, field 4.

The specification’s migration appendix (A.2.2) describes the same move, but not with the same details as the proto files:

	Removed	Added
Appendix A.2.2 of the v1.0.1 specification	`AgentCard.supports_extended_agent_card` (field 13)	`AgentCapabilities.extended_agent_card` (field 5)
`a2a.proto` at v0.3.0 and v1.0.1	`AgentCard.supports_authenticated_extended_card` (field 13)	`AgentCapabilities.extended_agent_card` (field 4)

The appendix has the old field number right, gives the old field a different name than v0.3.0 used, and gives the new field number as 5 where the proto says 4. AgentCapabilities has fields 1 to 4 and nothing numbered 5. The specification names a2a.proto as “the single authoritative normative definition” (section 1.4), so use the proto: 4.

AgentCard

#	v0.3.0	v1.0.1	What changed
1	`name`	`name`
2	`description`	`description`
3	`url` (string)	`supported_interfaces` (repeated `AgentInterface`)	Number reused for a different field and type
4	`provider`	`provider`
5	`version`	`version`
6	`documentation_url`	`documentation_url`	Now `optional`
7	`capabilities`	`capabilities`
8	`security_schemes`	`security_schemes`
9	`security` (repeated `Security`)	`security_requirements` (repeated `SecurityRequirement`)	Renamed; same structure
10	`default_input_modes`	`default_input_modes`
11	`default_output_modes`	`default_output_modes`
12	`skills`	`skills`
13	`supports_authenticated_extended_card` (bool)	`signatures` (repeated `AgentCardSignature`)	Number reused for a different field and type
14	`preferred_transport` (string)	`icon_url` (optional string)	Number reused; both are strings
15	`additional_interfaces`	unused	Folded into `supported_interfaces`
16	`protocol_version`	unused	Moved to `AgentInterface.protocol_version`
17	`signatures`	unused	Moved to field 13

AgentCapabilities

#	v0.3.0	v1.0.1	What changed
1	`streaming` (bool)	`streaming` (optional bool)	Now `optional`
2	`push_notifications` (bool)	`push_notifications` (optional bool)	Now `optional`
3	`extensions`	`extensions`
4	none	`extended_agent_card` (optional bool)	New; see above

AgentInterface

#	v0.3.0	v1.0.1	What changed
1	`url`	`url`
2	`transport`	`protocol_binding`	Renamed
3	none	`tenant`	New
4	none	`protocol_version`	New; replaces `AgentCard.protocol_version` (field 16)

AgentSkill

Fields 1 to 7 are identical. Field 8 changed from security (repeated Security) to security_requirements (repeated SecurityRequirement); see AgentSkill .

Unchanged

These messages have identical field names, numbers, and types in v0.3.0 and v1.0.1: AgentProvider, AgentExtension, and AgentCardSignature.

What to take from it

Three numbers changed meaning. Field 3 went from a string to a list of messages, field 13 from a bool to a list of messages, and field 14 from one string to another. Reading bytes written under one definition with code generated from the other can misread values or fail to parse. Interfaces declare protocol_version, and requests carry the A2A-Version service parameter, so a server can tell which definition a client is using.
No numbers were reserved. The v1.0.1 proto contains no reserved statements. Numbers 15, 16, and 17 on AgentCard are simply unused, and the message carries the comment Next ID: 20; nothing in the file stops a later change from reusing them.
optional has a job beyond style. Section 5.7 of the specification gives two reasons for the keyword: fields whose default differs from protobuf’s implicit default, and Agent Card signing, where optional separates an explicitly set field, which belongs in the canonical form, from an omitted one. In v1.0.1 streaming, push_notifications, extended_agent_card, documentation_url, and icon_url are optional. See Agent Card signing .

Check it yourself

git clone https://github.com/a2aproject/A2A && cd A2A
git show v0.3.0:specification/grpc/a2a.proto | sed -n '/^message AgentCard {/,/^}/p'
git show v1.0.1:specification/a2a.proto      | sed -n '/^message AgentCard {/,/^}/p'
git show v1.0.1:specification/a2a.proto      | sed -n '/^message AgentCapabilities {/,/^}/p'

The v0.3.0 proto lives under specification/grpc/; from v1.0 on it is specification/a2a.proto.

Agent Card : the card itself, with the JSON-level migration table.
What’s New in A2A Protocol v1.0 : the complete migration guide, by field name.
A2A SecurityScheme : the security to securityRequirements rename in detail.

Source: a2a.proto at v0.3.0 , v1.0.0 , and v1.0.1 ; A2A official specification: Normative Content, Field Presence and Optionality, Appendix A.2

A2A Error Codes: JSON-RPC, gRPC, and HTTP Mapping