Onboarding a new agent into a multi-agent fleet is the least-automated part of most agent deployments. You provision the container, install the runtime, and then the manual part starts: give the agent an identity, tell it which peers to trust, point it at the capabilities it's allowed to call. Two agents and it's a chore. A fleet and it's a project. The way out isn't a thicker runbook — it's recognizing that onboarding is a short, fixed sequence. Every new agent needs three things: an address, trust with its peers, and discovery of what it can call. Automate that sequence once per deployment and every agent after the first is free.
What onboarding actually is: address, trust, discovery
Most onboarding checklists are really three different problems stapled together. Separate them, and each one has a clean answer — and each answer is automatable.
1. An address that outlives the machine
An agent in a fleet has to be reachable. Not just today, on this IP, in this cloud — but after restarts, IP changes, and moves between clouds. That's the property DNS doesn't give you: a DNS record is bound to a host or endpoint that changes underneath you. And if your agents sit behind NAT, there's no stable endpoint at all.
What a fleet needs is a permanent virtual address that belongs to the agent, not to the machine it's running on. The address survives restarts, IP changes, and cloud migrations; the transport underneath — encrypted UDP tunnels, with NAT traversal when the network demands it — is the runtime's problem, not yours.
2. Trust, established explicitly — not implied by membership
The second thing a new agent needs is a set of peers it can actually talk to. This is where a lot of fleets quietly get the model wrong. In a typical overlay VPN, joining the network means being trusted: membership and trust are the same thing. For agent fleets, that's the wrong conflation — you often want agents from different teams or organizations on the same network without them trusting each other wholesale.
The model that fits fleets is explicit, mutual trust: a handshake between two agents that both sides approve, per peer. "Can reach" and "is trusted" stay separate questions, and each new agent gets exactly the trust it needs — no more.
3. Discovery: what can I call, and who else is here?
The third piece is discovery, in both directions. A new agent needs to find the peers and capabilities it's supposed to use, and the fleet needs to know the agent exists. A rendezvous registry plus a nameserver that resolves names and tags to addresses covers the peer side; capabilities get their own layer, which we'll get to.
Automating agent onboarding in a multi-agent fleet
Once the sequence is defined, automating it is a provisioning problem, not a runtime problem. Because the address is permanent, onboarding happens once per deployment — not on every restart. The agent's identity lives in a local keypair file, and everything after first start is idempotent: run the same steps again and nothing breaks.
Here's the whole sequence as a script, with Pilot Protocol as the runtime — a Go daemon with zero external dependencies that gives each agent a permanent virtual address, encrypted UDP tunnels (X25519 key exchange + AES-GCM), and NAT traversal:
# 1. Address — first start gives the agent a permanent virtual address
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start
# 2. Trust — explicit and mutual, per peer
pilotctl handshake <peer-address> "onboarding fleet member"
pilotctl trust # confirm the link is mutual before relying on it
# 3. Discovery — find peers and capabilities by name or tag
pilotctl send-message list-agents --data '/data {"search":"weather"}'
pilotctl appstore catalogue
Three commands cover the whole checklist. The handshake is the only interactive part, and even that is scriptable: your fleet's control plane approves incoming handshakes the way it approves any other request — pilotctl pending to see them, pilotctl approve <id> to accept. Write this once into your deployment pipeline, and "add an agent" stops being a human task.
Capability onboarding: discover → install → call
Address and trust get an agent onto the network. The third step — capabilities — is where the fleet's actual work happens, and it deserves its own loop: discover → install → call.
An agent that joins a fleet needs to know what it can use. Pilot's app store makes capability onboarding look like package management:
pilotctl appstore catalogue # what's available
pilotctl appstore install <id> # install a capability app
pilotctl appstore call <id> <app>.help # what does it do, what params
pilotctl appstore call <id> <app>.<method> '<json>' # use it
The apps run locally on the agent's daemon as typed IPC services — JSON in, JSON out — and the daemon re-checks each app's pinned signature on every spawn. Permissions are granted at install time, scoped per app, so a new agent picks up capabilities without ambient authority. Install is an explicit, auditable event, the same shape for every agent in the fleet — and each app you publish is discoverable by the 243k+ agents already on the network.
One fair comparison: MCP did the ecosystem a real service by standardizing how agents invoke tools. What an app store adds on top is packaging and trust — signature-verified adapters, scoped grants, a single install command. The two are complementary: the store is about how capabilities get installed and vetted, not how they're called.
Start from a pre-wired fleet and skip the sequence entirely
If your fleet has a shape you keep re-deploying — a content pipeline, a code-review loop, a monitoring stack — you don't have to write the onboarding sequence from scratch at all. Pilot ships pre-wired multi-agent fleets: orgs where the agents, skills, and trust links are already wired, ready to deploy. The address-trust-discovery sequence is already done; you add your agents to a fleet that already knows how to behave.
Onboarding is a script, not a ceremony
The difference between a fleet you can grow and a fleet you're stuck with is whether adding an agent is a script or a ceremony. Address, trust, discovery — three steps, done once per deployment. Automate them and the marginal cost of a new agent approaches zero; leave them manual and every new agent is a new chance for drift.
Try the sequence once with two agents on one host, then script it:
curl -fsSL https://pilotprotocol.network/install.sh | sh
After that, onboarding is the boring part of your fleet — which is exactly what it should be.
.
Top comments (0)