The Astro framework's open issue count went from more than 200 to roughly 30. Cloudflare, which maintains the project, credits AI agents running inside GitHub Actions for the drop of about 85%. The stated target is zero.
The number is eye-catching. The design underneath it is the part worth studying, because it looks nothing like handing a model a repository and asking it to fix things.
Four agents, one file
The workflow mirrors what Astro maintainers did by hand. Each step runs as its own subagent, and the boundaries are strict.
A reproduction agent confirms the reported behavior actually occurs. A diagnosis agent instruments the code to locate the cause. A verification agent reads tests, documentation and comments to establish what the intended behavior was. A fix agent turns the reproduction into a test case, then implements a solution.
The agents do not share an execution context. They pass information forward through a report.md file.
That choice is deliberate and easy to underrate. A shared context lets an early wrong assumption contaminate every later step. A handoff artifact forces each stage to state its conclusions explicitly, and it gives a human reviewer something readable when the chain produces a bad answer.
Labels as a state machine
Orchestration runs on GitHub issue labels rather than a bespoke controller. New issues get a triage-needed label. Confirmed fixes move toward a fix-verified state.
When an agent lands on a candidate fix, the workflow builds a preview release. It posts findings, logs and installation instructions directly to the issue thread. The reporter installs the preview and says whether it worked.
Only after that confirmation does the automation open a pull request. A July 2026 issue involving Astro's Container API moved through exactly this path, reaching fix-verified after the original reporter validated the bot's patch.
The sequencing puts the person who filed the bug back in the loop as the acceptance test. That is a cheaper verification signal than a maintainer review, and it is a more reliable one than a passing CI run.
Failure as a code smell
The most interesting claim in Cloudflare's account is not about throughput.
The team treats failed agent runs as diagnostic information about the codebase itself. In one Hot Module Replacement case, an agent kept rewriting the same conditional and introducing regressions. The underlying behavior had no tests describing it, so nothing pushed back.
Adding a descriptive comment changed the agent's behavior and stopped the loop. Read that as an inversion of the usual framing: the agent was not confused so much as the code was underspecified, and the agent surfaced it faster than a human contributor would have.
Commenters on the work picked up the same thread. Jordan Matthiesen, a senior product manager at CloudBees, emphasized reproducing before diagnosing and making fixes trivial for reporters to test. Shubhanshu Singh characterized the workflow as explicit system design rather than reliance on agent loop abstractions.
From one repo to a framework
The Astro workflow has since been packaged twice over. It exists as triagebot-action, a standalone GitHub Action, and its orchestration model became Flue, an open-source framework for durable agent workflows.
Flue inverts how agent code is usually written. Developers declare an agent's context — its model, skills, sandbox and instructions — instead of hand-rolling an orchestration loop. Execution history persists to an append-only event log, so an interrupted run resumes from its last state rather than starting over.
It connects to GitHub, Slack, Linear and Discord, and runs on Node.js, GitHub Actions or Cloudflare's own platform. On Cloudflare, agents execute as Durable Objects with isolated storage.
What the 85% does and does not prove
A caveat belongs on the headline figure. Closing issues is not the same as improving software, and an aggressive automated triage pass will inevitably resolve some tickets that a maintainer would have kept open.
Cloudflare has not published a breakdown of how many closures were genuine fixes versus duplicates, stale reports or non-reproducible entries. The Container API example is a single documented case, not a sample.
What the project does demonstrate convincingly is a structural pattern. Bounded tasks, explicit handoffs, persistent state, and a human approval gate at the point of highest consequence. That shape is portable, and it is considerably more useful to other maintainers than the percentage is.
