[FEATURE] Agent Hierarchy Dashboard — unified real-time visualization for multi-agent workflows (TUI + Desktop)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/19555
2. https://github.com/anthropics/claude-code/issues/17425
3. https://github.com/anthropics/claude-code/issues/10052

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This already exists as a standalone tool. Beadbox watches your .beads/ directory over WebSocket and gives you real-time visibility into agent work: epic trees with progress bars, dependency badges, inline status editing, multi-workspace switching. Sub-second updates when an agent claims a task, closes a subtask, or hits a blocker.

It reads the beads database directly, so it works with any agent framework (Claude Code, Codex, Gemini CLI, manual). No account, no cloud, your data stays local. Native desktop app built with Tauri.

Not a replacement for a built-in dashboard (that would obviously be better since it could show token usage, cost, and agent tree natively), but it solves the monitoring and triage problems described here today: which agents have claimed what, what's blocked, what's done, how far along each epic is.

brew tap beadbox/cask && brew install --cask beadbox or grab a binary from beadbox.app. macOS, Linux, Windows. Free during beta.

This is exactly what I built — a real-time dashboard for coordinating multiple Claude Code agents.

Mycelium has a web dashboard that shows:

• All agents with live status (online/offline, last heartbeat, what they're currently working on)
• Task board with assignments, priorities, and status tracking
• Plan hierarchies — multi-step plans with ordered steps that auto-advance as agents complete work
• Message feed — inter-agent messages, blocking requests, directives
• Operator inbox — approval requests with risk-tiered voting (low/medium/high/critical)
• Live swarm view (/live) — real-time visualization of the agent network

The agents connect via an MCP server (61 tools), so any Claude Code instance can plug into the network with one command. Each agent heartbeats its current status, so the dashboard always reflects what's actually happening.

I run 5 agents across 6 projects daily — the dashboard is how I coordinate work, monitor overnight autonomous sessions, and catch issues before they compound.

Screenshot of the live view: https://mycelium.fyi/live

Open source MCP server: https://github.com/SoftBacon-Software/mycelium-mcp

Use case: Discord + menubar dashboard for background agent monitoring

I regularly dispatch 3-5 background research agents from a single Claude Code session. My current workaround is using Discord edit_message to maintain a pinned status panel — essentially a poor man's dashboard that I manually update each time an agent completes.

What I actually need:

1. Event-driven updates — SubagentStart / SubagentStop hooks with unique agent_id so external tools can track lifecycle without polling
2. Lightweight status sink — a JSON file or statusline field I can read from a SwiftUI menubar app and a Discord bot simultaneously
3. Security boundary — when dispatching research-only agents, I want to enforce tool restrictions (e.g., WebSearch + WebFetch only, no Bash/Edit/Write). Instruction-level constraints aren't enough for untrusted workloads

The infrastructure layer described in this proposal (Agent Registry + enriched hooks + agent_id in payloads) would unblock all three. Especially agent_id in SubagentStop (#7881) — without it, you can't build any external dashboard that tracks more than one agent.

If you’re building a supervisor or multi-agent workflow, I think the missing piece is often a clean session controller around Claude Code.

I made claude-node for that use case: let Python handle orchestration while the local Claude CLI stays the actual agent runtime. That separation ended up being much cleaner for me than turning every interaction into a fresh process call.

Sharing in case it helps:
https://github.com/claw-army/claude-node

Strong +1 to this proposal, and I'd like to extend the focus in two directions:

1. Agent Teams as a first-class citizen

The dashboard concept applies equally — if not more urgently — to agent teams. With agent teams, you have a lead and multiple independent teammates with direct inter-agent communication, not just a tree of subagents reporting upward. A purpose-built orchestration surface that visualizes the full team topology (lead → teammates → task assignments → message flow) would make agent teams actually manageable at scale rather than requiring users to juggle tmux panes or cycle through in-process sessions with Shift+Down.

2. Desktop app as an _optional_ orchestration controller — with CLI parity and awareness

The more important gap, I think, isn't just visualization — it's the relationship between the Desktop app's Claude Code and the CLI. Right now they're effectively strangers sharing a filesystem. What I'd love to see:

• The Desktop app's Claude Code session should be able to optionally act as the primary orchestration controller for agent teams — spawning, monitoring, and steering teammates whether they're running in the Desktop app or the CLI
• The CLI should retain full feature parity (no second-class citizen)
• More critically: the Desktop app and any running CLI instances should have active awareness of each other — what sessions are running, what teams exist, what tasks are in flight — regardless of which surface initiated them
• This awareness should persist even for CLI sessions started independently, not just ones launched from the Desktop app

The filesystem already provides a shared substrate (worktrees, task lists, team configs). The missing piece is a coordination layer that surfaces that shared state across both interfaces in real time, and lets either one take the wheel.

The community tooling referenced in this thread proves the demand. A first-party solution that treats Desktop and CLI as two views of the same orchestration layer — rather than two separate tools that happen to share files — would be a meaningful step forward, especially for Windows users where tmux-based split panes aren't a viable fallback.

Strong +1 — adding a concrete real-world data point from a session yesterday that mapped exactly onto the gap this issue describes.

Use case: a single Claude Code session dispatched 13 background agents across 7 waves to land a multi-component feature (database migration, API client, admin handlers, scripts, docs, validator refactor). The flow had explicit gates: Wave N must commit before Wave N+1 dispatches, because Wave N+1 imports from Wave N's code. Across the session there were also independent waves that ran fully in parallel.

Two specific pain points the proposed dashboard would solve directly:

1. Wave/dependency awareness. I'd dispatch 3 agents and then have to mentally track "B1 + B2 must both finish and commit before B3+B4 can start safely." Currently this lives in chat scroll plus my own working memory. A dashboard with a dependency graph (or even just a wave tag per agent + ordering visualization) would make this a property of the tool rather than the operator.

1. The per-completion noise problem. Each agent's completion arrives as a separate task-notification message, interrupting the main agent's flow. By agent #7 the chat scroll is mostly "X done" / "Y done" acknowledgments. A dashboard pane consuming those events would let the conversation view stay focused on the operator's intent rather than agent bookkeeping.

Mitigation today: I've added a "fleet-view pattern" to my Claude memory (open with an agent table, suppress mid-wave chatter, full summary at gates). This is a workaround for the missing tool surface, not a substitute. The right answer is the dashboard the OP proposed.

One small addition to consider for the spec: agent grouping by dispatch wave as a first-class concept, with collapsible sections per wave and a "gate" marker between dependent waves. Useful even if dependencies are operator-declared rather than auto-detected.

Whatever ships, this would meaningfully change how I approach complex multi-agent work — likely making me dispatch more parallel work than I currently do (the current cost is the bookkeeping, not the agents themselves).

The gap this issue describes maps onto a specific coordination failure I keep hitting: when you have a lead agent dispatching 8–13 subagents across waves, the terminal view becomes a liability rather than an asset. You are context-switching between the main session window and trying to mentally track which wave you are on, which subagents finished cleanly, which are blocked waiting for input, and which are silently stuck.

A few things from running this pattern in production that seem directly relevant:

The interleaving problem is worse than it looks. Tool call output from subagents is mixed into the same scroll buffer as the lead's turn-by-turn reasoning. When you have 7 active subagents, you cannot tell which result belongs to which agent without reading backwards through the output. The TUI dashboard concept in this issue would fix that by giving each agent a stable row rather than an unbounded log line.

Agent status is the missing primitive. Right now the states you can observe are: running (the session is open), waiting (a tool is executing), and done (the session closed). The practical states you actually need — "this subagent finished its task cleanly," "this subagent hit an unexpected branch and needs a human decision," "this subagent is looping and consuming tokens without making progress" — aren't surfaced anywhere.

The desktop vs. TUI split matters. Some folks want this in the terminal; others want it as a web view or native app. A few tools (Beadbox, Mycelium, the Discord bot workaround mentioned earlier in this thread) fill the gap from outside Claude Code today. The right long-term fix is a first-class API surface that exposes agent state so dashboards can be built against it — rather than each workaround scraping terminal output.

The strongest case for this feature is unattended or overnight workflows: when Claude Code dispatches a large fleet before you step away, there is currently no reliable way to check status without reattaching to every session individually. A unified status surface — even just a file Claude Code writes to — would unlock a class of safe autonomous workflows that are too risky right now.

(Building Claudeverse — claudeverse.ai — a scheduling + coordination layer for Claude Code, so this is a pain point we track closely.)

theres a small cluster of tools doing the dashboard half of this now (AgentNexus, Mycelium, Beadbox), so worth being clear about what differentiates one.

the angle i took with repowire is that the dashboard is fed by the same mesh that carries the messaging, so its not a passive viewer, you can ask/notify a peer from the live view and steer it. it also spans runtimes, so a lead agents codex and gemini subagents show up in the same tree as the claude ones, which a claude-only dashboard cant do.

honest gap vs what youre describing: repowire shows peer/ask/spawn state and live status, but not yet a full per-agent token/cost meter or historical replay. so the spawn-tree + live-status + steer parts are there, the resource-accounting + replay parts are not.

@prassanna-ravishankar good roundup, and agreed these are mostly complementary. One clarification, since Mycelium got grouped under "claude-only dashboard" — it's neither claude-only nor a passive viewer:

• Spans runtimes, not claude-only: Mycelium is substrate-agnostic. The agents I run on it daily are a local squad — Qwen3-Coder, Qwen3.6, a DeepSeek-V4 head — served on Apple Silicon, right next to Claude Code instances. Anything that speaks the MCP joins the same network/tree, so it isn't tied to one vendor's runtime. (The whole point for me is owned local models, not just watching cloud sessions.)
• Steerable, not passive: the dashboard carries the mesh — inter-agent messages, blocking requests, directives, and a risk-tiered operator inbox (low→critical voting). You ask/notify/steer a peer from the live view, not just watch it.

Repo: https://github.com/SoftBacon-Software/mycelium

For this dashboard to stay trustworthy, I would anchor it on provider events rather than scraped terminal text.

Useful backing model:

• raw event log per agent/session
• normalized edges: spawned, messaged, waited-on, completed, failed
• per-agent token/cost/latency rollups with source provenance
• last known state plus stale/unknown state when no terminal event exists
• drill-down from any dashboard row to the transcript/tool events that produced it

The stale/unknown state matters. A dashboard that only shows running/completed will repeat the same failure mode as the transcript view: missing child completion looks like success or silence instead of an inspectable gap.

---

_Generated with ax._

Adding one narrower UI datapoint from building a small macOS companion surface for this problem: I think there are two different product surfaces here, and both matter.

1. A full dashboard is for inspection: agent tree, transcript drill-down, wave/dependency state, per-agent metrics.
2. A peripheral status surface is for interruption: something always visible that only answers "is it running, waiting for me, stuck, or safe to inspect now?"

For long unattended runs, the second one matters more than I expected. Most of the time I do not want to open a dashboard; I just need a trustworthy state transition outside the terminal so I know whether to keep working, step in, or leave it alone.

That pushes the infrastructure requirement in the same direction this issue describes: the backing API should expose durable state transitions, not just terminal-rendered text. At minimum, external surfaces need:

• stable session / agent ids
• running / waiting-for-user / blocked-or-stale / completed / failed
• last heartbeat timestamp
• terminal event provenance
• explicit unknown state after resume or process loss

I built Agent Island for the smaller peripheral layer on macOS: https://github.com/tristan666666/agent-island

It is not an agent hierarchy dashboard, but it is the kind of companion surface that becomes much more reliable if Claude Code exposes first-class agent/session state instead of every tool scraping transcripts or terminal output.

Good write-up of the problem. The "conversation view as control plane" issue is real - once you have 5+ subagents the interleaved transcript becomes actively harmful for understanding system state.

One pattern that has helped in practice: a separate poller process that reads the Claude Code hooks output stream and writes structured agent state to a side file (agent ID, task, token count, last tool call). This gives you a rough real-time view without blocking the agent loop. It is not the unified dashboard this issue is requesting - just a stopgap - but it moves the observability surface out of the terminal scroll.

The per-agent cost breakdown is the hardest piece. Right now you can infer it post-hoc from the session log but there is no streaming attribution while the run is in flight. If Anthropic does implement the agent tree view this issue proposes, tying token deltas to specific agent nodes would make cost attribution tractable in real time.

The 20+ fragmented issues this references are pointing at the same thing: the mental model of "chat with one assistant" does not compose to "supervise a team of agents". The surface needs to change, not just the features.

Surfacing this for anyone following along: the "buried approval prompts + no per-agent visibility" pain is real and well-articulated here. I've been building exactly in this space -- a session manager that surfaces per-agent status, cost, and coordination state without requiring you to read through interleaved scrollback.

The point about Kubernetes/k9s as the mental model is right. The conversation pane should stay conversational; the control plane belongs in a separate surface.

A few questions for the thread that might inform the design:

• When you're running 3-8 parallel subagents, what's the first thing you want to see on the dashboard? Per-agent progress, token spend, or which ones are stuck waiting for input?
• The TUI proposal here looks good, but is anyone hitting this pain hard enough that a standalone terminal daemon (not embedded in the Claude Code session itself) would be worth the setup overhead?

Happy to share what I've built so far if it's useful context for the feature discussion.

-- Kyle Carriedo, building Claudiverse (misfit labs) -- a session coordination layer for Claude Code