An issue tracker for AI agents needs six things: a way to ask what's next, context the next session can use, decisions with their reasons, status changes that can fail, small searchable reads, and a record you can check. Most of the differences between tools come down to where the plan lives and who else needs to open it.
I build Frostbyte with coding agents, and they track that work in Frostbyte. To write this list, I counted what they did: 1,682 Frostbyte tool calls across 91 Claude Code sessions from 14 July to 3 November 2026, plus 141 calls from Codex. That's one founder and one project, using a tool I sell, so treat these as field notes.
What the agents did
These are the Claude Code calls:
update_task: 489get_task: 396list_tasks: 181task_log_decision: 112task_complete: 83create_task: 82task_start: 65
Only 19 calls returned an error. The Frostbyte plugin tells agents when to read tasks and log decisions, so these numbers show what they were told to do as much as what they'd choose on their own.
1. A way to ask what's next, with a reason
Without something to read, an agent asked what's next will answer from whatever it can see in the conversation. The tracker needs one read that returns a short ranked list and says why each item is on it. That read shouldn't change anything. Frostbyte's whats_next never assigns, starts or moves work.
My own evidence here is thin. whats_next is new and got 3 calls, so most sessions used list_tasks instead.
2. Context the next session can use
A new session knows nothing about the last one, so the task has to carry the handover. I keep two fields for this. The description says what we want and why, in my words. Agent context holds file paths, hypotheses, constraints and what's been ruled out. Agents wrote to agent context on 64 of 82 new tasks and in 114 later updates.
Keeping the fields apart means an agent can add detail without overwriting what you wrote. The cost is length, because the largest task an agent read ran to 11,300 characters.
3. Decisions with their reasons
Code shows what was chosen. It rarely shows what was rejected, or why. My agents logged 112 decisions across 57 tasks. One reads: "Founder Reply-To reads FOUNDER_REPLY_TO and stays unset until the thomas@ alias exists, so replies keep reaching support@ instead of bouncing."
History matters as much as the latest answer. On one task, Codex recorded my choice to approve public submissions individually on 26 October. A few hours later, Claude Code recorded the change: posts stay public on arrival, with a switch to hide each one. Anyone reading that task can see what changed and when.
A tool can ask for the reason outright. When we tested Backlog.md, all four runs recorded the choice, but only one kept the reason on the task. It's a small test, and our tool asks for exactly what we scored, so it leans our way.
4. Status changes that can fail
Status writes should be able to refuse. When an agent tried to start a task that was already in progress, Frostbyte returned "Task is already in-progress." That happened twice, and a tracker that accepts every write would have hidden it.
Agents also need a proper way to stop. On FB-259, an agent couldn't reproduce a bug, so it changed no code and recorded a blocker listing the paths it had tried and the three things it needed from me.
We haven't solved when a task counts as done. I usually close work on merge and sometimes earlier, and agents connected through plain MCP get no rule from us about it yet. Whichever tool you use, write your rule down where the agent will read it.
5. Small reads you can search
Agents find tasks by words. 116 of 181 list_tasks calls used a search term, while 9 filtered by release and 10 by area. So keep lists short and fetch detail on demand. A typical list came back at about 350 characters and a typical full task at about 1,500, though the largest list hit 15,582.
Lookups also need to accept what people say. This was our own weak spot. Nine of the 19 errors came from an agent passing a task number like FB-360 to a tool that wanted the internal ID, so our task tools now accept the number too.
6. A record you can check, and writes you control
You should be able to review the work on the task, without rereading the chat. All 83 completions carried a summary and 49 listed the files touched. Agent comments are marked as agent comments and often name the client, such as codex or claude-code.
Check how writes are controlled too. Claude Code's auto mode blocked four of my update_task calls as external writes. Your agent's permissions sit on top of the tracker's, so try a write early, and check that the token can only reach what you can.
Using one with Codex
The setup is the same idea with different files. Codex reads AGENTS.md before it starts work and takes MCP servers from ~/.codex/config.toml or codex mcp add. AGENTS.md is a good place for how you work and a poor place for current status, because it goes stale as soon as the plan moves. OpenAI's docs suggest adding a snippet to AGENTS.md so Codex reliably uses an MCP server, and the same approach fits a tracker:
Before starting work, read the task in Frostbyte. Log decisions with their reasons on the task. When you finish, add a summary and the files you touched.
I haven't compared Codex with and without those lines. In Frostbyte, Claude Code's plugin names the project as the session starts, while in Codex the plugin's guidance reads the link file when work begins.
My Codex numbers are small. Frostbyte was called in 6 of about 125 Codex sessions on this repo, all on 26 and 27 October: 58 get_task calls, 19 list_tasks, 15 update_task, 4 decisions and 1 completion. That's mostly reading over two days, so it doesn't tell you how Codex behaves through a long build.
When a repo tool is the better choice
If the plan only has to serve you, your agent and your repo, a repo tool may be all you need.
Backlog.md keeps tasks as Markdown files in your repo. It's free under MIT, needs no account, and has a local web board, a CLI and MCP. Pick it if you want the plan in git history and on your branches. We've tested it, and if you have no outside users, I'd tell you to stay on it.
Beads is built around a dependency graph. bd ready lists work with no open blockers, agents claim tasks, and hash IDs avoid merge collisions across branches. Pick it if you run several agents at once on work with real dependencies. Frostbyte's blockers are a written reason on a task, with no dependency graph. We've since run Beads through our two-session test. The agent read the plan with no setup from us, but the reason for its choice didn't reach the task.
A hosted tracker makes more sense when someone without the repo needs the plan: a teammate, a contractor, or users asking for things. It also helps when one plan spans several repos. If you already use Linear or GitHub Issues and they connect to your agent, run the test below before you move.
A test you can run on any tracker
Connect the tool, add a few real tasks, then try this:
- Start a new session and ask "what's next, and why?" Check that the answer comes from a record.
- Have the agent start a task, make one choice and finish. Look for the reason on the task.
- Start another new session and ask why that choice was made. It should quote the record, without inferring from the code.
- Ask it to open a task using the number you'd say out loud.
- Open the task yourself and see whether you can review the work without the chat.
Where Frostbyte fits
Frostbyte is the hosted option. You and your agent share one plan, with What's Next, decision logging and a link your teammates can open. Agents connect on every plan, Free included, through the Claude Code or Codex plugin or any MCP client. If you want the plan in git, use one of the repo tools above.
