Issue Tracking for AI Agents: Why Agents Need a Tracker More Than You Do

Issue trackers were invented to compensate for human limitations: we forget details, we lose track of who owns what, we disagree about what “done” means. Coding agents have all of those limitations in a more extreme form. An agent's entire understanding of a task lives in its context window, and the context window ends. Ask a human engineer what they shipped last Tuesday and you get an answer; ask a fresh Claude Code session and you get nothing, unless the answer was written down somewhere durable.

Look at what an issue actually encodes, and it reads like a checklist of exactly the things a coding agent lacks on its own:

This is why teams that run agents seriously converge on tracker-shaped workflows even when they never adopted one for humans. The tracker is not process overhead for agents, it is the external memory and coordination layer they cannot provide for themselves. How you run the whole team around that layer is the subject of our guide to project management for AI agents.

The industry has noticed. The major human-first trackers have all added agent support over the past year, and a new category of trackers built for agents is emerging alongside them.

If you designed an issue tracker from scratch on the assumption that most assignees are machines, five requirements fall out. Together they are a reasonable definition of agent-native issue tracking:

1. 1

   Machine-readable acceptance criteria

   The issue body must be a spec, not a title. Scope, files in play, verifiable success conditions, explicit exclusions. A human assignee fills gaps with judgment and a quick Slack question; an agent fills them with guesses. The criteria are the agent's target function, so they have to be concrete enough to verify against.
2. 2

   A gate between planned and in progress

   With humans, “in progress” is a courtesy status. With agents it is the moment code starts being written at machine speed, so the transition needs a hard checkpoint: a human approves the plan before the agent moves the card. No agent-native tracker should let work start on an unapproved issue.
3. 3

   One branch or worktree per issue

   The tracker should own the mapping between issue and git isolation. Every issue gets its own branch or worktree at start time, automatically, so parallel agents can never collide and every diff traces back to exactly one issue.
4. 4

   Diff-linked status

   Status must derive from reality, not self-reporting. “In progress” should mean commits are landing on the issue's branch; “ready for review” should mean the diff exists and is attached to the card. Agents are unreliable narrators of their own progress; the diff is not.
5. 5

   Human review as a first-class column

   Review is not a checkbox on the way to done, it is where the human in the loop actually works. An agent-native tracker gives review its own column, with the diff, the original criteria, and the accept/reject decision in one place, because that column is the team's real bottleneck.

Measure any tool against these five and the retrofit gap is obvious: delegation-era trackers typically deliver ownership and history, but not spec-shaped issues, not the start gate, and not diff-linked status. Those three are where agent work goes wrong.

AIDEN's answer is to collapse the tracker and the execution environment into one surface. There is no separate issue database to sync: the story cards on the board are the issues, and the board runs the agents. Each story flows card → spec gate → agent → worktree → diff → PR, which maps onto the five requirements directly:

The board itself, and how it differs from dragging cards in Jira, is covered in AI kanban for developers; the spec format and approval flow in spec-driven AI development. And once the tracker is in place, the day-to-day question becomes how you hand work to agents well, which is its own craft: see how to assign tasks to AI agents.