Multi-Agent Fleet Setup: Getting a Working Team of Agents Running Fast

Multi-Agent Fleet Setup: Getting a Working Team of Agents Running Without Reinventing the Wiring

Every team that moves from a single agent to a fleet hits the same wall. The agent logic is the easy part — you already have working prompts, tools, and skills. The hard part is everything around it: how do agents find each other, which ones are allowed to talk, and who routes a task to the right specialist. A multi-agent fleet setup is mostly plumbing, and plumbing is where projects stall.

This post walks through what a real multi-agent fleet setup requires, why most teams end up rebuilding the same scaffolding project after project, and one way to skip the wiring by starting from a pre-configured fleet instead of a blank slate.

What "fleet setup" actually means

Strip away the agent-specific logic and a working fleet needs three things solved, regardless of framework:

Addressing. Every agent needs a stable identity other agents can reach — not an ephemeral session ID that changes on every restart or every time the process moves to a different host or cloud. If agent identity is tied to an IP or a container's lifecycle, the fleet breaks the moment anything restarts.

Trust. Agents shouldn't automatically talk to everything on the network just because they can technically reach it. A fleet needs an explicit approval step between "these two agents are connected" and "these two agents trust each other" — otherwise you've built an open relay, not a team.

Task routing. Once agents can find each other and trust is established, something has to decide which agent handles which piece of work. This is usually the least standardized part — most projects hand-roll a router, a queue, or a set of if/else rules that only that team understands.

Get all three right and adding a fourth or fifth agent to the fleet is trivial. Get any one wrong and the fleet stays fragile no matter how good the individual agents are.

The manual path

Most teams start manually: pick a message bus or shared database, write a small registry service so agents can look each other up, and hardcode which agent calls which. It works for a demo. It gets harder to maintain as agents move across environments, as team members add agents with different trust requirements, and as the routing logic accumulates edge cases nobody remembers the reasoning for.

Frameworks like LangGraph and OpenClaw solve the orchestration logic — the graph of who calls whom and in what order — well. What they don't solve out of the box is the network layer underneath: stable addressing across restarts, NAT traversal so agents behind different firewalls can actually reach each other, and a trust model that's separate from "is on the network." Those are usually left to whatever infra the team already has, which is exactly where fleet setups tend to drift out of sync.

Starting from a pre-wired fleet instead

Pilot Protocol is an open-source overlay network built for exactly the addressing/trust/routing layer above: every agent gets a permanent virtual address that survives restarts and IP changes, connections run over encrypted UDP tunnels with NAT traversal built in, and trust is an explicit per-peer handshake rather than "joined the network, therefore trusted."

On top of that network, Pilot's app store maintains a library of pre-wired multi-agent "orgs" — fleets where the agent roles, their skills, and the trust links between them are already configured. Instead of starting from an empty network and wiring addressing, trust, and routing by hand, you install a fleet that already has that structure in place, then customize the parts specific to your use case.

The orgs span common fleet shapes — pipelines for code review, content and social workflows, customer support triage, CI/CD, and more — organized by complexity so you can start with a simple three-agent pipeline and work up to something with more moving parts once the basics are proven out.

Getting a fleet running

The loop is the same one used for any capability on Pilot's app store: discover, install, call.

# install pilotctl if you haven't already
curl -fsSL https://pilotprotocol.network/install.sh | sh

# see what's available
pilotctl appstore catalogue

# inspect a specific fleet before installing it
pilotctl appstore view <org-id>

# install it — the daemon spawns the agents and wires trust between them
pilotctl appstore install <org-id>

# check what's running
pilotctl appstore list

# call into the fleet
pilotctl appstore call <org-id> <agent>.<method> '{"...": "..."}'

Because each agent in the org is signature-verified and grant-scoped at install time, you're not handing the whole fleet ambient authority over your systems — each agent gets exactly the permissions it was configured with, and those permissions are re-checked every time the daemon spawns it.

From there, the customization work is the interesting part: swapping in your own prompts, connecting a specific data source, or adding an agent the base org doesn't include. The addressing, trust, and routing scaffolding is already handled, so that customization is additive instead of foundational.

When to build your own vs. start from a template

A pre-wired org is a starting point, not a constraint. If your fleet shape matches one of the existing orgs closely, starting there saves you the addressing/trust/routing work entirely. If your use case is genuinely novel, you can still build directly on Pilot's network layer — the same addressing and trust primitives the orgs use — without adopting a template that doesn't fit.

The honest tradeoff: templates are fastest when your fleet looks like a known pattern (support triage, content pipelines, code review). Custom builds make more sense when your task routing logic is the actual product, not incidental plumbing.

FAQ

Do I need to use a pre-wired org, or can I build a fleet from scratch on Pilot?
Both are supported. The orgs are a shortcut for common fleet shapes; the underlying addressing, trust, and discovery primitives are available directly if you want full control over routing logic.

What stops one agent in a fleet from talking to agents outside it?
Trust on Pilot is an explicit per-peer handshake, decoupled from network membership. Being reachable doesn't mean being trusted — an agent only talks to peers it (or its org configuration) has explicitly approved.

Does this replace my orchestration framework (LangGraph, etc.)?
No — those handle the logic of which agent calls which in what order. Pilot handles the network layer underneath: stable addressing, NAT traversal, and trust, which the orchestration layer can then build on.

What happens to agent identity if I move a fleet to a different cloud?
Each agent's virtual address is permanent and independent of IP or hosting environment, so moving hosts doesn't require re-wiring addressing or trust.

Get started

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl appstore catalogue

Pilot Protocol is open source (AGPL-3.0, Go, zero external dependencies) with SDKs for Go, Python, Node, and Swift, and a live network of 243k+ agents already using it. Full docs at pilotprotocol.network/docs.