A backlog an agent can actually read
Stefan-Iulian Tesoi · · 7 min read
Four things stop an agent working from a normal backlog, and none of them looks like a defect: the repository nobody names, the acceptance criterion that cannot be satisfied in the order it is sequenced, the status that disagrees with the code, and the item that is really six items.
Most backlog items are written for someone who already has the context. That is fine when the reader sits next to you. It breaks when the reader is an agent that has only the text.
What is an agent-ready backlog?
An agent-ready backlog is not a better-written backlog. It is a backlog whose items do not depend on anything the reader is assumed to already know — repository named, acceptance criteria checkable, dependencies sequenced.
That is a narrower test than backlog quality in the usual sense. INVEST, the twenty-year-old checklist for a good user story, asks whether an item is independent, negotiable, valuable, estimable, small and testable. Every one of those still applies. What none of them asks is whether a reader with no memory of the planning conversation could act on the item, which is the test that changed when the reader did.
That distinction is easy to miss because the assumed knowledge is invisible to the people who have it. A team of five who have worked together for a year share thousands of small facts: which service owns which table, what "the app" means, which of two similar-looking flags is the live one. None of that is written down, because writing it down would be insulting to the only people who ever read it.
Hand the same items to something with no memory of the last standup and the gaps become the whole story. Here are the four we keep running into. None of them looks like a defect. Each one reads as an ordinary ticket.
1. The unstated repository
An item says "add a blog section". The team has five repositories, and the answer is the one nobody mentions in planning because everyone knows it. An agent has to guess, and guessing wrong means building the feature in the wrong application.
The fix costs one field. The failure costs a whole implementation.
What makes this one worth naming separately is that it is not ambiguity in the requirement — the requirement is perfectly clear. It is ambiguity in the target, which no amount of rewriting the description will fix. A team can describe a feature beautifully and still not say where it goes.
2. The circular acceptance criterion
An item requires its output to appear in something that does not exist yet — and the item that would create it is sequenced after this one, on the reasonable grounds that there is no point building it before there is content.
Both items are individually sensible. Together they cannot both be satisfied, and the symptom is an unfinished checkbox rather than a planning error.
An agent handles this worse than a person does, and not because it is less capable. A person hitting a circular dependency stops and asks. An agent with a definition of done it cannot satisfy will keep going: it will build something adjacent, mark the criterion as blocked, or satisfy the letter of the requirement in a way nobody wanted. All three outcomes cost more than the question would have.
3. The status that disagrees with the code
An item is marked done. The code does not support the claim. This happens more than anyone expects, and it is corrosive in both directions: work gets redone because nobody trusts "done", or work gets skipped because the board says it shipped.
A commit message is a claim. The file is the evidence.
The reason it persists is that nothing in a normal tracker ever compares the two. Status is set by whoever finished working, and finishing feels the same whether the criteria were met or merely approached. There is no moment in the process where a machine reads the diff and asks whether it does what the item said.
4. The item that is really six items
Any item whose description contains a list of distinct deliverables is not one item. We recently split a thirteen-point story into six children and the children came to twenty-six points — the estimate was not slightly wrong, it was wrong by a factor of two, and nothing about the original item revealed that.
That factor is the part worth keeping. Underspecified items do not produce estimates that are a bit optimistic; they produce estimates that are wrong by multiples, because the missing work was never visible to count.
What do all four have in common?
None of these are found by reading the backlog. They are found by trying to implement from it, which is exactly the moment they are most expensive to discover.
| Failure mode | How it reads | What it actually is |
|---|---|---|
| Unstated repository | A clear requirement | An unclear target |
| Circular criterion | An unfinished checkbox | A sequencing error |
| Status vs code | A completed item | An unverified claim |
| Six items in one | A large story | Four hidden stories |
All four share a shape: the item is readable and not executable. Writing tickets for AI agents is mostly a matter of closing that gap, item by item. A person reading it understands what is wanted. Something trying to act on it cannot proceed. Review catches unreadable items, because a reviewer notices when they do not understand a sentence. Review does not catch unexecutable ones, because understanding a sentence and being able to act on it are different tests, and only one of them gets run.
How do you find these before an agent does?
Take the next twenty items and, for each, answer four questions from the text alone. No asking anyone, no opening another tab:
- Which repository? Not which service or which area — which checkout.
- What observable outcome? Something a person could look at and agree had happened.
- What would prove it? A command to run, a request to make, a screen to open.
- What must exist first? And is that thing sequenced before this item or after it?
Anything you cannot answer without asking someone is the defect, and the item is where it lives. Score it: count how many of the twenty pass all four. On the backlogs we have audited, the first pass is usually between a third and a half, which is a shock the first time and the entire reason this post exists.
Then repeat the count next month, because the number is only useful as a trend. A single measurement tells you the backlog is worse than you thought. Two tell you whether anything you changed helped.
That is the argument for auditing a backlog before pointing agents at it, and for treating everything an implementation attempt reveals as evidence worth keeping. Laimonade exists because these four kept coming back on our own backlog first. It is also most of what an AI Product Owner actually does — the work is not writing prose, it is closing these four gaps on every item, every week, without getting bored on the fortieth one. The sprint workflow covers how that lands in a week, and the engineering leader's view covers what it changes for whoever holds the team.
Frequently asked questions
Are these defects a sign of a badly run team?
No, and that is why they survive. Every one of them is the natural result of writing for a reader who shares your context, which is the correct thing to do when that reader is a colleague. The defects only become defects when the reader changes. A team that had never adopted coding agents could carry all four indefinitely and ship perfectly well.
Can a coding agent spot them itself?
Partly, and the part it misses is the dangerous one. An agent can usually tell that a repository was not named, because the absence is local to the text. It cannot tell that a criterion is circular, because that requires reading the item that was sequenced after this one. Detecting the second kind means looking at the backlog as a whole rather than one item at a time.
How often should a backlog be audited?
The next twenty items, weekly, is the cadence that has held up for us. A full-backlog audit sounds more thorough and is worse in practice: it takes long enough that it happens once, produces a list nobody works through, and describes items that will be re-scoped before anyone reaches them. Twenty items is an hour and covers what you are about to build.
Does fixing these slow the team down?
It moves the cost rather than adding it. The four questions take a few minutes per item; discovering the same gaps through a failed implementation takes a day and produces a rebuilt feature. What does change is where the time sits: before the work rather than during it, which feels slower to anyone watching the board and is not.