What to look for in an agent-native project tracker
Stefan-Iulian Tesoi · · 7 min read
Four things: an agent can fetch work without a person copying text into a prompt, items carry the fields an agent cannot infer, returned work is checked against criteria written before the work started, and a person still decides what is done. Everything past those four is preference.
The phrase agent-native project tracker is new enough that it is mostly used as a badge, so it is worth being concrete about what it would have to mean. The four above are testable in an afternoon, which is the only useful property a definition in this category can have.
What makes an agent-native project tracker different?
Where the specification lives. In a conventional tool it lives partly in the item and partly in the heads of the people who discussed it. In an agent-native one, the item is the whole of it, because nothing else is available at the moment the work starts.
Everything else follows from that. If the item is the whole specification, the system has to care whether it is complete, which means fields rather than prose conventions. If the agent cannot ask a follow-up question, the handover has to carry context the agent would otherwise have asked for. If nobody is present when the work finishes, something has to check the result before a person is asked to look.
The test is not whether an agent can reach your backlog. It is whether what it reaches is sufficient. Access was solved a while ago; sufficiency was not.
Which four capabilities actually matter?
Each has a tell you can check yourself, without a demo.
| Capability | The tell | Without it |
|---|---|---|
| Agent-readable handover | An agent fetches the next item and its context in one call | Someone pastes the ticket into a prompt, and edits it while pasting |
| Required specification fields | Acceptance criteria are a field, countable and returnable | Criteria live in a text box by convention, and decay |
| Verification on return | Returned work is checked against the criteria before review | Review is the first and only gate, and it is a person |
| A human decision to close | An agent can reach review and no further | Status becomes a claim, and the board drifts from the repository |
The second is the one teams underrate. A backlog tool for coding agents that stores criteria as free text has not stored criteria; it has stored a paragraph that usually contains some. The difference shows up the first time you want to ask which criterion a change satisfied, and cannot.
The fourth sounds like a limitation and is the point. Work that closes itself removes the only checkpoint where a person compares what was asked for against what arrived.
Why is an AI feature not an agent-native design?
Because the features being added sit on top of the same data model, and the data model is the constraint. An assistant that summarises an item, suggests labels or drafts a description is operating on the item after it exists, with no more information than the item has.
This is not a criticism of those features. Summarisation genuinely helps a person catching up on a thread. It does not change what an agent receives when it asks for work.
The clearest version of the distinction is in the tool surface. Trackers ship MCP servers now — GitHub's official MCP server is a real, maintained example, and Atlassian and Linear have their own. Read the tools such a server exposes and you mostly find CRUD on the existing objects: create an issue, get an issue, update an issue, list issues. That is a faithful integration with the data model underneath, and the agent ends up holding the same thin item a person would have held.
Compare that to a surface organised by workflow rather than by entity. Laimonade's connector exposes 39 tools and 4 resources, grouped as finding work, understanding before editing, creating backlog items, moving work through the board, and reporting back. The grouping is the design: an agent asks for the next ready item and receives criteria, epic context and the repositories to touch, then reports back with what it ran. What the connector covers is in integrations, and the shape of the system around it is in what Laimonade is.
None of that requires the agent to act unsupervised. It carries work to review; a person decides what is done.
Which features turn out not to matter?
Most of the ones that demo well. Each of these is pleasant and none of them changes whether an agent can execute your backlog.
- AI-generated descriptions and summaries. A fluent paragraph generated from a thin item is a thin item that reads better. The missing information was missing before the model saw it.
- Automatic estimation. Points predicted from a title predict how the title was phrased. An estimate on an unspecified item is a confident number about an unknown quantity.
- Natural-language search. Useful for people, irrelevant to an agent that was handed its item rather than looking for one.
- Auto-triage and labelling. Saves a few seconds each, on a task that was never the bottleneck. Labels are for filtering, and filtering is not what is slow.
- A chat interface over the backlog. Impressive in a demo and rarely the shape of the work. The failure mode of an AI project management tool is that the chat produces decisions nobody writes down, which is the pre-existing problem with a nicer interface.
- Dashboards. Worth exactly what the underlying records are worth, and no more.
The pattern is consistent: these features assume the item is adequate and make handling it faster. The problem worth paying to solve is that the item is not adequate. Which questions to put to a vendor about that is the subject of Jira alternatives when an agent reads your backlog.
How do you run a two-week trial that tells you something?
Do not migrate anything. Run one team's next two weeks in parallel, with ten items, and measure two numbers.
- Pick ten items you already consider ready. Do not rewrite them for the trial. Rewriting them is the experiment leaking: you would be testing a backlog you do not normally have.
- Hand each to an agent through the tool's own handover. No copying into a prompt. If a person has to paste, the first capability is absent and the trial has already answered its main question.
- Count how many executed without a human editing the item first. This is the number. Everything else in a trial is atmosphere.
- Count how many came back needing a specification fix rather than a code fix. That ratio measures whether the tool improved the items or merely moved them, and it is the one a vendor cannot stage.
- Time one person for one week. Hours spent on project management for AI agents — grooming, clarifying, re-explaining — is the cost the tool is supposed to reduce, and it is the honest denominator for whatever it costs on the pricing page.
Two weeks is short enough to be real and long enough to reach the second sprint, where the first one's shortcuts surface. A trial that runs one sprint measures the enthusiasm of whoever ran it.
Frequently asked questions
Is an MCP server enough on its own?
No, though it is necessary. An MCP server determines whether an agent can reach your backlog; it says nothing about whether what it reaches is executable. A connector exposing create, read and update on thin items gives an agent reliable access to insufficient specifications. Read the tool list before treating the presence of a server as an answer.
Does the tracker need to read your repository?
Not necessarily, but it needs to accept what came back from one. The useful link is inbound: commits, test commands and exit codes arriving against the item, so status reflects something that happened rather than a button someone pressed. A tracker that reads code and still closes items on a click has the integration pointing the wrong way.
What should a trial measure?
How many items an agent executed without a person editing them first, and how much of the rework was caused by the item rather than the code. Both are countable in two weeks. Velocity, time saved and satisfaction are not measurable that fast and will reflect novelty more than the tool.
Can an existing tracker be made agent-native?
Partly. Required fields, templates and automation can force acceptance criteria to exist, which is most of the second capability. What does not retrofit is verification on return and a handover shaped as a work order, because both need the system to have an opinion about whether work meets its criteria. Enforced structure is achievable; enforced sufficiency is the harder half.