What an A2A client reads before its first message
RolesAgent Systems EngineeringCustomer AI DeploymentDeveloper Experience and Education
The question
Your planner agent must delegate a test run to a remote agent that it knows only by host and port. Describe what it fetches first, how it decides which endpoint to call, and what it checks before it asks that agent for a stream.
Answer it first, aloud or on paper. Then open the answer.
The answer
Show short answer
It fetches the agent card with a plain GET on /.well-known/agent-card.json. From supportedInterfaces it takes the first entry whose binding and version it speaks, and it calls that entry's URL. Before SendStreamingMessage it reads capabilities.streaming, because a server must refuse the call with UnsupportedOperationError when the flag is absent or false.
Show full answer
One GET, one document
The specification names three routes to a card: the well-known URI, a registry or catalog, and direct configuration. It standardizes only the first. A planner with hosts in its configuration fetches each card from the well-known path.
The proto gives AgentCard 14 fields, and eight are REQUIRED: name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills. Four of them are lists, and a required list must hold at least one element. Reject a card that lacks one.
The endpoint comes from the interface list
Each supportedInterfaces entry has a REQUIRED url, protocolBinding and protocolVersion. The list is ordered, and the client selects the first entry it supports. Supported means a binding and a version that the client implements. The client also copies that entry's tenant into every request, and omits the field when the entry has none.
Flags decide which operations exist
Flag in capabilities | Operations it allows | Error when absent or false |
|---|---|---|
streaming | SendStreamingMessage, SubscribeToTask | UnsupportedOperationError, -32004 |
pushNotifications | the four push configuration operations | PushNotificationNotSupportedError, -32003 |
extendedAgentCard | GetExtendedAgentCard | UnsupportedOperationError, -32004 |
An absent flag counts as false. In the recorded error run, a push configuration sent to an agent without the flag got -32003 for a task id that did not even exist. The card had already answered.
Cache it like any document
A card changes rarely. The server should send Cache-Control with max-age and an ETag. The client honors them and revalidates with If-None-Match.
Follow-ups
L1ScreenWhich field tells you what work the agent can do?
Show expected answer
skills, each with anid, aname, adescriptionand at least one tag; pick the agent by skills and media modes.L2WorkingThe card lists a gRPC entry first and a JSON-RPC entry second, and your client speaks only JSON-RPC. Which URL do you call?
Show expected answer
the JSON-RPC one, because the rule is the first entry that you support.
L2WorkingHow do media types reach the agent?
Show expected answer
the card's
defaultInputModesanddefaultOutputModes, a skill's owninputModesandoutputModes, and amediaTypeon each part the client sends.L3SeniorYou hold a bearer token and the card sets
extendedAgentCard. What changes?Show expected answer
call
GetExtendedAgentCardwith the declared credential and use the fuller card in place of the cached public one for that session, or until the card'sversionchanges.
Wrong answers
Show the wrong answers that interviewers hear
“Read the top-level
urlfield of the card.”The current version moved the endpoint into
supportedInterfaces, and there is no top-levelurl.“Try the stream and fall back when it fails.”
The flag answers the question in advance. The failed call costs a round trip for nothing.
“Put the skill id in the message so the server runs that skill.”
No field of
SendMessageRequestorMessagenames a skill. The list describes the agent.
Taught in
The AgentCard fields section lists the fields, and the discovery section gives the interface rule and the flag table.