You can run 10 AI coding agents in parallel now. Spin up a tmux session, give each agent a task, and let them coordinate through beads. It works. We do it every day.
But here's what nobody talks about: you can't see any of it happening.
The visibility gap
beads solved the memory problem. Before beads, agents forgot everything between sessions. They'd churn through markdown todo files, lose context after compaction, and re-discover the same bugs three times. beads gave them persistent, structured, git-backed memory. That was a breakthrough.
But beads is a CLI tool. It's built for agents, not for the humans supervising them. When you want to understand the state of your project, you run bd list. You get a flat list of issues. You run bd show bb-abc to read one. Then another. Then you run bd dep list to understand what's blocking what. Piece by piece, you reconstruct the picture in your head.
That's fine for five issues. It falls apart at fifty. And when you have 10 agents filing, updating, and closing issues in real time, the CLI can't keep up with you, let alone with them.
What we built
Beadbox is the visual layer on top of beads. It watches your .beads/ directory for changes and renders everything in a native desktop app within milliseconds. When an agent updates an issue in the terminal, you see it in Beadbox before your shell prompt returns.
No accounts. No cloud. No syncing. Your data stays on your machine, in the same .beads/ directory your agents already use. Beadbox just reads it and shows you what's happening.
Here's what that looks like in practice:
Epic trees with progress bars. Your top-level epic shows 7 of 12 children complete. You expand it, see which subtasks are blocked, which are in QA, and which agent is working on what. One glance replaces a dozen bd show commands.
Real-time sync. We watch the filesystem for database changes. When an agent commits a status change, Beadbox picks it up through a file-watch pipeline and pushes it to the UI over WebSocket. No polling. No refresh button.
Multi-workspace support. If you're working across multiple projects, switch between beads databases from a dropdown. Each workspace remembers its own filters and view state.
Dependency visibility. Blocking relationships show up as badges on every issue. You can see at a glance that bb-q3l is waiting on bb-f8o without running a single command.
How we build Beadbox
We use beads and Beadbox to build Beadbox. That's not a gimmick. Our daily workflow runs 10+ Claude Code agents coordinated through a supervisor agent. Engineering, QA, product, marketing, shipping, all tracked as beads in a single database. Nelson watches the whole operation in Beadbox while agents file issues, claim work, push code, and report back.
Every feature we ship gets tested on our own workflow first. If the epic tree doesn't make sense when you have 50 active issues across 6 agents, we fix it before anyone else hits that wall.
The tech stack is intentionally boring: Next.js for the UI, Tauri for the native wrapper, the bd CLI as the single source of truth. We never read the database directly. Every operation goes through bd, which means Beadbox always agrees with your terminal.
Where this is going
Today, Beadbox is a dashboard. You watch your agents work. You triage issues. You track progress across epics.
Tomorrow, it becomes the control plane. We're building toward a world where you can dispatch work to agents, review their output, and manage your entire fleet from one window. The terminal stays the agent's home. Beadbox becomes yours.
We're in beta, so it's free. Try it.