Autonomous agents don't need a dashboard. They need a way to reach you.

I run five Claude Code agents at once. Different terminals, different repos: one refactoring a payment service, one grinding through a video pipeline, one rewriting landing copy, one fixing a cron, one building the very tool this post is about. On a good afternoon that's five autonomous engineers working in parallel for the price of one subscription.

And for weeks the bottleneck in that setup was not the agents. It was me.

Not because I was slow at the work. Because I was slow at one specific thing: knowing which of the five needed me, right now, and getting to it before it either stalled or guessed wrong.

The problem nobody warns you about when you scale agents

Everyone sells the dream as fire-and-forget. Hand the agent a task, walk away, come back to a finished PR. That works right up until you run more than one of them, and then the whole thing quietly inverts.

Here is what actually happens with five agents running. At any given second, they're in three completely different states. One is deep in a turn, burning tokens, nothing for me to do. One finished ten minutes ago and has been sitting idle, its work done, waiting for the next instruction I didn't know it needed. And one hit a fork it can't resolve on its own, and it's now either blocked on a permission prompt or, worse, about to pick an approach I would have vetoed if it had asked.

I couldn't see any of this without alt-tabbing through five windows, one by one, reading scrollback to reconstruct where each one was. By the time I made the full loop, the states had changed.

Fire-and-forget is a great demo and a terrible operating model. The second you run a fleet, the scarce resource stops being agent time and becomes your attention.

Why a dashboard doesn't fix it

The obvious answer is a monitor. A few exist for Claude Code already. I tried them. They're read-only dashboards, and they all stop at the same place.

They answer "what is each agent doing?" That's the easy half. It shaves the polling cost, which is real and worth having. But it does nothing about the expensive half: the agent that needs a decision only I can make. A dashboard shows you a session is blocked. It can't carry your answer back. You still have to find the window and type into it.

That return trip is the whole game. An agent that can reach a human at the exact moment it's uncertain is worth far more than an agent that runs longer before it guesses. Autonomy without a way back to the operator isn't autonomy. It's a machine that fails silently at a higher altitude.

What I actually built

So I built the return trip. It's called Quarterdeck, after the raised deck a captain commands the ship from, and it does two things.

First, the boring half: it watches every Claude Code session and gives each a live status. Red needs you, yellow working, green idle. The tray icon shows the worst status across the fleet, so one glance tells me if anyone is blocked. Status comes from Claude Code's own hook events, not from polling or scraping transcripts.

Second, the half that mattered: the agent can reach back. Any session can call a tool that asks me a question, with quick-pick options, and Quarterdeck pops it over whatever I'm doing without stealing my keyboard. I tap a button, the answer routes straight back into that session, and the agent keeps going. A twenty-minute run stops and asks "which of these two migrations?" instead of stalling or guessing. And it fails open: if I don't answer, Claude Code just falls through to its normal terminal prompt. It can never leave an agent more stuck than it would have been.

The lesson, which is not about a tray app

I've been writing for a year about governed autonomy: the leverage in AI isn't setting agents loose, it's building the frame that goes in and owning the judgment that comes out. Quarterdeck is that thesis compressed into software I use every day.

The frame and the judgment are the parts that don't hand off. You can delegate the code. You cannot delegate the decision about whether the migration is reversible, whether that refactor is worth the blast radius, whether the copy sounds like you. The agent should run at full speed up to that line, and then it should have a fast, reliable way to put the decision in front of the one entity that can make it.

Delegating the work was never the hard part. Building the channel the work comes back through is the hard part.

Every real move toward autonomy I've made this year has been less about making the agent more independent and more about making the handoff sharper. Scale the agents all you want. Just don't forget to build the door they knock on.