Astro Took Its Open Issue Count Down 85% With Agents Running in GitHub Actions. The Transferable Part Is the Label State Machine, Not the Agents.
On August 4, Cloudflare published how the Astro maintainers cut the project's open GitHub issue count by 85% using isolated AI subagents running in GitHub Actions, orchestrated by an open-source framework they call Flue. The New Stack reported Astro was down to roughly 20 open issues from more than 200 at the start of the year, heading to zero for the first time in five years.
I run this blog on Astro, so I read that as a user of the project before I read it as a technique. And the technique underneath is more interesting than the headline number, because the part that transfers to a one-person repo has nothing to do with agents.
What they actually built
The pipeline has four stages, each handled by a separate agent: reproduce the bug in a sandbox, diagnose the root cause, verify it is actually a bug, and attempt a fix. Each stage runs isolated in GitHub Actions. The whole thing is driven by a state machine encoded in GitHub labels.
Read that last sentence again, because it is the design decision the post is really about. The state does not live in a database, a queue, or the agent's context window. It lives in labels on the issue, which are visible in the GitHub UI, editable by a human with two clicks, and durable across every crash, timeout and rate limit the agents will inevitably hit.
That means every stage is resumable, every stage is auditable, and a human can override any transition by changing a label. The agents are workers pulling from a queue whose state is public. If you deleted every agent tomorrow, the labels would still describe exactly where each issue sits in the process, and a human could keep working the same pipeline by hand.
Why the 85% is less useful than it looks
Astro's issue backlog is unusually well-suited to this. It is a build tool with a large user base filing bugs about deterministic behaviour, most of which can be reproduced from a minimal repo in a sandbox. Reproduction is the expensive, boring, mechanical step, and it is exactly the step an agent in a container can do at 3am.
Your backlog is probably not that. My open issues, such as they are, look like "the RSS feed renders wrong in one reader I do not own" and "a build failed once in March and I never found out why." Neither is reproducible in a sandbox. An agent pointed at those would burn tokens confirming it cannot reproduce them, which I could have told it for free.
So the number is real and it does not transfer. What transfers is the observation that made the number possible, which is that most of the work in a bug backlog is not fixing bugs. It is triage: deciding whether a thing is real, whether it is reproducible, and what it actually is. Astro automated triage. The fixes were the smaller half.
The part I would copy this weekend
Encode your triage as labels, then work the labels. No agents required.
The stages Astro used generalise almost unchanged. Something arrives and it is unverified. Someone establishes whether it reproduces. If it does, someone works out what is actually causing it. Then someone attempts a fix. Four states, four labels, and an issue is always in exactly one of them.
The reason this is worth doing solo is not throughput, it is context switching. The cost of a 40-issue backlog for one person is not the fixing. It is that every time you open the list you re-derive, for each issue, what you already know about it and what the next action is. That re-derivation is the tax, and you pay it every single time you look. A label that says needs-repro versus root-cause-known collapses that to a glance.
Doing this to my own backlog took about half an hour of clicking. Two of the issues turned out to be the same issue. One was already fixed and nobody had closed it. That is a mediocre outcome for thirty minutes and it is still better than the previous state, which was that I avoided opening the list.
Once the labels exist, automating a stage becomes possible rather than architectural. If you later want a script or an agent to attempt reproduction on everything tagged needs-repro, it has a well-defined input, a well-defined output, and one label to move. But you get most of the benefit before you write any of that, which is the argument for doing the boring half first.
Where the agent version stops making sense solo
The Astro setup is running against a repo with a lot of inbound issues from strangers. That is the condition that justifies building a pipeline. Automation earns its keep on volume you did not choose and cannot predict.
A solo repo mostly has issues you filed yourself. You already know what they are. You do not need an agent to reproduce a bug you wrote the reproduction steps for, and you definitely do not need four agents to do it in stages. The honest ratio is that below some threshold, maybe 20 or 30 open issues, the pipeline costs more to run and maintain than triaging by hand.
There is also a failure mode worth naming: an agent that closes issues it could not reproduce. On a busy repo that is a real user getting silently dropped. Astro's design puts verification in its own stage precisely so "could not reproduce" is a state rather than a conclusion, which is the right call and also the thing a hastily copied version would skip.
What I would actually do
If you maintain something with real inbound volume, read the Cloudflare post properly and look at Flue. The reproduce-diagnose-verify-fix decomposition is worth stealing on its own, and the fact that it is open source means you can evaluate it against your repo rather than reasoning about it.
If you are a solo operator with a backlog you avoid looking at, do the labels and skip the agents. Four labels, half an hour. The measurable outcome I would look for is not issues closed, it is whether you open the list voluntarily a week later. If you do, it worked.
Where I could be wrong: I am assuming the state machine is the durable insight and the agents are an implementation detail, and there is a reading where that is backwards. If agent reliability keeps improving at the rate it has this year, the threshold where automated triage beats manual triage will drop, and it may drop well below 20 open issues. In that world the people who built the label scaffolding early are the ones positioned to flip the switch, which is an argument for the same action either way, just for a different reason.
Author
Lukas
@lukcombinator