[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._

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

The framing here is exactly right: the conversation view was built for human-to-one-agent, not as a control plane for 7 concurrent subagents. The mental model mismatch shows up fast.

A few things worth calling out from experience running larger agent fleets:

The blocking issue is not rendering - it is that there is no canonical "agent identity" today. Without stable agent_id in hook payloads, any dashboard is essentially screen-scraping tmux output to infer state. That is fragile and explains why every third-party tool in this space (amux, wmux, the various TUI wrappers) has slightly different heuristics for "is this agent stuck or just thinking."

The SubagentStart hook you listed as a prerequisite is probably the most important single change. Once you have reliable start/end events per agent, monitoring falls out naturally - you do not need the dashboard to be especially smart if the data stream is clean.

On the "historical replay" point: this is actually achievable today with hooks + a local event log, even without native support. If you write a PostToolUse hook that appends structured JSON to a per-agent log, you get a replay-able audit trail. We do this in our setup and it has been the most useful debugging tool by far for understanding why a parallel run went sideways.

The consolidated issue list here is useful - a lot of these (#22995, #16901, #20559) are the same underlying need expressed differently. Hope Anthropic treats this as one infrastructure request rather than 20 feature requests.

(Disclosing: I build Claudeverse, a tool for multi-agent Claude Code workflow management.)

This is a well-structured proposal that captures a recurring pain pattern across the community.

The demand for a unified control plane is real. Running 5+ concurrent Claude Code sessions is increasingly common, and the current model -- where every agent's status lives only in its own terminal scroll -- breaks down fast. The "conversation view designed for single-agent dialogue" framing in this proposal is the right diagnosis.

One thing worth noting from community observations: the 20+ fragmented issues you consolidated here tend to cluster into two distinct user needs that may want different solutions:

1. Monitoring while running -- knowing what each agent is doing right now, what it's waiting on, how much context it has left. This needs low latency and maps well to the TUI dashboard proposal.

1. Handoff and recovery -- resuming work after an agent finishes, crashes, or hits a context limit. This maps more to the session discovery + structured state export pieces.

The first need is urgent and blocking active work. The second can be partially worked around with CLAUDE.md summaries or checkpoint files. If the team has to pick a starting point, the "agent_id in hooks + SubagentStart hook" foundation would serve both, since it lets the community build monitoring tooling immediately without waiting for a full dashboard.

Looking forward to seeing this move forward -- the infrastructure dependencies list is a helpful prioritization signal.

The pain here is real - once you go past 3-4 nested subagents the conversation view becomes nearly unreadable. You end up doing mental accounting of which agent spawned what, and approval prompts surface in the scroll noise.

One pattern that helps right now: write a brief "state file" (just a markdown) to a tmp path at each subagent handoff, then have the orchestrator read it before each spawn. Not a proper solution but it cuts the confusion when you need to trace what happened. The agent tree still isn't visible but at least you have a breadcrumb.

The DAG visualization you're describing is the missing control plane. Building Claudeverse (a runner that manages multi-agent Claude Code cycles with a separate orchestration layer) has made clear how much the in-session view breaks down at scale - you really do need the agent tree, per-agent cost, and state outside the chat transcript.

Upvoted. Would love to see this landed.

+1 from a use case this proposal already covers well (per-agent status, cost/token tracking, cross-session visibility), plus one gap I ran into that isn't in scope here but is closely related — filing that separately as #91888, linking back to this thread.

Context: I run multi-agent "subagent-driven development" style workflows a lot — a controller session dispatches a fresh implementer subagent per task in a plan, reviews its diff, runs fix-round loops when the review finds something, and repeats across a plan with 20-30 tasks, often with several tasks running in parallel in isolated git worktrees to avoid collisions. Everything this proposal's Agent Tree / Task Panel / Stats Panel would show is exactly what I currently reconstruct by hand from a markdown "ledger" file I make the session maintain and update after every task, because there's no built-in surface for it. So: strongly +1 to this landing.

The one thing I couldn't map onto this proposal's scope is plan structure rather than agent structure — which tasks in a plan block which others, and the iteration history within a single task (round 1 found N findings, round 2 fixed M of them, round 3 closed it). That's a different shape of graph than the agent parent-child tree this proposal describes, so I've filed it as its own issue rather than trying to fold it in here — but if the Task Panel this proposal describes ever grows plan-awareness, that's exactly where it'd want to live.

+1, with a concrete implementation angle that I don't think has come up in this thread yet, plus a quick verification.

The building blocks for a live agent-flow view already exist in the early-access function-hooks plugin API (the mods/ folder in this repo is the source of the built-in /diff, telemetry and sec-default mods). From the published declarations in mods/types/claude-code.d.ts:

• agent.spawn carries the prompt, subagentType and parentAgentId, and its result carries the new agentId and resolved model, so parent→child edges are known at spawn time.
• $.agent.list() returns every subagent and in-process teammate with id, type, status and parentId.
• tool.call carries the agentId of the loop it runs in, and turn.complete closes each loop's turn with durationMs and usage.
• ui.open + ui.render of Pane draw a pane beside the transcript, which is exactly how the built-in /diff pane is implemented. The render contract covers the terminal and the desktop surfaces.

Verified on 2.1.270 with a throwaway ~200-line mod (function hooks are early access and off by default, so this needs them enabled): /flow opens a docked pane; dispatching one Explore subagent produced agent.spawn (id, parent=main, type, model), two tool.call events tagged with the subagent's id, and turn.complete with its duration. The pane re-rendered on each event and the node went from running to completed:

Agent flow · 1 agent · 0 running
main
└─ ✓ Explore "Count .ts/.tsx files in hooks dir"  4s · Bash ×2  [completed]

So an /flow pane could ship as another built-in mod, fed by engine events rather than scraped terminal text (which addresses the trustworthiness point raised earlier in this thread).

One gap worth flagging for the maintainers: the AgentLoop docs say Workflow-tool agents and the engine's own forks "carry ids no list names", so $.agent.list() cannot see a /workflows run today. For a dashboard to cover dynamic workflows, those agents would need to be listed too, or the run journal exposed to plugins.

Follow-up: the mod I sketched above now exists and is published.

agent-flow — https://github.com/Charlie0113-T/claude-agent-flow (Apache-2.0)

claude plugin marketplace add Charlie0113-T/claude-agent-flow
claude plugin install agent-flow@claude-agent-flow

/flow opens a pane beside the transcript with a live, read-only tree of the session's subagents and in-process teammates: status, type, description, elapsed time, what each agent is doing right now (a tool call and its duration, or a wait for the person's approval), call count, tokens once finished, and a [+] per row that expands details. Engine events feed pure reducers; $.agent.list() reconciles every 2 s while anything runs; loops the engine never listed appear under a collapsed "unlisted loops" group. Where no pane can be drawn, /flow prints the same tree as text (/flow text always does).

Scope note: VS Code 2.1.269 shipped its own agent map (footer pill → per-agent cards, Stop, transcripts), so the extension side of this issue is covered; this mod is the terminal counterpart, built on the same function-hooks API as the built-in /diff mod. Hooks modules are early access, so it loads only where they are enabled.

Verified: 68 unit tests, claude plugin validate, and an expect-driven interactive smoke test (9/9: pane drawn, nested general-purpose → Explore tree, running → completed). A PR-ready branch with the mod under mods/agent-flow is at https://github.com/anthropics/claude-code/compare/main...Charlie0113-T:ARRS-claude-code:upstream-agent-flow for anyone who wants to run it through the mods CI.

Two API gaps met along the way, for the maintainers: $.agent.list() cannot see a Workflow tool's agents (as the AgentLoop docs say), and no engine event carries the person's answer to a permission prompt, so a wait shows until the approved call ends.