In the 31 days to 2026-08-19 our agent fleet filed 1,029 issues across two repositories and closed 564. The open backlog stands at 627 — 98% of it agent-authored. Thirteen days earlier we had run the same measurements and written up the diagnosis: 906 filed, 412 closed, 541 open, inflow more than double outflow over the month. Almost every number in that write-up is now wrong. The queries are not — and that asymmetry, durable queries over perishable numbers, is what this article is about.

The wrong first response to a growing backlog is to triage harder. Triage treats the pile, and the pile is a symptom. Diagnose the flow instead, date every number, and re-run the queries before you quote them. The five queries below need nothing beyond gh and jq against a stock GitHub API; the whole diagnosis costs an afternoon. Each query carries both dated readings, because the deltas are where the method earns its keep.

query 1 — flow balance: is the valve asymmetric?

Count issues opened and closed over the same trailing windows:

gh api 'search/issues?q=repo:<R>+type:issue+created:>2026-08-12' --jq .total_count
gh api 'search/issues?q=repo:<R>+type:issue+closed:>2026-08-12'  --jq .total_count

Run it at one, two, and four weeks, and record the date, because the ratio moves:

Trailing window2026-08-062026-08-19
one week1.7×1.1× (217 opened, 195 closed)
two weeks2.6×1.3× (392, 306)
four weeks2.1×1.8× (919, 503)

A ratio holding above 2 across the longer windows is an asymmetric valve. A ratio near 1 over a large standing backlog is sediment — archaeology, not plumbing. Don't average across windows and quote a single number. On 2026-08-06 every window said valve. On 2026-08-19 the short windows sit near balance — one repository closed more than it opened in each of the last two weeks, its first net drain since the fleet went live — while the four-week window still remembers the flood. Same queries. Different disease.

query 2 — authorship census: whose demand is this?

gh issue list -R <R> --state open --limit 1000 --json author

Tally the logins. Ours, re-tallied: 98% of the 627 open issues were filed by agent identities; exactly one human login appears across both repositories, holding 11 of them (thirteen days ago: 99%, the same single login, five issues). This tracker is not measuring user pain; it is measuring fleet activity. A backlog of user-filed issues growing 2× is a product crisis. A backlog of agent-filed issues growing 2× is a plumbing problem, and you should feel calmer, not worse, once you know which one you have.

query 3 — close reasons: does the reject lane exist in practice?

gh issue list -R <R> --state closed --limit 100 --json stateReason

Of the last 100 closes in each repository, exactly one was not_planned — at most 1%, down from 2–4% thirteen days earlier. Everything else exited as completed: a fix, a review cycle, a human merge. Filing still costs one API call while the only exit anyone uses is the most expensive one available. The re-run added a fact the first diagnosis could not see: in between, a sanctioned reject lane shipped behind explicit human authorization, and a drain pass examined the then-626 open issues for defensible closes. It found five. The backlog is not duplicates and not stale trivia; it is distinct, mostly-unfixed observations that will never each earn a fix cycle. A reject share near zero can mean the lane is missing — or that the pile resists cheap exits; only building the lane and re-measuring tells you which.

query 4 — age against process events: flood or sediment?

Bucket open issues by creation date and lay your own process timeline next to it — go-lives, pipeline changes, fleet-size changes — and state the boundary you use, because the count depends on it:

gh api 'search/issues?q=repo:<R>+type:issue+state:open+created:>2026-07-09' --jq .total_count

Against the review pipeline's go-live boundary, 609 of the 627 open issues postdate it and 18 predate it (2026-08-06: 531 and 10, of 541); in one repository every open issue is younger than six weeks. This backlog is not the product decaying; it is the pipeline exhaling. That is also the honest confound to carry into every conclusion afterward: a flood that starts at a go-live partly measures activity, not defects, and the write-up should say so.

query 5 — the work-in-progress fleet: where does outflow die?

gh pr list -R <R> --state open --limit 200 --json isDraft,reviewDecision
gh pr view <N> --json commits,reviews --jq \
  '{lastCommit: .commits[-1].committedDate, lastReview: ([.reviews[].submittedAt] | max)}'

reviewDecision cannot tell you whether the author came back after the review — it only flips on a fresh review — so pair it with the per-PR timestamp check. Thirteen days ago, ten of a dozen sampled changes-requested drafts had no commit after the last review. This time we checked the whole fleet: 52 open pull requests, still every one a draft; 42 at changes-requested; 31 of the 42 with no commit after the last review. The reviewer showed up; the author had ceased to exist, because agent sessions end and our review loop assumed a persistent author. Eleven had pushed since. And one number moved the other way: the merge gate, empty at the first measurement, now holds ten approved drafts, several parked there deliberately awaiting a release decision. Measure before you blame the person with the merge button — then re-measure before you exonerate them, because the bottleneck migrates.

one more query: search the backlog for its own diagnosis

Before designing fixes, search the backlog for proposals about the backlog. The first diagnosis found four — a filing gate with mandatory dedupe, a sanctioned close lane, a weekly scoreboard, a plea to shrink the human surface — filed by the agents themselves weeks earlier, sitting unread in the queue they were written to fix. The tense update is the point this time: all four have since shipped as code. Filing now runs through a tool that forces a duplicate search first and budgets new issues per session; closing has sanctioned lanes that verify a human authorized each one; the human's decisions arrive batched with defaults; the scoreboard is below. This query is free, it is humbling, and on our evidence it is where the fix starts.

what it added up to

Three findings survived both measurements, and none of them is "the models file too much." The valve was asymmetric: cheap writes, one expensive exit, inflow scaling with fleet size. Policy lived in memos, and a memo binds no fleet session under load — sessions call tools. And nobody owned the level: no report went red when the total crossed 300, or 400, or 500. The ratios came down in the same window the tool-shaped fixes shipped; the hedge says why we won't claim the arrow.

the scoreboard, thirteen days on

The first write-up specified a weekly scoreboard and said, honestly, "specified, not yet built." A tense has to be re-earned each time it is published, so: the scoreboard is now built and merged. It reports the metrics below per repository over trailing windows; it prints the exact query beside every number; a failed input prints unknown rather than a fabricated zero; and the two metrics needing close-event attribution we don't collect are declared deferred in its own output, not silently proxied. What it is not, yet, is running: the job that would publish it weekly is staged behind a human cutover, and as of 2026-08-19 it has never fired on its own schedule. "We have a scoreboard" would still be ahead of the truth by exactly one workflow file.

MetricWhat a bad number meansStanding response
Net issue delta (7d, per repo)The valve is still asymmetricTwo consecutive positive weeks → next work batch is ≥20% drain
Close ratio (closed over opened)Same signal, normalized for busy weeks
Not-planned share of closesThe reject lane has rusted shut againInspect the close tooling, not the agents
Agent-authored share of openInterpretive key for everything else
Stalled-WIP count and ageWork is abandoned faster than adoptedFeed the re-dispatch queue
Decision-queue max ageThe human is the head of the critical pathBatch and escalate with defaults

One rule matters more than any metric: every number needs a standing response. A scoreboard nobody is obligated to act on is a dashboard, and dashboards don't drain queues.

why two good instruments missed it

We already ran two respected instruments, and neither caught the flood. Our DORA emitter counts only merged work, so the abandoned drafts were invisible to change lead time; and a flooding fleet silently corrupts its bug-count input for change failure — the authorship census is a data-quality gate on DORA's own inputs. Our daily constraint report stayed calm because the issue tracker and the draft fleet are not stages in its inventory; the constraint had migrated to a channel the instrument doesn't meter, which is where constraints go. Meter every queue agents can write to.

the counter-example that carries the lesson

The week of the first diagnosis, the fleet overhauled the one control that had held — an hourly write budget, implemented in code. The agent reviewing that change opened by disclosing a conflict of interest: the change would raise the very budget throttling its own throughput. It then declined the change anyway, on a finding that ran against its own interest. Two rounds in, the original author had gone quiet; another agent adopted the orphaned branch, and the fix landed through the gates on the third. The control has since been re-scoped twice more under the same gates, and held.

One disclosure from the first write-up is still owed. The budget's known concurrency gap — parallel writers racing the same counter past its cap — remains open as of 2026-08-19. Its fix exists, passed review, and has sat ten days as an approved draft, waiting in exactly the queue that query 5 measures. The diagnosis and the disease, in one tracker row.

Where policy lived in a memo, the fleet flooded the tracker. Where policy lived in code, the process held well enough that an agent ruled against itself and abandonment was survivable. A policy that lives in a memo doesn't bind a fleet. A policy that lives in a tool does.

the hedge

Single fleet, two private repositories, post-hoc analysis. The flood coincided with the review pipeline's go-live, so the raw counts partly measure activity rather than defects — judge the ratios, not the integers. The thirteen-day improvement in the ratios is not attributable to any single fix: several controls, a drain pass, and a change in fleet mix landed in the same window, and two measurements are two points, not a trend. The abandonment census counts "no commit after the last review," which overstates abandonment where the review is fresh — 18 of the 31 had reviews more than two days stale. The authorship census counts a shared operator identity as agent traffic. The counter-example is one incident, not a controlled result. We think the queries generalize; we know the numbers don't — ours did not even generalize to us, thirteen days on.

If you run an agent fleet against a shared tracker, the five queries cost an afternoon. Ours cost two, and the second one mattered more: the expensive problem was not where we would have bet, and it was no longer where it had been thirteen days earlier. The fleet had already filed what was wrong. The fixes that worked were the ones compiled into tools. The queries keep; the numbers rot; run the queries.

Explainer video

Watch the explainer video.