An issue tracker records the work. Agents also need what the work has to satisfy.
A tracker is good at who is doing what and in what order. Once coding agents do the work, you also need the requirements and acceptance criteria each task must meet, kept as records the coding agent can't change, a check that a task is ready before an agent starts, and a way to decide done that doesn't depend on the agent's word.
Tickets, owners, priorities, states and history. A team of people can make a tracker and a good spec work, because people carry the context in their heads and ask when something is unclear.
Agents typically don't carry context between sessions, often don't ask unless told to, and tend to report their own work as finished. That's where gaps start to show.
What goes missing when agents do the work
What the ticket must satisfy. Acceptance criteria written in a ticket description can usually be rewritten by whoever edits the ticket, including the agent.
Whether the ticket is ready. A ticket can be picked up with open questions and missing criteria; the agent fills the gaps with guesses.
What else changes when a decision changes. In a typical tracker, nothing flags the tickets written against the old version of a requirement.
When it's done. Moving a ticket to Done is a status change, not evidence.
What you can do with the tools you have
Put requirement and criterion IDs in every ticket and every commit subject, so work can be traced back.
Write acceptance criteria before the agent starts, and treat them as read-only for the agent.
Keep a short checklist the ticket must pass before an agent picks it up: no open questions, criteria present, dependencies merged.
Close tickets from CI on the merged change, not by hand or by the agent's report.
Record decisions as their own items with an ID, and link tickets to them instead of restating them.
How Keel handles it
What an issue tracker did for teams of people, Keel does for coding agents: it keeps what each task must satisfy, and the links between them, in one record.
Requirements, acceptance criteria, rules, architecture decisions, tasks and defects are small versioned records with typed links. Tests must prove acceptance criteria held in Keel, which the coding agent can't change.
Before a coding agent starts, the server checks the task's requirement and design readiness and lists each missing item; a task that fails stays blocked.
When a requirement gets a new revision, the acceptance criteria and tests linked to it are marked for review, and the impact can be traced along the links.
A coding task is marked done by the server from the merged change and its CI verdict, not by an agent.
Your agents keep running where they already run and read the record through Keel's MCP server or command line; a CI reporting job runs in your pipeline. Keel doesn't decide how your agents work.
On a real system
DynoInvoice, an e-invoicing system for Singapore, is built by agents with Keel; its source is on GitHub for study.
As of 26 October 2026, Keel held 915 live tasks for DynoInvoice, 602 of them done. Only 58 existed when the requirements were imported in September; agents broke the requirements down into the rest, and each new task was examined before publication.
When the owner changed a core database rule on 12 October 2026, 16 reviewed changes amended the decision and the requirement and created or amended 22 tasks in about 46 minutes. Read how it went.
Questions
How is Keel different from an issue tracker with agents?
A tracker records the work. Keel also records what the work has to satisfy. Tasks link to the requirements and acceptance criteria they implement; before a coding agent starts, Keel checks the task's requirement and design readiness and lists anything missing; and a task is marked done from its merged change and CI verdict.
Can't I just put acceptance criteria in the ticket?
You can, and it helps. The gaps are that ticket text can usually be edited by anyone, including the agent; by default nothing checks a ticket is ready before work starts; and moving it to Done is a status change rather than evidence. In Keel the criteria are versioned records the coding agent can't change, and the server decides done from the merged change and CI.
Can I use Keel today?
Keel is open to a small group of design partners: engineering teams already building with coding agents. During the beta it's free, and we set up each team by hand. We ask for one real project and candid feedback.
Running agents off a backlog?
If that sounds like your team, apply to try Keel as a design partner. Beta access is free; we set up each team by hand and ask for one real project and candid feedback.