Running a fleet of agents

One agent on your phone is a novelty. Three or four working in parallel — one refactoring, one writing tests, one chasing a bug, one waiting on you — is a genuinely new way to work. The hard part isn't starting them; it's keeping them straight. This guide is about the organization layer: how to lay out many sessions, route their approvals, and switch between them without thrash.

What you'll learn

• Lay out parallel agents across tmux windows, Zellij tabs, or Herdr workspaces
• Use the session picker and shortcut panels to jump between them fast
• Keep approvals from different agents untangled in the inbox
• Decide between one-host-many-windows and many-hosts
• Choose the right multiplexer for fleet work

The two layouts

There are two sane ways to run several agents. Most people end up combining them.

For most people the answer is one host, one multiplexer, one window (or tab) per agent. Reach for multiple hosts only when isolation or raw capacity demands it.

Laying out agents in a multiplexer

Give each agent its own window or tab, named for the task. The discipline of one agent per window is what keeps a fleet legible on a small screen.

$moshi ~/projects/api
# inside tmux: one window per agent
$tmux new-window -n tests
$tmux new-window -n bugfix
$tmux new-window -n refactor

Then start an agent in each window — they can even be different agents:

$claude

$codex

Moshi detects the multiplexer on connect, lists every session in the picker, and gives you a per-multiplexer shortcut panel with a window/tab quick-access row — so jumping from tests to bugfix is one tap, not a typed prefix sequence.

Herdr: a workspace per agent

Herdr is a multiplexer built for exactly this. Instead of windows you think in workspaces, and Moshi forwards rich context — workspace and tab — into each agent event, so the inbox can tell you not just that an agent needs you but which workspace it's in.

If you're starting a fleet workflow from scratch, Herdr's workspace-per-agent model maps most cleanly onto "one agent, one job." If you already live in tmux, you don't need to switch — the window-per-agent pattern works well. The full support matrix is in Multiplexers.

Keeping approvals untangled

With several agents running, the inbox becomes mission control. A few habits keep it readable:

• Name sessions and windows after the task, not the project — payments-tests beats window 3. The name rides along in agent events, so the inbox card tells you who's calling.
• Triage from the inbox, act in the session. Allow/deny obvious requests inline; for anything needing context, tap into the exact session the event came from.
• Let notifications prioritize for you. When three agents are working and one finishes, the notification names it. You don't poll — you respond.

When to use multiple hosts

Stay on one host until one of these bites:

• Capacity. Several heavy builds or test suites contending for the same CPU.
• Isolation. You want an agent's blast radius contained to its own machine.
• Environment. One task needs Linux, another needs macOS-only tooling.

When you do go multi-host, save each as its own connection in Moshi. The session picker spans them, so the experience is still "pick the agent," just across machines. Put home machines on Tailscale so they're reachable without exposing ports.

A sane daily pattern

1. moshi <project> to land in a named session.
2. One window/workspace per task; start the right agent in each.
3. Kick them all off, then lock the phone.
4. Respond to inbox cards and notifications as they arrive — newest, most-blocking first.
5. Reattach anytime; tmux/Herdr kept everyone alive.

Where to go next

• Moshi with Claude Code — the single-agent loop this builds on
• Moshi with tmux — window strategy and durable sessions in depth
• Herdr and Multiplexers — the workspace models
• Agent events — how the inbox routes attention