Guide

How to run several AI coding agents in parallel without losing track

One agent is a copilot. Three agents is a team — if you can keep up with them. The pitch is obvious once you've felt it: while one agent refactors the auth module, a second writes tests for the billing service and a third chases a flaky CI job in a different repo. You're no longer the bottleneck on any single task. You parallelize the boring 80% and spend your attention on the 20% that's actually a decision.

The trouble shows up about ten minutes in. Three agents means three terminals, and a coding agent isn't a batch job — it pauses. It stops for a permission prompt, asks what you meant, or just finishes and waits. Now you're rotating through windows trying to spot which one is blocked, and the answer is usually "the one you weren't looking at." The parallelism is real; the way most people run it is what falls apart.

Why one agent per repo or feature is the right grain

The natural unit of parallelism is a working context the agent shouldn't have to share. That usually means one repo, or one feature branch within a repo, per agent. Keep the boundaries clean and the agents don't step on each other.

• One repo per agent is the simplest split. Each agent has its own directory, its own dependencies, its own test command. There's zero risk of two agents editing the same file or fighting over a dev server port.
• One feature per agent works inside a single repo if you give each its own git worktree — separate checkouts of the same repo on different branches. Two agents on the same branch in the same folder will clobber each other; two worktrees won't.
• Match the model to the job. Nothing says all three agents have to be the same tool. Run your own Claude Code on the gnarly refactor, a second on a different repo, and Grindy — Backgrind's own hosted agent — on a low-stakes cleanup so you're not burning your main quota on busywork.

The thing that makes parallel agents pay off is picking tasks that need few decisions. The more an agent can run unattended, the more leverage you get from running several. That's the same instinct behind vibe coding — describe the outcome, let it run, judge the diff — applied three times over.

The pattern most people start with: many terminals or tmux

The first move is always "open more terminals." It works, technically, and it's worth knowing where it leaks before you outgrow it.

• Separate terminal windows or tabs. Fine for two agents you're actively watching. Past that, windows get buried behind your editor and browser, and you stop glancing at the ones you can't see. The blocked agent is always the one off-screen.
• tmux with a pane per agent. A real step up — one window, a grid of panes, and the sessions survive a closed terminal. tmux is genuinely good at keeping the processes alive. What it can't do is tap you on the shoulder. A pane waiting on a permission prompt looks exactly like a pane that's busy working. You have to scan all of them, constantly, to notice the one that stalled. We dig into that gap in running Claude Code in the background.
• nohup or & to detach. Wrong tool for an interactive agent. Detaching from the shell means the agent has nowhere to send a question and nowhere to read your answer — any prompt becomes a silent hang. Multiply that by three and you've built a quiet pileup.

The failure is the same in every case and it gets worse linearly with agent count: the processes keep running, but the signal — this one needs a decision, that one finished — never finds you. One unwatched agent is an annoyance. Three is a guessing game.

What actually scales: tabs plus per-tab attention

The fix isn't more screen real estate, it's routing attention. When you run several agents, three things have to be true at once for it to stay sane:

• One surface, many agents. All your agents live in a single window as tabs, not scattered across the desktop. You see the whole fleet at a glance and switch with a keystroke instead of hunting for a window.
• Each agent owns its own context. A tab is pinned to a repo or worktree and keeps its own scrollback. Switching tabs is switching projects, cleanly — no mental reload of "wait, which agent was this."
• Attention is per-tab, not global. This is the piece that makes parallelism work. When agent C hits a prompt, its tab should light up — an accent ring, a chime — while A and B keep running silently. You don't scan; the agent that needs you raises its hand. With Claude Code that's driven by its lifecycle hooks — roughly Notification (wants attention), Stop (finished), and PreToolUse (about to run a tool, can pause for allow/deny).

Get all three and the math flips. Instead of your attention being divided across N agents, it's pulled to exactly the one that needs it, exactly when. The rest stay quiet. That's the difference between babysitting three terminals and supervising a team — a distinction we make in stop babysitting your AI coding agent.

Where Backgrind fits

Backgrind is built for exactly this: an always-on-top overlay with a tab per agent, each running your real CLI — Claude Code, Cursor, or Grindy — in its own repo or worktree, kept alive by a background daemon so closing the window never kills the work. When one agent needs a decision or finishes, only that tab pings with a ring and a chime; the others run on. You run three agents and answer the one that's actually waiting. Watch the loop in the live demo.