Backlogs are better off being represented as a task dependency graph, rather than a heap of markdown files, because a nice graph of tasks:

- helps agents focus - gives better observability of partial progress - supports parallelization better - works well with subagents

Also, the act of planning a backlog *makes the design better* because in the act of planning, you learn things about your own design. This is as true for agents as it is for humans.

The planning modes of claude and codex blur the distinction between specs and backlog and land you in a heap of markdown files.

Steve Yegge diagnosed all this, and his solution was the beads CLI -- a brilliant idea. You just tell your agent to use this CLI for planning instead of their own plan mode (all you do is add a one-liner in your AGENTS.md file), and you get an instant planning upgrade.

However, I found the implementation of beads a little bit hairy and flaky, when I tried to use it in production. And the performance made me sad.

So I've reimplemented the core concepts, as ergo.

It's very fast (5-15x faster than beads), very robust, and rigorously simple. There is no daemon running, no SQL database, it's self-healing, and the plans are stored as JSONL, so if all else fails you can just reconstruct your plans from scratch.

Implementation:

- Plans live in `.ergo/` in your repo root (or your dir of choice). JSONL was chosen because it's git-friendly & easy to resolve merge conflicts around. - ergo is concurrency-ready if you're into agent swarms. Concurrent writes are serialized with flock(2). Multiple agents can race to claim tasks — exactly one wins, others fail fast. - Do operations in huge plans of 1000+ tasks in ~15ms on a Macbook Air. - The help text doubles as the agent manual. I spent a lot of time on `ergo --help` and `ergo quickstart` because they're the primary interface for agents.

I've been using ergo heavily for a couple months and I believe it's solid enough for anyone to use, would love your feedback.