Running five AI coding agents at once without losing your mind

The first agent is a joy. You describe a change, it goes off, you watch the diff, you commit. The second one is still fine. Around the fourth, something quietly breaks — and it isn't the code. It's you.

The bottleneck moved, and nobody told you

For years the limit on how much you could ship was how fast you could type and think. Agents moved that limit. Now the agent does the typing, and a single developer can have five changes in flight at once. The new bottleneck is your attention: there's exactly one of you, and five things that periodically need a decision.

Here's the thing that makes it hard. Agents don't run on a clock. One finishes in forty seconds, another grinds for six minutes, a third stops dead after ninety seconds because it wants permission to run a command. You can't predict which needs you when. So you do the only thing a terminal lets you do and tab through, checking. Checking is the expensive part.

Context switching is the tax

Every time you tab into a session to see what's going on, you pay a context-switch cost. You have to remember what this agent was doing, read the last hundred lines of output, figure out whether it's blocked or just thinking, and decide whether to act. Do that across five sessions in a loop and most of your day is the loop, not the work.

It gets worse with the quiet failures of attention. An agent finishes and waits. Nothing tells you, so it sits there with the work done while you're three tabs over, babysitting the one that didn't need babysitting. The cost isn't dramatic. It's a steady leak: minutes of dead air on every session, all day.

Polling doesn't scale, interrupts do

The fix is to stop polling. You shouldn't be the one checking; the tool should be the one telling. That's the difference between "I'll tab through and see who needs me" and "something will pull me in the moment someone does."

For that to work, something has to actually know the state of every agent. That means hosting the session closely enough to see when it's working, when it's blocked, and why it's blocked. A permission prompt is not the same event as a question, a plan waiting for approval, or a finished task, and you want to be interrupted differently for each.

What a status grid actually buys you

Put all of that into one view and the day changes shape. Every session is a card with a status on it: working, waiting on you, idle, exited, or stopped at a usage limit. The cards sort themselves so the ones waiting on you sit at the top. You glance, you see two sessions working and one idle, and one that says it is waiting for a permission. You answer that one and leave the rest alone.

Where the agent CLI can report its own state through hooks, that status is what the agent said about itself rather than a guess. Where it can't, reading the screen is the fallback. The grid does three things a stack of tabs can't:

• It tells you status without a click. You see who's blocked before you decide where to look.

• It sorts by what needs you. Waiting-on-you first, so the queue is the screen.

• It interrupts instead of waiting to be polled. A notification at the moment something blocks, so idle time stops being invisible.

The honest part

A grid doesn't make the agents smarter or the code correct. You still have to read the diffs. You still have to make the calls, and five agents means five times the decisions. What the grid removes is the overhead around those decisions: the polling, and the finished sessions nobody told you about. The decisions are the job. Everything around them was just tax.

Running five agents well isn't about typing faster. It's about spending your attention only where it's actually needed, and never on figuring out where that is.