Beads is by far the most popular vendor-neutral agent work management system. Its direct alternatives are not PRD generators, human issue trackers, orchestration libraries, or terminal dashboards. They are tools built to keep coding-agent work durable, structured, queryable, and available beyond one model session.
The serious comparison set is Beads, br, ticket/tk, Trekker, Knots, and PaiR. Each carries the Beads idea in a different direction: versioned databases, a frozen classic architecture, Markdown files, an event log, a small local graph, or a visual desktop product.
Gas City, Inc. is the company behind Beads. This review uses the project census and primary-source check completed July 17, 2026, with current Beads behavior rechecked July 31.
The comparison set and method
Every product in the matrix is vendor-neutral with respect to the coding agent or model doing the work. Every product has a durable task or work model intended for agents, not only for people. The review asks seven questions that matter once more than one agent is doing consequential work:
- Does work survive agent crashes, context loss, and handoffs?
- How much of the real work graph can the system represent?
- Can several agents claim and update work without creating races?
- Is history native, queryable, and independent of code commits?
- Can work cross sessions and machines without collapsing into chat transcripts?
- Can different coding agents discover and use the system effectively?
- Is there enough adoption, documentation, and ecosystem support to trust the protocol as it evolves?
The roundup excludes Task Master because PRD planning is a different job. It excludes Jira, Linear, and GitHub Issues because they are organizational systems of record. It excludes Conductor and similar products because session control is a different product category.
Beads at a glance
These criteria measure whether a work manager can become durable shared memory for coding agents rather than merely another place to write tasks.
| Criterion | Beads capability |
|---|---|
| Crash-resistant continuity | Work identity, status, assignment, dependencies, provenance, and history live outside the coding-agent session |
| Work-graph depth | The current protocol distinguishes hierarchy, blockers, discovery provenance, related work, validation, duplication, and supersession instead of flattening them into one link type |
| Coordination safety | Atomic claim reserves one item for one worker, while embedded and server modes cover solo and concurrent operation |
| Versioned history | Dolt makes the work database and its history the source of truth, with native branching, merge, backup, push, and pull |
| Agent and model neutrality | Beads works across coding-agent CLIs rather than making the work model an extension of one agent vendor |
| Recognition and integration | A clean-project evaluation makes recognition measurable, while official host integrations make setup and project behavior repeatable |
| Adoption and ecosystem | Beads has by far the largest measured distribution and community in the July 2026 direct set, plus current docs, integrations, viewers, and a commercial team path |
Product architectures at a glance
| Product | Source of truth | Work graph and readiness | Coordination model | Operating profile |
|---|---|---|---|---|
Beads (bd) | Version-controlled Dolt database | Typed relationships, hierarchy, blockers, provenance, bd ready | Atomic claim; embedded mode for one writer, server mode for concurrent writers; Dolt remotes across machines | Teams that want durable work, rich graph semantics, history, and a broad vendor-neutral protocol |
br / beads_rust | SQLite database plus a JSONL sync representation | Classic Beads graph, ready/blocked queries, scheduler | Atomic local claim plus reconciliation and sync guards around two stores | Legacy installations that cannot yet leave the retired SQLite-and-JSONL contract |
ticket / tk | One Markdown/YAML file per ticket | Parents, hard dependencies, links, ready and blocked queries | No claim or lock; separate files reduce unrelated edit conflicts; Git moves work | Small projects that prize inspectable files and a 1,383-line Bash implementation |
| Trekker | Local SQLite database | Epics, tasks, subtasks, dependencies, and ready queries | Local project operation; no built-in remote or atomic claim documented in the reviewed version | Claude-oriented users who want a compact local task graph |
Knots (kno) | Append-only events on a dedicated Git branch, with a derived SQLite cache | Typed edges, queues, workflow states, gates, and execution plans | Atomic poll/claim, expiring leases, optimistic concurrency, event merge | Teams that want enforced queue transitions and lease-based agent work |
| PaiR | Local SQLite plus JSONL in a dedicated tracker branch | Hierarchy, dependencies, external blockers, ready work | Desktop sessions, Git synchronization, conflict handling, LAN peers | Operators who want work management and agent terminals in one visual desktop product |
The table exposes different storage, coordination, and operator models without collapsing them into one ranking.
Beads: the broad, durable protocol
Beads stores work in Dolt. The default embedded mode runs in process with no server to manage; server mode supports concurrent writers. Durable issue and graph writes become database state, and Dolt history makes those changes inspectable and reversible. Claim leases and bd heartbeat are intentionally node-local and do not create Dolt commits or history. bd dolt push and bd dolt pull carry database history across machines.
The work model separates relationships that flat trackers often blur. Parent/child expresses scope. blocks determines readiness. discovered-from preserves why work appeared. bd ready computes the actionable frontier, while bd update --claim reserves an item atomically.
Beads also has the largest distribution in the direct set. The July 2026 review found a wide lead over every direct alternative on both GitHub stars and cumulative release-asset downloads. By July 30, Beads had crossed 800K cumulative GitHub release-asset downloads. The npm installer fetches those same release assets, so npm downloads are not added as another installation total. Release-asset downloads include upgrades, automation, and retries rather than unique users, but the gap to the direct alternatives is substantial.
These capabilities are relevant when work must remain intelligible through crashes, compaction, handoffs, concurrent workers, and movement between machines.
br: the retired Beads storage model, deliberately frozen
br is a Rust reimplementation of the pre-Dolt Beads architecture. It freezes SQLite plus JSONL after current Beads moved to Dolt.
This is not a toy fork. br keeps the familiar graph, ready/blocked queries, and atomic local claim, then adds audit logs, scheduling, coordination diagnostics, sync guards, and recovery tooling. Much of that safety machinery exists to manage a SQLite database and a JSONL representation that can become stale or divergent.
Beads left that two-store pipeline behind after real stale-state, merge, deletion, corruption, and split-brain failures. Current Beads keeps work and Git-like history in Dolt; JSONL is only interchange. It also continued expanding the graph and agent interface while br diverged. br does not carry Dolt history, Dolt remotes, or current Beads protocol features, and its license includes a rider withholding rights from OpenAI and Anthropic.
br preserves compatibility with the classic Beads SQLite-and-JSONL contract and provides a Rust implementation with additional audit, scheduling, and diagnostic surfaces. The tradeoff is retaining two representations that must be reconciled, omitting Dolt history and remotes, and diverging from the current Beads protocol. The direct Beads vs br comparison covers those storage and migration details.
ticket / tk: a disciplined small work graph
ticket reduces the system to one Bash script and one Markdown/YAML file per ticket. The files carry stable IDs, status, type, priority, assignee, parent, dependencies, links, tags, descriptions, design notes, acceptance criteria, and timestamped notes.
The graph is real. tk ready and tk blocked derive work from hard dependencies. tk dep tree traverses the graph and tk dep cycle finds cycles. The product does not need a database index because each command reads the files directly.
The restraint is impressive. Its 1,383-line Bash core includes stable and partial IDs, priority ordering, tags, notes, and the essential graph queries. A Git-style plugin system keeps editing, JSON queries, and Beads migration outside the core, while 124 behavior-driven scenarios exercise the small command surface.
That simplicity creates a clear concurrency trade. Agents changing different tickets touch different files. Agents changing the same ticket rely on ordinary filesystem and Git behavior. There is no documented atomic work claim or lease.
For a solo developer or one agent working at a time, tk is a coherent and useful product. The boundary appears when several agents share a ready frontier: there is no documented atomic work claim or lease. The Beads vs ticket comparison makes that boundary concrete.
Knots: event-driven workflow enforcement
Knots treats work as an append-only event stream. Events live away from the code branch, a SQLite cache makes queries fast, and synchronization merges immutable event files instead of one mutable task database export.
Its distinctive feature is operational discipline. Queues, workflow states, execution plans, gates, atomic polling, expiring leases, and optimistic concurrency make the tracker enforce how agents take and advance work. A lease gives abandoned work a route back to the queue.
Knots supplies an opinionated workflow state machine around agent work. Its public adoption remains small, while its event and lease design provides capabilities that are absent from simpler task graphs.
Trekker and PaiR: two different product shapes
Trekker is a small TypeScript/Bun task graph with SQLite storage and a Claude Code plugin. It supports epics, tasks, subtasks, dependencies, and ready-work queries. It fits a local, Claude-heavy workflow that wants more structure than Markdown without adopting the breadth of Beads.
PaiR turns the work manager into a desktop operations product. It combines its own CLI and schema with task views, terminals, tmux sessions, journals, Git synchronization, and LAN peers. PaiR is free but source-unavailable; its distribution repository contains binaries and documentation rather than the application source.
Trekker keeps the graph small. PaiR expands around it into a visual control room. Both remain direct alternatives because durable agent work is part of the product’s center, not an incidental integration.
Distinctive strengths and tradeoffs
| Product | Distinctive strengths | Tradeoffs to examine |
|---|---|---|
| Beads | Dolt-backed versioned history, rich typed relationships, atomic claim, concurrent-writer mode, broad integrations, 20+ community tools including terminal, web, editor, and native viewers, and the largest measured adoption in this set | A larger protocol and database surface than the deliberately minimal alternatives |
br | Rust implementation, classic Beads compatibility, atomic local claim, audit log, scheduler, and coordination diagnostics | SQLite and JSONL must remain synchronized; no Dolt history or current Beads protocol; license rider for OpenAI and Anthropic |
ticket / tk | Readable Markdown/YAML records, a 1,383-line Bash core, 124 behavioral scenarios, and an extensible plugin boundary | No documented atomic work claim or lease; Git supplies history only after files are committed |
| Trekker | Compact Claude-oriented SQLite task graph with epics, dependencies, ready queries, and a built-in viewer | No built-in remote or atomic claim documented in the reviewed version; narrower graph and integration surface |
| Knots | Enforced workflow states, queues, gates, optimistic concurrency, expiring leases, and append-only events on a dedicated branch | Opinionated queue model and a much smaller public adoption footprint |
| PaiR | Integrated task views, terminals, tmux sessions, journals, cross-project navigation, Git synchronization, and LAN peers | Source-unavailable application with a desktop-centered operating model |
Build the decision from the constraints
The products preserve durable work, but they make different promises about storage, coordination, workflow enforcement, portability, inspection, and operator experience. Those differences matter more than a publisher-assigned rank.
Run the same scenario through the candidates: start two workers on one ready frontier, interrupt one after it claims work, add a dependency from another machine, and ask a fresh agent what is ready. Then inspect the claim behavior, recovery record, synchronization path, graph semantics, human interface, and operational burden. The results let the reader decide which tradeoffs fit the actual work.
Related articles
- Beads vs
br: See why Beads replaced the SQLite-and-JSONL architecture with Dolt. - Beads vs
ticket/tk: Compare a versioned database with one Markdown file per ticket. - Task management for coding agents: Identify the category and operating requirements before choosing a product.
- Beads: Read the full product, adoption, durability, and agent-memory narrative.