Every Ticket My Agents Filed Looked Like Diligence

Good news: we found more things to do. Bad news: we were supposed to be finishing things.

- Every status meeting, eventually

Last week I described how I run a fleet on a client's platform. One Claude Code session plans and briefs, and several stream sessions each own a ticket end to end.

This post is the question that one left open: did it work? For a while, no. The fleet wrote good code and the queue got longer.

The Number That Wouldn't Move

In early September I measured how many tickets the fleet filed for every pull request it merged. The answer was 0.9.

It wasn't a bad week. Across two fully tagged weeks the rate held flat: 0.87, then 0.92. A flat rate doesn't run out. After three weeks of work aimed squarely at the ticket queue, the queue was bigger than when I started.

About 26 percent of open tickets carried the tag that marks them as agent-generated. That's a floor, because the tag only existed from August 20.

What I wrote at the time:

"I have spent multiple weeks working toward a goal that is now further away than when I started."

The first fix made it worse. On September 3, four streams ran a new written process for the first time. They closed 2 tickets and filed 3.

Why Every Filing Looked Right

None of those tickets was wrong on its face. A stream finds a real problem next to the one it was sent to fix. It writes a careful ticket with the file, the symptom and a suggested fix. That looks like diligence. From inside the session, filing always does.

From outside, each one is a cost. Someone has to read it, triage it, reload the context, cut a branch, review a change and run CI. Sometimes the fix was smaller than the ticket describing it.

Worse were the tickets that weren't work at all. A ticket that boils down to "should we do A or B?" is a question for me. Filed, it sits in the queue looking like a work item, when the answer would have taken me a few minutes in the session.

So the agents weren't failing. They were following an incentive I'd never pointed anywhere else.

A Constraint, Not a Target

Three weeks of targets had produced 0.9. So the new rule is a constraint:

A stream may not end with more tickets filed than closed.

There are three ways to satisfy it: fix the problem, ask a person, or prove it's blocked. There is no fourth way. A stream must never drop a real problem to make the number look good. That's suppression, and it's worse than filing.

For each finding, in order:

1. Know the fix, and it's in scope of the pull request? Fix it, even if it isn't the bug you were sent for. A small fix in a file you already have open costs less than a ticket.
2. Needs a design decision? Ask. A decision filed as a ticket is minutes of judgment dressed up as work.
3. Required to finish work you hold? File it. The cap applies to findings, never to scope. Capping your own remaining work isn't discipline. It's hiding it.

Every stream's EXIT note, the report it writes before saying it's done, now carries four numbers: tickets closed, tickets filed, items deferred to an open ticket, and items deferred with no home. The last one must be zero.

The test for that last number is one sentence: name the ticket that can't close if this is forgotten. If you can name it, a comment on that ticket is enough. If you can't, the item has no home, and it needs a ticket.

As I wrote last week, a rule left out of the prompt doesn't happen. This one goes in every brief.

Two Levers

Two levers, both measured on a single day. Treat them as what happened on the day we measured, not as a trend.

What you assign a stream to do. Some streams were assigned to score existing tickets: is this already done? Those went −2 each. Streams assigned to build went +1 and +2, while doing excellent engineering. A queue that's been growing for weeks is full of work already finished that nobody has checked. Checking it is cheap, and each one it confirms comes off the queue.

Check the fix size before endorsing a filing. When a stream proposed a ticket, looking at the size of the fix first paid off. One proposed ticket turned out to be a single AND organization_id = $1 in a file the stream already had open. That's not a ticket. That's a line.

If you've read Refute, Don't Review, the second lever will look familiar. "This needs its own ticket" is a claim like any other, and it's cheaper to test than to trust.

The Numbers Since

Over five weeks, 76 streams closed 265 tickets and filed 120.

Treat those as approximate, about plus or minus 5 percent. The counts are self-reported. Some tickets were closed in more than one stream. "Closed" includes duplicates and cancellations. And the last week leaves out five streams that were still running.

Here's the weekly view, measured as tickets filed for every ticket closed. That's a different measure from the 0.9 above, which counted filings per merged pull request, so don't compare the two directly.

It isn't a clean downward line. Mid-September was the worst week of the five: 19 streams closed 44 tickets and filed 37. The rule existed by then. It didn't stop that week. The week before is too small to read much into, with three streams.

The last two weeks look different. In the most recent week, 18 streams closed 92 tickets and filed 20.

The open queue tells the same story from the other side. Leaving out tickets that are on hold or deferred, the daily snapshots were:

• Sep 28: 315
• Sep 29: 311
• Sep 30: 293
• Oct 1: 299
• Oct 2: 274

The rise on October 1 came from new work: our product group delivered a new screen design, which arrived as a single epic with several sub-tickets.

On the day ending October 2, the streams closed 32 tickets and filed 5. The orchestrator closed 3 and filed 6, and I approved each of those six. In total: 35 closed, 11 filed.

Then a refute pass, a fresh agent told to prove each close wrong, reopened 12 of those closes. Every one was re-closed or given a home. That's the check working. A ratio built on closes nobody verified would just be a nicer-looking number.

The Solo Version

You don't need a fleet for any of this. If you use one AI session on your own backlog, the same incentive applies. Every finding it hands you looks like diligence.

• Count both directions. At the end of a session, write down what closed and what got filed. You can't manage a ratio you never look at.
• Make it a constraint, not a goal. "Don't end with more than you started" is clearer than "try to reduce the backlog."
• Fix, ask, or file, in that order. If the fix is small and in a file you already have open, it's cheaper than the ticket. If it's a decision, decide it now.
• Never buy the number by dropping problems. A finding you ignore to look good is worse than one you file.
• Spend a session on scoring. Ask the AI which open tickets are already done, then have a fresh one prove each "done" wrong before you close anything.

The agents were never the problem. They did what the incentive rewarded, and filing always looks like work. The rule changed what counted.