Put a team of agents to work on your software

The workflows we run

Astrohacker is built by agents. This is how the work is organized today, in the open, in our own repositories:

• Separate roles in separate sessions. An issues session turns requests into GitHub issues. A code session takes issues, a review session reviews pull requests, and a deploy session releases what merged. Code and review never run in the same session, so no change approves itself.
• One worker per issue or pull request. Each role session starts a worker for each issue or pull request it takes. That worker stays with it through every review round until it is merged and cleaned up.
• Independent review of the exact commit. The reviewer checks the specific commit that would merge, runs the checks itself, and asks for changes until it passes. After three rounds it either passes or hands the pull request to a person.
• A repository tool that enforces the rules. Our command-line tool, ah, gives each agent an exclusive claim on its issue and applies the merge policy, so the rules are code rather than a paragraph in a prompt.
• GitHub as shared state. Issues, pull requests, comments and labels are the record every agent reads and writes. Nothing important lives only in one agent’s memory.
• People decide what only people can decide. Any agent can put a hold on an issue. The work stops until a person answers, and only that person can lift the hold.
• Continuous deployment. The deploy session releases each merged change and checks the published site, with no approval step per release.

On November 10, 2026, this setup made 926 GitHub contributions, as counted on the GitHub contribution calendar of Ryan X. Charles, whose login our agents share. Across four of our repositories, in US Central time, that day saw 517 commits to the main branches, 147 issues opened and 130 pull requests opened. Those categories are measured separately and don’t sum exactly to 926.

The rules are public. Read our AGENTS.md and the skills each role follows. We have written about how it works and what we learned:

• Building a Software Factory
• Software Factory vs Software Garden
• Who Checks the Software Factory?
• Can You Copy a Software Factory?
• The Living Software Repository

To set up a swarm like this yourself, follow our hands-on guide, Build an Agent Swarm With Claude Code.

How we design a new workflow

Your problem is not ours, so we don’t copy our setup onto it. We design one for your work, the way we carried ours to a second codebase in Can You Copy a Software Factory?:

1. Map the work and its risks. What comes in, what has to come out, and what goes wrong when it fails.
2. Choose the roles and the checks between them. Who does the work, who checks it, and against what. The checker needs a different job from the maker; see Who Checks the Software Factory?.
3. Decide which decisions stay with people. Spending, releases, product calls, anything you would not delegate to a new hire on day one.
4. Encode the rules in tools and skills. Claims, holds and merge rules belong in code and checked-in instructions, not in a prompt the next session might not see.
5. Run a pilot and measure it. Put the system on real work, count what it ships and what review catches, and change it from what you see.

Factory, refinery or garden

These are three framings we choose between, not three products.

Software factory

Requests come in as issues and move through stations, each with its own check, until they ship. You measure throughput and the defects each station stops. See Building a Software Factory.

Software refinery

The input already exists: a codebase, documentation, a backlog. Agents make repeated passes over it, each removing one kind of impurity, such as dead code, missing tests or unclear copy. The output is the same thing, cleaner.

Software garden

The codebase is a living thing that keeps changing. Agents tend it over time, and people decide what it should grow into. See Software Factory vs Software Garden and The Living Software Repository.