The agent that needs you most may be the one producing no output.
Imagine returning to several coding sessions. One is running tests. Another has finished its patch. A third is waiting for permission to continue. A wall of terminals leaves you to work out which needs a decision.
I want an agent console to bring that decision to me. Otherwise, I spend the time saved by delegation searching for the next decision.
Ed Engelking II’s write-up of Podium made this problem concrete. His console brings Claude Code sessions and their child agents into one view, with optional browser responses. It prompted a design question for my own workflow: what should the first screen ask me to notice?
Put blocked decisions first
A grid of session cards gives a useful overview. I would put a decision inbox above it.
Consider a hypothetical supplier import. One worker needs to know whether to preserve an old field. Another has finished a copy update. A third has stopped reporting, so the console no longer knows its state.
Those items need different treatment: a choice to unblock the import, a patch to review, and a warning that a status is stale. Giving them the same amber badge makes me do the sorting.
The field question should tell me which import revision it concerns, who owns the decision, and what proceeds after I answer. It should take me back to the original session without making me reconstruct the task from its title.
Age alone should not determine priority. A decision blocking the import and its dependent tasks may matter more than an older optional experiment. The console should show why it put an item first and let me change the order.
Keep unknown states visible
A reporter disappearing does not mean the agent finished. A quiet session may be waiting, working without new events, or disconnected.
Every status needs a last-observed time and a point at which it becomes stale. If the reporter disappears during a test run, the screen should say that the current result is unknown. Keeping a green “running” badge would hide the gap.
Apply the same honesty to context and cost. If an adapter cannot report context usage, show “unavailable.” If cost comes from token counts and a pricing table, label it an estimate. Combining unlike measurements into a precise-looking total makes the screen harder to trust.
Attach success to the revision checked
A session tree shows who is working. It cannot establish that their patches fit together.
Suppose the import worker changes the shared field while another worker still uses the old version. A successful test run from before that change cannot validate the combined patch. Attach checks to the revision they tested and show which dependent tasks the change affects.
This is the problem in Parallel agents need an integration plan. The console can expose a dependency; someone still has to resolve it and check the result.
That is also why I would avoid ranking work by token usage or number of spawned agents. Both can rise during rework. I would measure time spent waiting for decisions, repeated interruptions, integration failures, and time to an accepted result.
Test whether a small console saves attention
Anthropic’s mods documentation describes handlers that run inside Claude Code and can observe or change session events. I would check the capabilities against the runtime version in use before choosing what to collect.
My first version would cover a few sessions on one machine, with no remote approval button. Its job would be to show the next decision and enough context to return to the right session.
Before building it, I would compare those requirements with Podium’s existing implementation. Extending it may solve the problem without another dashboard.
The test is simple: when I return to the desk, do I find the right decision sooner? If I still have to open every terminal to work out who needs me, the console has not done its job.