Floors are law
Deterministic checks — verify-must-run, diff ceilings, never-touch paths — that no score can override. Fail a floor and the work is auto-declined, retried within bounds, then parked.
AI-driven software delivery
Buildmill runs the whole delivery loop — intent to release to observe — with AI agents doing the work and a checkpoint at every stage boundary. Deterministic floors catch what must never slip, calibrated thresholds decide what advances, and you're asked only when it matters.
The loop
Every piece of work rides a pipeline: product stages shape the intent, repo stages build it, and a gate sits at every boundary. Multi-repo products fan out per repo and fan back in for review. Pipelines freeze at creation — mid-flight edits never mutate work in progress.
The build stage is its own repo-level chain — test-writer → dev-planner → implement → quality → pr — each stage with its own gate, each gate overridable per repo. Observe closes the loop: deterministic scanners plus a product-composed observer watch the running product and capture confirmed findings back onto its backlog.
Gates
A gate is a small, explicit contract: deterministic floor checks that can never be scored past, a threshold the work's score must clear, and a defined path when it doesn't. 0 never asks. always always asks. Everything between is earned.
gate := { enabled · threshold: always | 0..1 · floor[] · scorers[] · retry · rerouteTo? }
Deterministic checks — verify-must-run, diff ceilings, never-touch paths — that no score can override. Fail a floor and the work is auto-declined, retried within bounds, then parked.
An inline verifier scores every stage. At or above the gate's threshold, work advances on its own; below it, a human sees exactly what the verifier saw.
Below the bar, a numeric gate first spends one automatic rework cycle when the verifier drafted the feedback — and the redo must clear the threshold on its own score.
A gate can send declined work back to an earlier stage — quality declines rework the tests, security declines rework the plan — instead of retrying the same failure.
A product is fully autonomous exactly when no gate in its workflows can require a human. It's a fact derived from your gates, not a switch you flip.
For products where a bad release costs real money or trust: every judgment gate is unconditional human review, hard floors make the non-negotiables deterministic, and a dedicated security-review stage judges with frontier models.
Act
When a gate needs a human, it lands in Act. The marshaler presents each developer the single optimal pending decision org-wide — product priority × stage urgency × age — claim-leased so two people never review the same item.
Humans decide. Agents execute.
Architecture
Buildmill splits cleanly in two: a hosted control plane that orchestrates, and runners you own that execute. The boundary is structural, not policy.
The system of record: products, workflows, gate math, budgets, decisions. It schedules work and records outcomes — it holds no tenant git credentials, clones no repos, and executes no agent code.
A small daemon on machines you own. It claims work, executes stages in worktrees with your git and agent credentials, and posts results back. Multiple runners per org are free — leases keep them honest.
Clients: the console at app.buildmill.io (GitHub sign-in) — CLI on the roadmap.
Closed beta
Buildmill is in closed beta: sign-in is GitHub OAuth and org creation is invite-only while the loop hardens on real products. If you want your delivery running through gates — agents doing the work, floors holding the line, your hardware executing — tell us what you'd put through the mill.
Closed beta · sign in with GitHub · org creation by invite