The dashboard got better the moment I stopped centering sessions

On May 5, the first version of my work-tracking dashboard gave sessions top billing. Live transcripts, streaming agent state, an endpoint that showed what every agent touched in the last hour. It was a faithful picture of how the machine works. It was a poor surface for a human trying to find what to do next.

The work-tracking layer I run for multi-agent operations is a custom tool I built for this. The premise is simple. If you are running five to fifteen Claude sessions a week across dozens of ongoing tickets, you need something that tells you what is blocked, what is in flight, and where your attention should go when you sit back down. A log viewer does not do that. A plain task list does not either, once the task count clears fifty and agents start producing partial state across sessions.

I had been telling myself that visibility was the problem. Instrument everything, surface it in real time, and clarity would follow. The dashboard I built from that instinct was accurate and hard to use.

what a sessions-first surface actually shows you

Sessions accumulate fast. A morning of parallel Claude runs produces a dozen session files, each with a transcript, a manifest, a set of labels, and a running status. Showing all of that at the top of a work-tracking surface means the screen is always changing, always offering something to read, and never answering the one question you sit down with. Where was I, and what is blocked.

The first version exposed three things. A sessions list with live status. An open-questions endpoint. A scope view that tried to summarize what was in flight. Each had real information in it. All three were arranged from the machine’s perspective.

The machine’s perspective is that sessions are the primary artifact. They are what the system produces when work happens. Showing them front and center felt obvious. It was the wrong frame. The re-entry question is not “what did agents do.” It is “what needs me right now.” Those do not decompose the same way. The answer lives at the work-hierarchy level, one abstraction up from any individual session.

rebuilding around Area, Epic, Task

I rebuilt the primary view around a three-level hierarchy. Area at the top, five of them. The production app, agent system, blog, business ops, personal. Epics under areas, one per coherent initiative. Tasks under epics, one per chunk of work that can be finished or cleanly handed off.

An area does not have a session, and neither does an epic. A task has sessions attached to it as evidence, not as the primary object. Once I committed to that inversion, the shape of the dashboard changed. Session state moved to a secondary slot on each task. A task might have five sessions showing five different agent runs, which is useful when debugging why something drifted. The session is a log. You navigate by the task.

The change that made the board actually actionable was WAIT_HUMAN detection layered on top. An agent stalled waiting for input marks its task WAIT_HUMAN. The dashboard surfaces those tasks at the top of every view, above everything else. When I open the board in the morning and four tasks carry that marker, I know exactly where to start. Without it, the hierarchy is a well-organized directory. With it, the board has a gradient. Here is what cannot move without me. Here is what is running. Here is everything else.

The difference in re-entry speed was significant enough to justify rebuilding the whole abstraction. A session-first surface requires reading. A task-first surface with WAIT_HUMAN markers requires one scan.

the migration tax, 19 directories and 3 collisions

Rebuilding the abstraction meant migrating the underlying ID format. The old IDs were date-embedded. MT-YYMMDD-NN for manual tasks, ME-YYMMDD-NN for manual epics. That format made sense when I created it. It started breaking when agents used IDs as foreign keys across files, when tasks needed to outlive their creation date in practice, and when the date prefix kept generating near-collisions that confused both me and the tooling reasoning about task state.

The fix was to strip the dates and use bare integer IDs. MT-NN becomes 47. ME-NN becomes 12. Clean, stable, portable across whatever references them. An agent can use a task ID without reconstructing the calendar to understand what it means.

Getting there required renaming 19 directories and resolving 3 ID collisions, each of which needed a manual call about which version of a duplicated key was canonical. The migration ran in a single afternoon but touched nearly every active file that referenced the old format. That is a large surface area for a naming change, and it was justified because the date-embedded format had been load-bearing only in my head, not in any actual system constraint. Nothing in the tooling required a date in the ID. I had added it for readability and built up a layer of brittle implicit dependencies on it without noticing.

After the migration, the IDs are just numbers. They sort predictably and reference cleanly, and agents no longer produce confused reasoning about which task came first.

where sessions belong

Session state is not useless. It is secondary, and that distinction matters in practice. A task with attached sessions shows you how the work evolved, which agents touched it, and what each left behind. For debugging a wrong turn or a missing context window, the session log is the right object to read. The task view does not replace that. It moves sessions from primary navigation to attached evidence.

The open question I am carrying forward is how far the task-first view holds before I need a proper session browser alongside it. Right now the secondary attachment slot on each task is enough. There is a future version of this where I am triaging five agents across three epics and need to cross-cut by session age or by model, and the task view stops being sufficient. That problem is not here yet, which is exactly the right time to notice it without building for it.

A multi-agent dashboard is not a realtime console. A console shows you what is happening. A dashboard tells you what to do. Sessions are the exhaust of work, not the surface for directing it.

dxdev LESSON · paste into your AI coding agent
LESSON: Session-first dashboards answer the wrong question
SOURCE: dxdev.com/blog/2026-05-05_dashboard-stopped-centering-sessions
WHAT HAPPENED: A multi-agent work-tracking dashboard was built with sessions as the primary navigation object. It was accurate but unusable for re-entry: it showed what the machine produced rather than what needed human attention. Rebuilding around a three-level work hierarchy (area, epic, task) with sessions demoted to attached evidence, plus a WAIT_HUMAN marker surfaced at the top of every view, reduced re-entry from reading to a single scan. A secondary cost was that the underlying IDs embedded dates, which had created brittle implicit dependencies across dozens of files; stripping dates to bare integers required renaming 19 directories and resolving 3 collisions in a single afternoon.
THE RULE: A dashboard tells you what to do; a console shows you what is happening. Design around the re-entry question, not the machine's natural output.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Does any primary navigation surface or default view list sessions, runs, or agent transcripts as the top-level object rather than tasks or work items?
  2. Do any IDs embed dates, timestamps, or other time-derived components that are used as foreign keys across files or referenced by automated tooling?
  3. Is there a mechanism to surface blocked or human-gated items (WAIT_HUMAN or equivalent) above all other items in the default view?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.