The Board
A CLI is native to agents. It’s not native to humans. At least not for the kind of spatial reasoning you do when looking at a backlog. You need to see the shape of the work: what’s blocked, what’s in progress, what’s piling up. That’s a board, not a terminal.
This weekend I built one.
One command, one binary
Run beats board and you get a web UI in your browser. No database. No Docker. No infrastructure. The Go binary embeds a React frontend at build time, serves it on localhost, and communicates over a REST API backed by the same append-only event log that the CLI uses.
This was a deliberate constraint: a single binary that does everything. If someone has to install a database or run Docker to use a project management tool for a three-person team, the tool has already failed. The event log is the database. The embedded frontend means there’s nothing to install, configure, or keep running.
The v2 data model
The web board forced the v2 data model upgrade I’d been thinking about since January. The original flat JSONL wasn’t enough once issues had comments, richer relationships, and the kind of metadata you need to render a useful board.
The migration was painless because of the append-only design. I didn’t have to transform data in place. I changed how events are projected into current state. Old events still work, new events carry richer payloads. The event log is the source of truth, the projection is just a fold. I was worried about this for weeks and it took an afternoon.
What’s in the board
The first version has a backlog view with issues grouped by parent epic. You can see status, type, estimates, and the issue hierarchy at a glance. Comments landed the same day, and you can now have threaded discussions on issues. Dependencies are first-class with a beats link command.
Comments matter more than I initially thought. For human-agent teams, comments are how the agent explains what it tried, what failed, and what it decided during implementation. Without comments, the human has to dig through git diffs or conversation logs to understand what happened. With them, the agent’s reasoning is right there on the issue, reviewable asynchronously.
A realization about planning
Building the board surfaced something I’ve been circling around since January. When I look at a backlog in a board view, with epics broken into stories, stories ordered by priority, dependencies drawn between them, I’m looking at a plan. Not a plan document sitting in a Google Doc or a markdown file. A living plan that evolves as work happens.
This is the thing that was nagging me last month about decisions living outside the tool. The issue tracker isn’t just where you track execution. It’s where problem decomposition happens. An epic is a decomposition of a goal into stories. The ordering of those stories is a plan. The dependencies between them are constraints. All of this is design thinking captured in the structure of the backlog itself.
I’ve been writing design documents and project plans in markdown files alongside the repo, treating Beats as the place where the results of that planning get tracked. But the planning itself, the breakdown, the sequencing, the dependency mapping, that’s what the issue tracker is for. The markdown files are a crutch for what the tool should be doing natively.
I don’t have time to act on this insight right now. I need to let the board settle and use it across real projects for a while before I know what it actually needs. But this thought won’t leave me alone.