loom takes an ambitious plan — bigger than any single agent could hold in context — and builds it autonomously.
A shop jig, not a product
loom isn't for sale and isn't open source. It's a personal tool — built for my own work, kept here for my own reference and to show friends how it runs. This whole site is that: a reference, not a pitch.
The framing that fits it best comes from a comment on agent harnesses generally — they're shop jigs. You can buy one, but most makers just build their own to fit their own hands.
The source lives at github.com/martineriksson/loom — accessible to team members. If you'd seriously like to try, license, or build something around loom, I occasionally say yes to what interests me: martin@cor.ax.
tptacek · hnThe thing about things like this is that they're shop jigs. You can buy a crosscut sled if you really want to, but most woodworkers just make their own.
The flat build (--sprints). One gate is built and verified up front; then every sprint runs the same execute → gate → fix → review cycle in its own worktree, is committed, and is re-derived from the ledger on resume. When all sprints are green, loom merges to main.
The default driver. A plan is first decomposed into milestones; each milestone is then built as its own set of sprints, every one running the same execute → gate → fix → review cycle shown under sprint. Resume skips done milestones, not just done sprints. Force it with --milestones.
A "design me a new page" pipeline (--design / --redesign). The planner reads the target project's own design system and reference pages and writes a brief; the executor builds each page native to the codebase; the review judges it against that local system. --design builds consistent with existing pages; --redesign works from a blank slate.
A fan-out over a uniform work-list — each unit is its own fresh-agent build, gated independently. Resume re-derives done units by a per-unit skip-test against the unit's artifact, so an interrupted run rebuilds only the remainder.
Coding agents are great at thinking and planning and bad at carrying out anything complex. The reason is structural: a context window fills fast, and once it's ballooned to 200k–300k tokens the model gets slow and stupid — and keeps chugging along as if that were fine. Fanning out to sub-agents is a marginal band-aid: the top-level agent fills its own context just reading their output.
So for anything bigger than a five-minute fix you're better off with an orchestrator. loom splits the work into many agent sessions, no single context growing large enough to rot, and makes the top level a plain script instead of a context-incontinent agent — immune to overload by construction. You still get state-of-the-art reasoning, just invoked exactly where it's needed: "make a plan", "execute this", "review this", "resolve this conflict".
loom itself runs no LLM and never reasons about the code. It is a deterministic orchestrator: it sequences agents, runs the gate itself, records an auditable ledger, and stops on trouble.
try it — three launch forms