Beads: the AI-native issue tracker that became my second brain

What beads actually is

Beads (the bd command line tool) is an issue tracker designed for AI coding agents instead of humans clicking around a web app. Every piece of work is a small record in a graph database: a title, a description, a status, and, this is the important part, dependencies to other issues. When one issue closes, everything that was blocked on it becomes ready automatically.

Think of it as a database that tracks work the way an engineer's brain does. Not a flat todo list, but a web of "this needs that first." Agents read it, write to it, and never lose the plot between sessions.

Why AI agents need a tracker

If you work with AI agents long enough you hit the same wall I did: the context window ends, the session dies, and everything the agent knew about half-finished work evaporates. Markdown todo files rot. Plans drift from reality within a day.

Beads fixes this by being the persistent memory outside the model. The agent starts a session, runs bd ready, and sees exactly what is unblocked and worth doing. It discovers a bug mid-task? It files a new issue with a dependency link and keeps moving instead of derailing. The next session picks up where the last one stopped, even if it is a completely fresh context.

The tracker is the memory. The agent is just the driver who reads the pit board.

Running ZuraLog on it

ZuraLog is where beads earns its keep. Every feature of the app lives as an epic with child issues: the sync engine, the Zura coach prompts, App Store screenshots, paywall experiments. When I sit down to work, or point an agent at the repo, the question is never "what was I doing?" It is bd ready, pick the top item, go.

The dependency graph matters more than I expected. Health-data sync had to land before the coach could reason over sleep data, which had to land before the insights screen meant anything. Beads holds that chain so nothing ships out of order.

Beyond code

The surprise was how well it works for things that are not code. I track health plan comparisons and market research for ZuraLog the same way: each competitor teardown is an issue, each pricing experiment depends on the research issue that feeds it. My side projects each get their own database and the daily question stays the same: what is ready?

It sounds like overkill until you have five projects and an AI agent working on three of them while you sleep. Then it is the only thing keeping the whole operation honest.

The debrief

Lesson one: agents are only as good as the state you persist for them. Lesson two: dependencies beat priorities. A priority list tells you what matters, a dependency graph tells you what is actually possible right now. Lesson three: if a tool is good enough for your code, try it on your life. The overlap surprised me.