"kgai vs beads: the work queue and the why are different records"
beads isn't a memory layer in the usual sense. It's an issue tracker built for coding agents, and it comes up next to kgai because both give agents durable structure across sessions. That's a fair pairing, because they're two halves of the same problem. beads tracks the work. kgai records the why. We build kgai, so read this with that in mind.
What beads is good at. It replaces informal markdown plans with a dependency-aware task graph. Agents list what's unblocked with bd ready, claim work atomically, close it, and pull injected context with bd prime. Storage is Dolt, a version-controlled SQL database, embedded in-process by default with a server mode for concurrent writers, and it syncs across machines through Dolt push and pull. MIT. If your agents keep losing the thread of what to do next, this is the tool doing that job.
Where kgai differs, structurally.
- Work state vs decision history. A closed task tells you something happened. A decision records why, what was rejected, and what superseded what. Agents read tracker state as ground truth, so state that outlives the plan behind it gets believed anyway. That gap is exactly what decision memory exists for.
- Supersession is first-class. In kgai a new decision supersedes an old one through an explicit link with a reason, recall returns only what's in force, and the full chain stays queryable, dead ends included. An open beads issue (#5818) asks for exactly this shape, first-class decision records with a status and a supersedes link, which that team currently maintains by hand in a markdown file beside the tracker.
- What syncs, and how. beads syncs a database. kgai appends immutable, content-addressed events to per-writer shards and syncs them through an S3 bucket you own, so parallel writers can't produce a textual conflict by construction. The graph is a deterministic projection of that log, rebuilt the same way on every machine.
Choose beads if your agents need a work queue with real dependencies and atomic claiming, which kgai does not do and won't. Choose kgai if your team needs the decision record underneath the work, for teams where the LLM does most of the coding. Honestly, they barely overlap. Running both is a reasonable setup, one tracks what to do, the other remembers why it's like this. Closer to kgai's own lane, kgai vs engram compares two local-first memories directly.
Install is two commands and the store is plain files in your repo. Nothing about it touches your tracker.
Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.
See how kgai compares to other tools on the comparison page, or browse the other notes.