A factory that ships software, not slop
Beadhive is a bead-machine: a software factory that runs on beads. Agents run planning, review, release and operations at the speed the code gets written, and you hold the gates.
Slop is a process problem, not an AI problem
Unmaintainable software existed long before agents — AI just multiplied the speed it happens at. And process-as-brakes never worked either: discipline that slows builders down gets routed around. The answer isn't slowing anything down — it's speeding everything else up to match, the self-correcting practices of a mature engineering org run by agents at the same speed the code gets written:
- Reviews that change the process, not just the code
- Incidents that become guardrails, not just fixes
- Retros that rewrite the next plan
Agents do the discipline. You hold the gates.
Code got fast. Everything around it didn't.
Agents made code cheap. Planning, review, release and the record ofwhy still run at human speed — or get skipped. That gap is where slop comes from, and it was there long before agents; they just widened it. Beadhive runs everything around the code at the code's pace:
- Plans that are gated before any work starts
- Merges that refuse while a gate is open
- Releases that prove the exact tree they ship
Agents do the discipline. You hold the gates.
Three things, briefly
Automation is a dial, not a prerequisite
Other factories assume you already have the test coverage, the observability, and the trust to let agents run. Most teams have none of the three, so adoption dies on contact.
- Zero footprint in your repo until you ask for it
- Every gate defaults to a human
- Hand over one seat at a time, when the evidence earns it
The coding framework and the SRE agent are one system
Built as two products everywhere else — one writes code, another watches it run, nothing connects them. An incident shouldn't just get mitigated once; it should change what gets generated next time.
- Reviews target the process, not just the incident — the output is a guardrail that prevents recurrence, not only a fix
- shipped planning, dispatch, review, merge, and a guarded release that proves the exact tree it publishes
- direction the return path — production signal into the next plan and its guardrails
Open source, and made to be taken apart
Developers don't adopt infrastructure they can't read. Run the whole factory on a hobby project over a weekend and decide for yourself whether it's real.
- No signup, no hosted dependency — everything runs on your machine
The parts you actually touch
bh is a CLI. It drives bd for issues andgit for history — nothing to deploy, nothing hosted; the issue database is a local server bd starts for you.
⬢Work is a graph
A git-embedded tracker with real dependency edges, so "what's next" is computed, and it survives an agent losing its context.
⬢Seats, not workflows
Planner, dispatcher, developer, reviewer, merger, warden. A person or an agent fills any of them, and every action is stamped with the seat that took it.
⬢Humans hold the gates
Gates are records, not vibes in a chat log. Merge refuses to land while one is open.
⬢Every change is signed
Each agent works in its own worktree under its own identity. You can always see which worker did what.
⬢Green is proven, not assumed
Validation results are keyed to the exact tree they ran on. A release can't push until that tree is attested green; a reused result is never a claim about the whole tree.
Start automating one step at a time
Point it at a real repo. A hive writes nothing into yours until you ask it to, and you don't have to run the whole line to get something out of it.
Paste one link at your agent. It asks before every command and tells you what each one does.
https://github.com/beadhive/beadhive/blob/main/INSTALL.mdFrom there, the agents take it: a planner turns your idea into a gated plan, a dispatcher delivers it bead by bead, and every gate defaults to you. The start guide walks the whole first loop — including bringing in the planning your repo already has.