The Issues Our AI Agents Filed That Nobody Asked For

An AI-generated backlog fills up faster than anyone expects. We found 140 new issues in the tracker of our own AI configuration repository, all sharing one identical body, none describing real work. Nobody had asked for any of them. That incident was easy to clean up, but it pointed at a pattern I have since seen in subtler forms: a system that is allowed to create work will create it, and a good share of what it creates is work nobody needs. This post is about how we stopped our agents from filling the backlog with it, and what that took.

The Failure You Can See

The cause of the 140 was ordinary. A test run filed its placeholder issues into the production tracker instead of somewhere disposable. Failures like this are embarrassing for a day and then mostly harmless, because anyone looking at the board can see them, and they leave a clear fingerprint: a run of adjacent issues that all carry the same body.

We turned that fingerprint into a rule and a daily check. Our coding agent now carries a rule against leaving scaffolding in a live tracker, and an automated check looks for the pattern every day. The check only reports. The remedy is to close the residue, never to delete it, so the tracker keeps an honest record of what happened.

Work That Looks Real

The harder problem looked nothing like the 140. A single overnight run, sent to deliver other work, filed 86 issues about components it was not working on. When we re-scored the 71 that were still open and that nobody had picked up, we kept 37 and closed 34. Every one of the 34 had passed our filing rules, and after analysis none of them would have improved the solution’s performance, quality or security. Volume like that is not efficiency. Each issue still needs a person to review it, and even with AI support that review takes time away from work that matters.

Two patterns ran through what we closed. The first was findings about conditions that never occur in real use, such as a security weakness an attacker could reach only through a sequence of events the system does not allow, or a defect in a code path nothing calls. The second did more harm. When one component sent something unexpected, the agent filed issues asking the component that received it to tolerate, detect or work around the bad input. Building those would have masked the real fault and lowered the quality of the code, because the problem stays in the sender and every receiver grows workarounds for it. We always fix the fault where it starts, in the sender.

Why the Old Rules Let It Through

I wrote about our filing rules in The Three Doors AI Agent Authority Cannot Open. They asked an agent to name which kind of consequence a finding had before filing it, from a list of four. What they never asked was how much. One of the four, “blocks or wastes delivery”, could not fail in this repository, because the repository’s subject is the delivery system itself, so any defect in it can truthfully claim to waste delivery. That single category carried 107 of the 248 issues our runs had ever filed.

The weak rule had a weaker check behind it. An unattended run could grant its own issues readiness to be built, and the orchestrator then re-checked that grant before building. Our own documentation called this “the only arms-length check between a self-authored bug and an unattended build.” In practice, one unit found a problem, classified it, filed it and approved it in a single context, and then another machine re-checked that unit’s own claim. No person was in that loop, and the mechanism was spread across about twenty files. Asking the run to cite better evidence would have changed none of that, because the 34 closed issues had cited evidence too. The rule was in the wrong place.

One Gate, Where the Issue Is Born

We moved the rule to the one place every issue has to pass: the guarded path that writes to GitHub. It admits three kinds of consequence and no others. The finding broke something, it contradicts the plan, or it is a security or correctness hole someone can actually reach. Each claim needs a citation of something that has already happened, which removes the hypothetical findings at the door. A bug is also refused unless it names the change that restores intended behavior, and in my experience that requirement is what moves the work back to the source: the change that restores intended behavior is almost always in the component that broke it.

The self-approval and its downstream re-checks came out in the same delivery as the new gate. We would not split the two, because a window with a gate at neither end would have been worse than either the old system or the new one. The step that places a bug into its delivery lane now receives the issue’s labels and nothing else, so it cannot treat an issue differently because a machine filed it. That rule lives in the code itself rather than in a policy someone has to remember. Who filed an issue is still visible in GitHub, as it is for everything our agents do under their own identities. It simply no longer decides anything.

What the Gate Does Not Do

I want to be careful about what this change claims. Our decision record says it directly: the change “does not create human review where there was none, and claims none.” The mechanical half of the rule is enforced in code. The judgment half, whether a citation is real and whether a proposed fix truly restores intended behavior, is not. We also looked at putting a person in the loop at filing time and rejected it, because it would make the operator the bottleneck for every finding an unattended run produces.

There is a second choice behind the gate, and it is deliberate. Our delivery architecture now says that a finding an agent raises becomes an issue only above the materiality bar; below it, the agent files nothing and keeps nothing in a side file. That is how quality stays up. A real defect still reaches the backlog, because it can cite something that broke and name the fix, and the team spends its time on changes that improve the code instead of on triaging findings that would never change it. The bar applies to our agents, and only to them. Anyone on the team who sees something worth improving adds it to the backlog, and we want them to. Their judgment about what matters is exactly what the gate protects room for. The same thinking runs through the five steps of our AI delivery pipeline: the machine does the volume, and the gates decide what is allowed to count.

If your agents can already open issues, tickets or tasks in a system your team relies on, look at what they filed last month and ask how much of it anyone would choose to build. If the answer worries you, put the rule at the point where the work is created, make it cite something that already happened, and send every fix to the source. If you want to compare notes on setting that up in your own delivery, contact us at A-CX.