Beads: the issue tracker that gives AI agents a memory layer
Instead of another markdown checklist, Beads stores tasks as a versioned, dependency-aware graph so agents can claim, branch, merge, and compact work without losing context.
- Beads treats task state as durable memory, not disposable notes, so an agent can return to the same work without re-deriving the plan.
- Dolt is the key move because it makes that memory branchable, mergeable, and compacted instead of locked inside a fragile text file.
- The graph model matters more than the UI because claims, dependencies, and conditional blocks turn work into a versioned workflow.
- Beads is heavier than a TODO list, but that weight buys something markdown cannot, which is shared context that survives long, multi-agent work.
The real problem is not planning. It is amnesia.
Agents do not usually fail because they lack a plan. They fail when the session resets, a branch changes, or the work stretches long enough for context to rot. A markdown checklist can record intention, but it cannot protect state.
Beads starts from a harder claim: agent work should behave like software data. A task can be claimed, blocked, branched, merged, and compacted because long-running work needs those verbs more than it needs another note-taking surface.
Steve Yegge's bet was bigger than a tracker
Beads comes out of Steve Yegge's GasTown line of thinking, where agents are not chat windows but a herd that needs shared state. That framing matters. It turns the project from a productivity tool into coordination infrastructure.
The implication is blunt. An agent will come back later, another agent may pick up the same work, and both need the same memory without rewriting each other's notes. Beads is built for that handoff, not for a human skimming a list.
I’ve never seen the code, and I never care to… I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now.
Inside Beads: a graph, not a list
The core unit is the issue node, but the real meaning lives in the edges. Dependencies say what must happen first. Claims say who owns the work. Conditional blocks let a follow-up task happen only when the prerequisite fails, which is much closer to workflow logic than to a to-do checkbox.
Under the hood, the Go CLI wraps that state in a command context and stores it in Dolt so the graph can branch and merge. That matters because the plan itself becomes versioned, so the memory can evolve alongside code instead of living in a fragile side file.
That is the real leap. Beads treats state as something agents can revisit, fork, and reconcile, not just something they can append to. Once you see the graph that way, the rest of the design starts to make sense.
Why Dolt is the sharpest part of the design
Dolt is not a decorative dependency. It gives Beads Git-like semantics for data, which is exactly what agent memory needs. An agent can work on one branch of code and one branch of task state, then merge them when the shape of the work changes.
That same choice makes compaction meaningful. Old work can be summarized without deleting the live graph, so the active memory stays small while history remains queryable. In agent tooling, that is a serious advantage over a flat note file.
Beads versus the tools everyone already uses
The real comparison is not with Jira alone. It is with the default stack most agents get today: a TODO.md, a PLAN.md, or a human-first tracker built for people clicking through work, not for software rewriting itself.
| Tool | Memory model | Branching and merge | Best at | Weak point |
|---|---|---|---|---|
| Beads | Versioned graph | Native | Long-horizon agent work | More structure to manage |
| TODO.md / PLAN.md | Plain text list | Manual and fragile | Quick human planning | Easy to overwrite or drift |
| Jira / Linear | Centralized tickets | Limited or external | Team workflow and visibility | Not designed for agent-owned state |
That table is the point in plain language. Beads is not merely better task management. It is a different model of state, with stronger guarantees for agents that do not stay in one session or one branch for long.
The trade-offs are real
Beads asks for more structure, more concepts, and more operational discipline than a text file. That is the price of making memory durable. If your work is short-lived or lightly coordinated, the machinery may feel heavy.
The criticism matters because it points at the product's boundary. Beads is compelling when work is long-horizon, multi-agent, and stateful. It is less compelling when you just need a scratchpad.
What Beads suggests about the next wave of software
The deeper lesson is that agent-era software will need better state primitives, not just better prompts. Once you accept that agents forget, the answer stops being "write clearer instructions" and starts looking like databases, graphs, and mergeable memory.
Beads is one of the clearest attempts to make that idea concrete. It treats coordination as a first-class data problem, which is probably where a lot of the next wave of developer tooling will begin.