A single AI coding agent used to be the whole story: one repo, one session, one thing being worked on. That constraint is gone. Agents are cheap to run and easy to start, so nothing stops you from having six of them going at once — an API, a frontend, two automations, a scraper, an infra repo. The moment you do, the scarce resource is no longer compute. It is you: one human deciding what runs, what gets your attention, and what waits.

That reframing is the whole job. Once you accept it, the workflow questions answer themselves — you stop asking “how do I make this agent faster” and start asking “how do I schedule a fleet of them without dropping any.”

You are the scheduler, not a worker

The useful mental model is an operating system. Each agent is a process doing real work in its own project. You are the scheduler: you decide which processes exist, which one is on the foreground, and which ones can run in the background until they need something. You do not do the work — you allocate the one thing the workers cannot allocate for themselves, which is human attention.

Held that way, a fleet stops feeling chaotic. The failure mode of many agents is not that the agents fail; it is that the human alt-tabs at random, checks on ones that are fine, misses ones that are blocked, and burns the afternoon context-switching. The fix is to run the fleet like a scheduler would — deliberately, by state, in named batches.

Launch named groups, not everything

Not every project belongs in every work block. Client automations, internal tooling, and lead-gen scrapers rarely need your attention in the same hour, so opening all of them at once just crowds your monitors with windows you will not touch. mAgent (installed as magent) lets you carve the fleet into named groups and launch one at a time:

$ magent
  1  Launch & tile new windows        (default)
  2  Re-tile all open windows
  3  Launch a group  ›  AUTOMATIONS | INTERNAL | LEAD-GEN
  e  Edit config
  q  Quit

$ magent -g INTERNAL
✓ launching 4 windows · resuming sessions…

Groups are just subsets of your config. magent -g INTERNAL opens only the repos tagged for internal work, each in its own terminal with its agent already running. A work block opens what belongs in it and nothing else — the deep-work session for internal tools does not have three lead-gen scrapers competing for a tile. If you want the whole fleet, option 1 launches and tiles everything; groups are the scalpel when you do not.

Mixed tools, one fleet

A real fleet is rarely one tool. Some repos are best on Claude Code, some you have moved to Codex CLI, a couple run on cursor-agent, and there may be a project you drive with something else entirely. That is fine — the launcher does not care which agent a project uses. Anything on your PATH can be the per-project command: claude, codex, cursor-agent, agy, or a plain editor like code for the repos you still touch by hand.

The payoff is that the fleet is defined by your projects, not by a single vendor. You pick the best agent per repo and still launch, tile, and monitor them as one set. If you are weighing tools, the tradeoffs are worth a longer look than this post gives them — see mAgent versus tmux for AI agents.

Rotate on state, not on curiosity

The habit that separates a manageable fleet from a stressful one is what triggers you to switch windows. Curiosity — “I wonder how the api one is doing” — is the enemy. It pulls you into sessions that are fine and away from the one that is quietly blocked. Replace it with a signal.

$ magent watch
#  project      tool          state
1  lead-scraper claude        needs-input
2  billing-api  codex         error
3  dashboard    claude        working
4  notifier     claude        done

magent watch is a live table sourced from the agents’ own lifecycle hooks (wired once with magent hooks install). You react to needs-input and error; you leave working alone; you review done when you have a gap. On Windows, pressing a row number jumps focus to that window. The scheduler runs by interrupt, not by polling — how those states are produced is covered in agent status from lifecycle hooks.

Keep the environment from drifting

A fleet has more ways to break than a single session. An agent falls off your PATH after a shell change, an env var goes missing, a monitor gets unplugged, a directory is not writable, Tailscale drops, or the upload port is taken. Any one of these turns “launch everything” into a confusing half-failure. Rather than debug it window by window, run the check:

$ magent doctor
✓ config valid            ✓ terminal detected
✓ env vars present        ✓ 2 monitors
✓ agents on PATH          ✓ writable work dirs
✓ Tailscale up            ✓ upload port free

magent doctor diagnoses config, env vars, agents on PATH, your terminal, monitors, writable directories, Tailscale, and the upload port in one pass. It exits 1 on any failure, so you can gate a launch script on it, and --json gives you a clean payload to paste into a bug report when something is off. Running it before a big work block is the cheapest way to keep drift from eating your first ten minutes.

Get set up

The fleet mindset is only as good as the two-minute setup behind it. The install guide covers requirements, pip and uv install, first-run config, groups, and the state-hook wizard — everything you need to go from a scattered set of repos to a scheduled fleet. If you are coming at this from the single-tool angle first, start with tiling terminal windows across monitors and build up from there. To bring the whole fleet back after a reboot, see how to resume a Claude Code session after a restart.