beads vs Trellis
Distributed graph issue tracker for coding agents on Dolt: dependency-aware beads replace markdown plans — bd ready/claim/close, cell-level merge, push/pull across machines and agents. CLI + MCP. — versus — Spec, task and memory layer that lives in your repo: .trellis/ holds conventions, PRDs and journals, auto-injected each session — one workflow across 20 coding-agent platforms.
Same job — durable spec/task state for coding agents. Trellis bets on markdown living in your repo; beads bets on a Dolt graph DB with merge semantics for multi-agent, multi-machine work.
| beads | Trellis | |
|---|---|---|
| Stars | 26k | 14k |
| Forks | 1.7k | 754 |
| Language | Go | TypeScript |
| License | MIT | AGPL-3.0 |
| Last activity | yesterday | 4 days ago |
| Topics | coding, memory | coding, memory |
| Curated connections | 2 | 3 |
beads — the curator's take
Steve Yegge's answer to agents drowning in markdown TODOs: task state as a versioned database with real merge semantics, so parallel agents claim and release work without trampling each other — the dependency graph decides what's 'ready'. When NOT: solo short-horizon sessions — bd init plus a Dolt store is infrastructure, and if tasks finish in one sitting a todo list wins. Note it remembers WORK, not knowledge — recall memory is a different shelf.
Trellis — the curator's take
Attacks the right problem — agents restart from zero every session — with the boring, durable fix: files in the repo, not a memory service. Team-shared specs are the real moat; one engineer's hard-won rules compound for everyone. It's opinionated though: the 4-phase loop (brainstorm → implement → check → update-spec) only pays if the team actually adopts the process — half-adopted, .trellis/ rots into stale paperwork. AGPL-3.0: fine to use, but check your company's license policy. Skip it for weekend projects; this is process overhead that needs a team to amortize.