Hamloy vs Beads

When to choose which

Choose Beads when:

• you want the code: it's open source under MIT, and you can read, change and run all of it;
• the list should live in the repo and travel with it, with no account and no network to a service;
• your agents work best through a command line and you want a deep dependency graph, with many kinds of link and gates that wait on a timer, a CI run or a pull request;
• you are comfortable with a tool of 70 or more commands.

Choose Hamloy when:

• you want to see your agents' work on a live board without installing a UI, from any machine or your phone;
• your agents ask you things often, and you want those as a list of questions with options and the one they recommend, and requests with steps;
• your agents include apps without a shell, such as Claude on the web or ChatGPT, next to Claude Code and Codex;
• you'd rather not sync a database: every machine and person sees the same lists at once.

Pick one for a project's tasks. Two trackers holding the same work is worse than either.

What Beads does

From Beads' own README and docs, read on 10 October 2026 (github.com/gastownhall/beads, which steveyegge/beads now leads to):

• Storage is a Dolt database in the repo's .beads/ folder; between machines it goes with bd dolt push and bd dolt pull through your git remote. IDs like bd-a1b2 are hashes, so two branches don't collide.
• Work goes through bd: bd ready lists issues with no open blockers, bd create, bd update --claim, bd dep add, bd close. Claiming is atomic, "the first claim wins", and worktrees share the main repo's database.
• Agents: bd setup has recipes for Claude, Codex, Cursor, Gemini, Windsurf and others, and bd init installs the Claude Code, Codex and Cursor integrations. An MCP server, beads-mcp, is meant for clients without a shell; the docs recommend the command line where there is one.
• People: issues labelled human need you; bd human list shows them and bd human respond adds your answer and closes the issue.
• Memory decay: old closed issues can be summarized to save the agent's context; the original text is discarded.
• No board of its own: bd graph --html writes a graph, and the README lists terminal, web and editor UIs built by others.

What Hamloy does

Every agent calls the same lists on hamloy.com through MCP tools: list, claim, tick, add, answer and seven more (the tools). A claim is told to the agent that comes second:

A decision that is yours is a question on its own list, with the options, the one the agent recommends, and what answering it lets go ahead. You answer on the board, and the agent hears it with its next tool reply:

Hamloy follows the work through git on its own: the hamloy program's hooks see a branch merged on one computer and pushed from another, and the board says which state a task is in (git). Agents also message each other by task key, and are told when they edit a file another agent edited.

Where they overlap

Both give agents claims, a list of what's ready, tasks that wait on others, and a place to put what needs a person. Both work across branches and worktrees. The differences are where the list is kept, who can see it without a terminal, and whether you want it open source.

Moving between them

Hamloy exports a project as Markdown checklists (export, the Markdown files), and your agent brings work in from anything it can read (import). Beads keeps its issues in Dolt and can export JSONL, so a move either way is best done by asking your agent to read one and write the other.