Cloudflare and the Astro team have reduced the Astro project’s unresolved GitHub issue backlog from more than 200 issues to roughly 30 by using multiple artificial intelligence agents inside GitHub Actions, according to a Cloudflare engineering report.
The system was designed around several specialised agents rather than a single autonomous agent. Separate stages handle issue reproduction, diagnosis, verification and fixing, with each stage producing information that can be used by the next agent in the workflow.
Cloudflare said the reduction represents an approximately 85% decrease in the number of open issues. The figure refers specifically to the project’s unresolved GitHub issue count and does not mean that artificial intelligence independently fixed 85% of all bugs or that human involvement was removed from the process.
The work began with an agent skill based on the way Astro maintainers investigated issues manually. The skill was first developed and tested locally before being moved into GitHub Actions, allowing the workflow to operate within the project’s existing development environment.
The first stage attempts to reproduce an issue using the reporter’s reproduction repository. When the reported behaviour can be reproduced, another stage investigates the codebase, adds instrumentation or logging when needed and attempts to determine the underlying cause.
A separate verification stage then checks whether the reported behaviour is actually unintended. The agent can examine existing tests, documentation, comments and surrounding implementation details before the issue is treated as a confirmed bug.
For issues that reach the fix stage, the workflow turns the reproduction into a failing test and then attempts to implement a solution. Astro’s repository guidance instructs coding agents to define success criteria and verify their changes, with bug fixes generally following a test-first pattern in which the bug is reproduced, the test is made to pass and the result is verified.
The separation of responsibilities was deliberate. Cloudflare said large language models can develop a tendency to search for a solution even when the reported behaviour may not actually represent a bug. Isolating reproduction, diagnosis, verification and fixing gives each stage a narrower task and prevents one long agent session from making the entire decision.
Information is passed between the stages through a report.md file rather than one continuously expanding conversation. This gives each agent a record of what the previous stage found while limiting the amount of context it has to process.
The workflow also uses GitHub issue labels as its state-management system. The open-source triagebot-action includes states such as triage: needs triage, triage: needs reproduction, triage: unable to reproduce, triage: unable to fix, triage: fix pending, triage: fix rejected, triage: fix verified, triage: not actionable, triage: skipped and triage: failed.
That label-based approach allows the GitHub issue itself to retain the state of the workflow. Some states are terminal, while issues can be reconsidered when new comments provide information that could change the result.
When the system produces a possible fix, the process can include a human verification step. The workflow can create a branch and preview release, post its findings and logs to the issue and provide instructions for the original reporter to test the proposed change. After the reporter confirms that the fix works, the system can proceed to create a pull request.
The current GitHub Action configuration also supports automatic pull-request creation after a fix, giving projects the option to use a confirmation-first workflow or open a pull request immediately after a fix is produced.
The project has been extracted into the standalone withastro/triagebot-action repository. The action provides the general workflow, GitHub integration, model calls, state handling, verification and pull-request operations, while individual projects provide repository-specific instructions and skills.
Those project-specific instructions are a significant part of the system. Astro maintains agent guidance that describes areas of the codebase, development practices, testing requirements and architectural constraints. Its Astro developer skill and AGENTS.md guidance give coding agents information needed to work within the repository rather than relying only on general model knowledge.
The agents can also execute commands in the GitHub Actions environment, which allows them to build, test and investigate code instead of producing fixes solely from static source-code analysis.
The action supports Anthropic models as well as Cloudflare Workers AI models. Its current configuration lists Claude Opus 4.6 for triage and Claude Sonnet 4.6 for verification, while the project documentation also describes the use of Cloudflare Workers AI models.
Cloudflare said the process exposed weaknesses in Astro’s own codebase in addition to reducing the issue backlog. One example involved Hot Module Replacement logic. An agent repeatedly modified a particular condition while trying to address related HMR issues, producing changes that appeared useful for the reported problem but caused regressions elsewhere.
The experience showed that the relevant code did not have enough test coverage around the condition. After the team added a descriptive comment explaining the intended behaviour, the agent stopped repeatedly attempting the problematic modification. Cloudflare said the experience highlighted problems involving opaque abstractions, missing documentation and insufficient tests.
The issue-triage project subsequently contributed to the development of Flue, an open-source agent framework from the Astro team. Flue supports agents, subagents, skills, sandboxes, tools, durable execution, MCP servers and observability, and can be deployed through environments including Node.js, Cloudflare Workers and GitHub Actions.
The broader architecture treats agent work as a sequence of controlled stages rather than one unrestricted process. A GitHub issue enters the workflow, the appropriate agent is selected based on its state, the agent performs its assigned task, results are recorded and the issue moves to another state when the required conditions are met.
The project also raises security considerations because the system processes GitHub issue content while agents can interact with source code and repository credentials. The public triagebot-action development history includes work concerning long-lived tokens and prompt-injection risks associated with issue bodies.
The action’s documentation distinguishes between read and write credentials and describes using a GitHub App token or personal access token for write operations. These controls are important because issue content is supplied by external users and can become part of the context presented to an automated coding system.
Astro’s public issue tracker now contains issues carrying triage labels such as triage: needs reproduction, triage: fix pending, triage: fix verified, triage: unable to reproduce and triage: unable to fix, showing that the workflow is integrated into the project’s public issue-management process. The Astro GitHub issue tracker provides the public record of those states.
Cloudflare’s reported result is significant because it demonstrates a way to use AI agents for software maintenance without assigning every responsibility to one system. In Astro’s case, the agents operate within a workflow with defined stages, repository-specific instructions, tests, GitHub state tracking and opportunities for human verification.
The reduction from more than 200 open issues to approximately 30 is therefore best understood as the result of an engineered maintenance workflow rather than a demonstration of an AI system independently resolving most of Astro’s bugs. The work is now available in open source through the triagebot-action repository, while the wider agent architecture has continued through Flue.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
