An issue tracker for AI agents is not the same thing as one for your team

Two different things are being sold as an issue tracker for AI agents. One is a memory system your coding agent writes to dozens of times an hour and nobody else ever opens. The other is the board a designer, a founder and a support person all read on Monday. They are not competing products. They are separate jobs that happen to share a noun.

Most people arriving here are running an agent on a real project, watching it lose the thread between sessions, and wondering whether the fix is something they install or something they subscribe to. Usually it is both. The useful part is the line.

What an issue tracker for AI agents is actually for

Steve Yegge's account of building Beads states the problem cleanly. Agents boot with no memory of the last session: "It's the movie Memento in real life, or Fifty First Dates." His fix was to move the work out of markdown plans and into a tracker, and the design consequence he draws is the load-bearing one — "Dependencies are first-class, not prose" (steve-yegge.medium.com).

The detail worth pausing on is in the same post: "Half hour later I had 128 issues, six of them main epics, with five sub-epics." One person, thirty minutes, 128 rows. No human team files issues at that rate, and none could read them if it did.

That write volume is the design constraint, and you can watch it push on the tool. In October 2025 the launch post described Beads "writing the issues into git as JSONL lines". The README today describes something else: "Distributed graph issue tracker for AI agents, powered by Dolt", where the database is the backend and .beads/issues.jsonl is "an export for viewers and interchange, not the source of truth or a backup" (github.com/steveyegge/beads). It ships hash-based IDs so parallel agents on parallel branches do not collide, and a compaction pass that summarises old closed tasks to save context window. Those are not issue-tracker features. They are memory-system features.

Backlog.md takes the opposite bet on storage — "every task is a plain .md file in your repo", "no server, no account, no telemetry" — and states its reason in a line hard to improve on: "AI agents can now produce more plausible code in an hour than you can carefully read in a day. The bottleneck is no longer writing code. It's your attention." Hence three review checkpoints, and one task equals one context window equals one PR.

Where these win, with no hedging

For the job of keeping an agent oriented across sessions, Beads is a better answer than any hosted tracker, ours included. It is not close.

It models work as a graph with real blockers, so bd ready answers "what can I start now" instead of making the agent re-derive it from prose. It runs local by default — "Dolt runs in-process, data lives in .beads/embeddeddolt/" — so there is no service to sign into and no token to hand out, and moving the graph between machines is an explicit bd dolt push and bd dolt pull against your own git remote. It is MIT-licensed and free. Set that against the going rate for a team tracker — Linear's Basic plan is $10 per user per month billed yearly (linear.app/pricing) — and the case is not subtle.

Backlog.md wins a different axis outright: legibility of storage. A task is a markdown file, so a change to it reviews inside a pull request like any other diff. Nothing hosted matches that, and a JSONL export of a SQL database does not either.

The other job

Team state has a different reader: the person who did not do the work, does not have the repo, and needs to know something without asking anyone.

That reader changes every property you want. The record has to be reachable without a clone, permissioned so a contractor sees one board and not the codebase, and durable past the branch the work happened on. And it has to be short. A hundred and twenty-eight rows is an excellent day for an agent and an unreadable board for a person.

The counter-position, taken seriously

When Linear announced its agent products in March 2026, the sharpest reply on Hacker News made the maximal version of the argument: "I think a true AI agent would simply sidestep tools like Linear. Tools like Linear won't be needed" (news.ycombinator.com).

The strong form deserves stating rather than swatting away. If an agent holds the plan, the dependencies and the code, a board is a lossy projection of what it already has, and maintaining it is overhead. For the agent's own work that is correct, and it is why Beads exists.

Where it breaks is the readership. The tracker was never the agent's memory. It is the interface between people who cannot read each other's context — the support person who filed the bug, the designer who needs to know it shipped, the founder checking whether the thing promised on a call is done. Delete the board and that need does not disappear; it relocates to chat, where nobody can query it. Linear's own reply in the thread names it: customers "need a system of record" and "contextual collaboration".

The telling part is that an objection in the same thread arrives from exactly the opposite direction: "I use AI plenty, but I want it to stay far away from my issue tracker. To me that's a sacred space that can't be polluted by LLM noise." One person says the tracker is redundant now, the other says it is precious. Both are pointing at the same line. Agent scratch and team state should not share a store.

What earns a row a human will read

The rule we have settled on is checkable without any tooling:

A row belongs in the shared tracker if someone who did not do the work would decide differently after reading it. Everything else is scratchpad.

"Refactor the router helper because the fixture broke" is scratchpad. "The export endpoint is done and behind a flag" changes what someone else does next. The agent should write the second kind and keep the first to itself.

That implies a narrow connection, not a broad one. What an agent gets against a team tracker should let it record outcomes and ask questions, not file its own to-do list into the place people read. It is the difference between an agent that reports and an agent that dumps.

Which one fits you

If you are one or two people, everything is in one repo, and the problem is that your agent forgets what it was doing, install Beads or Backlog.md and stop reading. A hosted tracker adds nothing there and costs money. Same answer if nobody outside the repo needs to know anything.

If someone files or reads work but will never clone the repo, you need the second thing too, and the two are complementary rather than rival. A developer who ran Beads with Claude Code, then went and built his own smaller version of it, described the benefit plainly: "Giving an agent a task tracker helps a lot with focus and continuity" (news.ycombinator.com). Focus and continuity are properties of the agent's session, not of your team's week.

Kevta is one instance of the second job. It ships an MCP server on both plans, so an agent can file, move and comment through nine tools, using a token you can scope to a single board, expire and revoke (/docs/mcp). It has no offline or git-backed mode, and no importer or export today, which the app says on its own settings screen. If you want the task graph to live in the repo, Kevta is the wrong half of this comparison. What the shared half has to do for a small team is in what a five-person team needs from issue tracking; what changes in it once agents write most of the code is in an issue tracker for Claude Code.

If the shared half is the part you are missing, Kevta is in beta and you can join the waitlist.

Disclosure

We build the hosted kind, so this argues for a boundary that leaves us a job. Read it that way. The numbers being defended: Kevta Free is $0 with 2 workspaces, 5 boards per workspace and 10 members per workspace; Pro is $10 per workspace per month — not per person — with 10 workspaces, 10 boards and 50 members. Fifty is a real ceiling. Current figures are on the pricing page. Beads and Backlog.md are MIT-licensed and free; we have no relationship with either. Every competitor fact above was checked at the linked source on 3 August 2026, including Linear's published price, which is the kind of number that moves.