Agents that cannot tell which task store is authoritative start a new one. How duplicate backlogs happen in agent-heavy repos, and the resolve-before-touching rule that stops them.
A backlog is only useful if every agent working against a repository agrees it is the backlog. That sounds too obvious to need saying, until you run enough parallel agents against enough working trees and watch it fail in a specific, repeatable way: an agent starts a task, looks for wherever the project keeps its list of work, does not immediately find one it recognises as authoritative, and, because doing something is easier to justify than stopping to ask, creates a new one. Now there are two backlogs, and neither agent that touches the repo next has any principled way to know which one is real.
The conditions that produce this are mundane. A working tree checked out from an older commit does not yet have the backlog file a newer commit added. A task store scoped to one directory gets confused with a project-wide one sitting a few levels up. A tool that tracks tasks by working directory reports no tasks found when it is actually just looking in the wrong place, and an agent reads that empty result as ‘there is no backlog yet’ rather than ‘I have not found the real one’. Every one of these is a search failure dressed up as an absence, and an agent that cannot tell the difference resolves the ambiguity by creating rather than by escalating.
Once two backlogs exist, they do not stay in sync, because nothing is keeping them in sync, they are just two files or two stores that happen to describe overlapping work. Tasks get marked done in one and not the other. New work gets filed into whichever one the agent that filed it happened to find, which is often a coin flip determined by which directory it started in. Within a few cycles neither backlog is a complete or trustworthy picture of what is actually outstanding, and reconciling them after the fact means diffing two lists of prose descriptions against each other and guessing which pairs refer to the same task.
The rule that actually prevents this is not ‘write better search logic’, though that helps. It is a resolve-before-touching discipline: before an agent creates any new task entry, it has to positively confirm which store is authoritative for the repository it is in, not merely fail to find one and assume the field is clear. That confirmation might be a fixed, well-known path checked first every time, or a marker file that names the canonical location, or simply asking rather than guessing when the search comes back empty. The specific mechanism matters less than the requirement that absence of a found backlog is treated as an open question, never as permission to start a second one.
This gets harder, not easier, in a repo with multiple working trees and multiple task-id namespaces in play at once, because the same short id can legitimately mean two different tasks in two different trees, and a naive check for whether this id already exists gives a false negative if it only looks in the current tree. The check has to be scoped to what the tooling actually considers authoritative, the real backlog for that repo, wherever it canonically lives, not to whatever the current working directory happens to contain.
What I do now is treat ‘I could not find the backlog’ as a stop condition, not a green light. An agent that reaches that point reports it and waits, rather than quietly filing a new list that will look, to the next agent, exactly as authoritative as the real one. The extra friction of occasionally having to answer ‘where is the actual backlog’ is far cheaper than reconciling two divergent ones after a week of parallel work has been filed into each.
A backlog’s value is entirely a function of everyone agreeing that it is singular. A backlog that might have a sibling is not degraded, it is worthless, because nobody reading it, human or agent, can trust that it describes the whole of what is outstanding rather than half of it.