Mission Control: Never Lose Track of Which Agent Needs You
Running six agents means the canvas stops answering the one question that matters — who needs you right now. Here's how Fleet's state grouping and the pending-question tail fix that.
Two agents on a canvas is easy to watch. Six is a different problem. The canvas is a spatial layout — tiles scattered wherever you dropped them — but the question you actually need answered isn't "where is everything," it's "who is blocked on me right now." Spatial layout doesn't answer a state question. You end up scanning tile by tile, and scanning doesn't scale.
That's the attention-management problem that shows up the moment you go from running one agent to orchestrating a fleet of them. A permission prompt sitting unanswered three screens to the left costs you nothing while you're heads-down on tile four — until you notice, ten minutes later, that an agent has been idle the whole time waiting for a yes/no you never saw.
MadoHub's answer is Mission Control, the Fleet panel. It's worth walking through how it actually works, because the design choices map directly onto the problem.
How MadoHub handles it
Group by state, not by position
Mission Control's core move is to stop organizing agents spatially and start organizing them by state. Every agent tile lands in exactly one of six groups, always rendered in the same fixed order:
| Group | What it means | Dot color |
|---|---|---|
| Needs input | Waiting on a yes/no, permission, or other prompt | Amber |
| Working | Mid-turn | Accent |
| Done | Finished its turn, ready for review | Green |
| Failed | Hit an error | Red |
| Idle | Nothing doing | Faint |
| Exited | Process gone | Faint, dimmer |
Empty groups don't render a header at all — you never see "Failed (0)" taking up space for nothing. The ordering itself encodes triage priority: the agent that's been sitting on a permission prompt for ten minutes appears above the agent that's happily working, which appears above the agent that's already finished and is just waiting for you to look at it. You read down the list in the order you should actually act.
The collapsed badge is deliberately not "total agent count." If any tile is waiting on input, it shows that count on an amber badge — the number worth interrupting for. Otherwise it shows the count of all running tiles, in muted text. Not everything you're running deserves equal attention: a tile quietly working needs none of it, a tile blocked on a prompt needs all of it, immediately.
Show the actual question, not just that there is one
Grouping by state tells you that an agent needs input. It doesn't tell you what it's asking — and that gap is where people end up switching to the tile anyway, just to read the question, defeating the point of a triage panel.
Mission Control closes that gap. For every row in the Needs Input group, it shows the last couple of lines of that tile's terminal output. In practice that's almost always the actual pending question — a (y/n), an "Allow once / Allow always / Deny" choice, or similar — rendered in a small amber-bordered block right under the row. That's the difference between "Agent 3 needs input" and "Agent 3 is asking whether it can rm -rf node_modules — yes, obviously, go ahead." One of those you can decide on without leaving the panel; the other forces a context switch you didn't need.
Jump to the tile in one click
Once a row is worth acting on, clicking it pans and zooms the canvas viewport directly to that tile — from "agent X needs me" in the panel to looking at agent X's terminal in one click, no hunting across a canvas with a dozen tiles on it. State grouping tells you what needs attention and in what order, the pending-question tail tells you the actual question, and the fly-to-tile click gets you there.
Live Dynamic Workflows progress, without badge-flooding
Claude Code's own Dynamic Workflows feature can fan a single Claude session out into many concurrent subagents. MadoHub doesn't create or run these — it's Claude Code's feature, not MadoHub's — but it detects the subagent activity and rolls it into one progress line per tile instead of firing a normal notification per subagent, so a run with a dozen subagents doesn't flood the canvas with badges.
Mission Control surfaces that progress per row, underneath the activity line, whenever a tile has an active run:
workflow · 3/5 agentsThe two numbers are subagents that reached a terminal state over the distinct subagent threads seen so far on that tile. The line only appears while the run is active and disappears on its own once it lapses. Starting a new workflow on the same tile resets both counters to zero rather than accumulating.
Practical guidance
- Read down the list in order. The group ordering is the triage order — needs input first, then working, then done. Don't jump to "done" rows until the "needs input" ones are clear.
- Decide from the tail when you can. If the pending question is a routine permission you'd grant anyway, you can often answer it mentally and fly to the tile just to confirm — or skip the panel trip entirely for tiles you're going to visit anyway.
- Use the collapsed badge as an interrupt signal. Treat the amber number as "stop what I'm doing and check." A zero means you can stay heads-down.
- Don't expect plain shells. A plain terminal tile never appears in Mission Control — only tiles recognized as agent CLIs do, so the panel isn't cluttered with your scratch terminals.
None of this is complicated individually — group by state, show the last couple lines of output, jump to the tile on click. The value is in what it removes: holding six tiles' worth of state in your own head, scanning a canvas to find the one that's stuck, opening a tile just to read a question you could've read in a sidebar.
Mission Control's expand/collapse state is intentionally not persisted — every fresh launch starts collapsed, showing just the badge. That's the right default for a panel whose whole job is to answer one question fast and then get out of the way.