--- title: "Managing a fleet of AI coding agents across projects" description: "How to manage multiple AI coding agents in parallel across projects — named groups, mixed tools per repo, a state-driven rotation habit, and drift checks." date: 2026-07-22 reading_time: "6 min" keywords: ["manage multiple AI coding agents","parallel AI agents workflow","AI agent fleet","AI coding agent orchestration"] canonical: https://magent.now/blog/parallel-ai-coding-agents-workflow markdown: https://magent.now/blog/parallel-ai-coding-agents-workflow.md site: https://magent.now publisher: DevinoSolutions --- # Managing a fleet of AI coding agents across projects 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](https://magent.now/) (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](https://magent.now/blog/magent-vs-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](https://magent.now/blog/ai-agent-status-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](https://magent.now/install) 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](https://magent.now/blog/tile-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](https://magent.now/blog/resume-claude-code-session-after-restart).