a team of agents doesn’t stay on one box for long. one machine fills up, or you split work across regions, or you just want the noisy agents off on their own. so now your org is spread across machines, and the question becomes: how do you actually run it?

the compose post was about declaring a team and bringing it up. this one’s about the day after. when the team is live, across boxes, and you need to see and steer it.

the problem: ssh roulette

without a control plane, a multi-box org means ssh-hopping. which box is that research agent on again? log in, check, log out, try the next one. restarting one stuck agent means remembering its host first. there’s no single answer to “what’s running right now,” so you keep one in your head, and it’s usually wrong.

see everything

v0.3 gives the whole fleet one view. register your boxes once, then:

• 5dive fleet status — every box, reachability plus how many agents each is running. fans out over ssh in parallel, so it’s one round-trip, not one-per-box. an unreachable box shows as down instead of hanging the whole view.
• 5dive fleet agents — every agent on every box, in one list. the actual “what’s running right now,” answered.

read-only, both of them. no root, no writes. just look.

steer anything

seeing isn’t enough. you need to act without picking the right machine first:

• 5dive fleet send agent@box ”…” — drop a message to one agent on one box. message text is base64-transported on the wire, so it’s never re-evaluated as a shell command on the far end.
• 5dive fleet restart agent@box — restart any agent on any machine, from where you’re standing.

the agent@box address is the whole trick. you name who you want and where it lives, and the cli does the hop for you.

security: more reach, not more blast radius

a control plane that can touch every box is exactly the thing you want locked down. so the fleet layer is built to add reach without adding standing privilege.

• it rides your own ssh trust. fleet commands fan out over the same keyed ssh you already use. there’s no new daemon listening and no shared admin credential pooled on the control box. each command hops, runs, and leaves.
• least privilege by default. everything that reads the fleet (status, agents, ls, show) runs unprivileged. only fleet add, which writes the local registry, needs root. looking never does.
• messages are data, not commands. fleet send base64-transports the body, so the far end hands it to the agent as text and never re-evaluates it as a shell command. one box can’t be used to inject into another.
• boxes stay isolated. every box is its own machine with its own agents and its own secrets. the control plane coordinates them, it doesn’t merge them, so a problem on one box doesn’t hand over the rest.

on managed 5dive boxes it goes further: there’s no standing admin key, and operator access is consent-gated and auto-expiring, so even support can only reach a box inside a window you open.

register a box

one-time setup per machine:

5dive fleet add research --host=10.0.0.4
5dive fleet ls
5dive fleet status

add takes root (it writes the fleet registry). everything that reads the fleet, ls, show, status, agents, doesn’t.

why one pane matters

a single agent is a process you babysit. a fleet you can see and steer from one terminal is closer to operating a team. you stop tracking where things live and start tracking what they’re doing.

and the fleet view sits over the same substrate as the rest of v0.3: the org chart, the shared task queue every agent and human reads and writes, the human-gates an agent trips to hand a decision up to you. the control plane is just the operator’s window onto all of it.

try it

5dive is open source. the cli, the compose layer, the fleet control plane, all of it: github.com/5dive-ai/5dive

want it managed? get a box at 5dive, point the same cli at it, and add it to the fleet.