Beads — The Git-Versioned, SQL-Queryable Work Primitive
Source: Steve Yegge's Gas Town blog series (posts 1–4), Jan–Apr 2026
Code: github.com/gastownhall/beads (20k GitHub stars as of Apr 2026)
Related: [[steve-yegge-gas-town]], [[steve-yegge-gupp]], [[steve-yegge-meow]]
Beads as Universal Data Plane
In Gas Town, Beads are not just for tracking project tasks. They are the universal data plane — the single medium through which all work, coordination, and messaging flows.
Concretely, this means:
- **Project tasks** are Beads (epics decomposed into bead sequences)
- **Orchestration flows** are Beads (the Mayor's handoff instructions to the Refinery)
- **Messages between agents** are Beads (with full context preserved)
- **Patrol routes** for the Deacon daemon are Beads (structured work items the Deacon assigns to itself)
- **Quality gate results** are Beads (Witness output recorded as structured data)
- **Reputation stamps** from the Wasteland are Beads
Because everything is a Bead, everything is git-versioned, branchable, queryable, and auditable. Dolt's SQL interface means you can run queries like:
SELECT bead_id, author, reason, status FROM beads WHERE type = 'quality_gate' AND created_at > '2026-04-01' AND reason ILIKE '%security%';This is the forensic foundation that makes a dark factory trustworthy. Every action taken by every agent is logged, versioned, and queryable — not in some opaque activity feed, but in a database your existing tooling already understands.
Beads and the Wasteland
Beads are the substrate for the Wasteland's reputation economy. When a Rig completes work in the Wasteland (see [[steve-yegge-wasteland]]), the requesting party issues stamps — multi-dimensional attestations (quality, reliability, creativity) — as Beads attached to the original work item. The immutable, queryable Bead history means any party can audit a Rig's track record by querying its completed Beads.
The "yearbook rule" of the Wasteland — you can't stamp your own work — is enforced structurally: stamps are separate Beads authored by the validator, not the worker.
Kelly Parallel
| Beads Concept | Kelly Equivalent |
|---|---|
| Bead as atomic work item | Kelly's **work-item tracking** — each task in the pipeline has an associated work item |
| Bead's `reason` field (Why) | Kelly's **TEA audit trail** — reasoning logged alongside actions for forensic reconstruction |
| Immutable, versioned Beads | Kelly's **done markers per subphase** — explicit state transitions that create a paper trail |
| Dolt SQL queryability | Kelly's **pipeline state** — structured state query, but Beads' Dolt is far more powerful |
| Epics as Bead sequences | Kelly's **subphase → action chain** — ordered work items flowing through pipeline stages |
| Stamps as attached Beads | Kelly's **multi-agent attestations** (e.g., 5-agent verdict) — external validation recorded on the work item |
| Bead authorship (who did it) | Kelly's **agent attribution** — which agent performed which action |
Key gap: Kelly has no equivalent to the Bead's universal data plane. In Kelly's system, work items, messages, quality gates, and patrol routes are tracked in separate mechanisms (memory, heartbeat, pipeline state, TEA audit). Beads would unify these into a single git-versioned, SQL-queryable store. This is a significant architectural simplification.
Key distinction: Kelly's TEA audit captures reasoning alongside actions but is not designed to be the work item itself. Beads make the reasoning the primary citizen, not a sidecar. A Bead is the work; its git history is the audit.