Running several coding agents at once: what breaks at three

One coding agent fits in a terminal. Two fit in tabs. From the third one on, something breaks — and it isn't your machine, it's your attention. Here are the four problems, in the order they appear, and the known ways to deal with them.

Why three is the threshold

With one agent, you read its output live: you are its main loop. With two, you alternate and lose a little, but scrollback saves you. At the third, three counters run in your head at once: where is each one, which one is waiting for me, which one is burning time for nothing. That last one is the expensive one — an agent stuck for ten minutes on a permission prompt is ten minutes of subscription window wasted and a queue of work that didn't happen.

Problem 1 — Knowing who's stuck, without looking

The question you need answered at a glance has three states: working, needs you, done. Three approaches exist, most reliable first:

• CLI hooks — most modern agents can report their own state (status line, permission event, end of turn). It's the only source that asserts rather than guesses. Use it wherever it exists.
• The window title — many CLIs write their state into the terminal title (OSC sequence). Free, standard, often enough.
• Reading the buffer — checking whether the screen still changes. Good for telling "moving" from "not moving", useless for telling "thinking" from "waiting for an answer". Keep it as a fallback, never as the primary truth.

The classic trap is treating "nothing moves any more" as "finished". An agent showing a question and waiting doesn't move either. If your dashboard reports "done" for both, it lies to you half the time.

Problem 2 — Approving without blocking

You want your agents to ask before doing something irreversible. You don't want them idle while they wait for you. Those two requirements only conflict when approval is synchronous.

The way out is a request queue. The agent files its request, carries on with everything that doesn't depend on it, and you clear the queue when it suits you — in batches, rather than one modal at a time. Two rules make it liveable:

• Deny by default on the irreversible. Dropping data, pushing to the main branch, restarting a service: no answer means no.
• Exclusion beats blanket approval. "Approve everything except X" must exclude X, even if X joined the queue in the meantime.

Problem 3 — Chaining work without babysitting

"When that one finishes, the other picks it up" is the most common manoeuvre and the worst tooled. Most people do it on a stopwatch: come back in ten minutes, look, copy, paste. A proper chain fires on the agent's actual state (see problem 1), not on a timer, and it must be:

• visible — you should be able to read the list of pending chains;
• cancellable — you change your mind more often than you think;
• persistent — it survives a restart, or it will betray you on exactly the day it matters.

Problem 4 — Remembering from one day to the next

This is the hole an agent cannot plug for itself: every session starts from zero. You re-explain that the build goes through make, that this folder is generated, that this API lies about its error codes. Three layers are enough, and they're better as readable files than as an opaque store:

• session history, indexed and searchable;
• your corrections, turned into notes and re-injected on the next turn;
• repeated procedures, written as SKILL.md files — an open format several ecosystems already read.

One detail that matters: a procedure written by an agent should stay disabled until you've read it. Otherwise you end up with a tool that quietly learns habits you never approved.

What it looks like assembled

Put together, those four bricks describe a cockpit: one screen where every session is visible at once, an exact state per agent, an approval queue, event-driven chaining, and a memory you can read. The rest — committing, opening a pull request, creating a worktree — agents already do well on their own: building buttons for that adds work rather than removing it.