From a user of both: Loom and Gas Town look like two halves of the same system

[v-good]

Hey Robb,

Posting this as a user, not as anyone with authority to propose mergers. I run a small studio with multiple projects in parallel, and I've been operating my own instance of Steve Yegge's Gas Town to coordinate work across them. I started reading Loom this afternoon and the architectural overlap between the two felt worth flagging out loud.

(Steve's intro to Gas Town, for anyone landing here cold: https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04)

What you've nailed in Loom

Labels-as-coordination is the right human surface. Forge-agnostic abstraction (GitHub + Gitea via ForgeClient) is sharp. The 4-layer hierarchy (Human → Daemon → Shepherds → Workers) is clean. Shipping at v0.6.5 with a daemon, a .app bundle, and real worktree-isolated execution puts Loom ahead of 99% of the "agent orchestrator" repos out there.

The thing I find most compelling is your worldview: that professional software development happens on GitHub in a particular ritual (issues opened → curated → built → judged → merged), and that putting agents inside that ritual primes them to perform like real engineers because the training corpus is full of GitHub-shaped work. That's a real insight and most orchestrator projects miss it.

The wall I hit as a multi-project user

Loom's worldview assumes one repo at a time. Issues, PRs, labels, branch protection — all per-repo. That's perfect for solo devs and small teams running a single product.

But when I'm coordinating across multiple projects in parallel, I need a layer Loom doesn't have: somewhere to ask "what's happening across all my work right now," to escalate cross-cutting decisions, to move an agent from finishing one project's job to picking up another's. The forge becomes the bottleneck because the forge is repo-scoped.

That's the wall. And it's exactly the wall Gas Town is built to solve.

What Gas Town adds, from a user's seat

I'm describing Steve's architecture, not pitching it as mine. Things GT has that Loom doesn't, in rough order of how often I rely on each:

1. Mayor: a global coordinator above the per-rig daemons — cross-project strategy, escalation routing, human interface.
2. Cross-project agents with persistent identity, not bound to one issue or one repo.
3. Dolt as ledger: a durable, queryable, time-traveling SQL state store. Labels are 5 enum values; beads (GT's work units) are first-class objects with relationships, types, priority, dependencies, and history.
4. Mail: agent-to-agent messaging separate from work items. Witnesses can flag the Mayor without polluting the bead.
5. Watchdog stack: Deacon patrols agents, Boot watches Deacon. Self-healing without human in the loop.
6. Convoys + molecules: formula-based workflows for repeatable multi-step coordination. Beyond per-issue shepherding.
7. Federation ("wasteland"): multiple towns federate across organizations. Cross-org agent collaboration.
8. Go binary: single static executable, no Python dependency chain.

None of this replaces what Loom does well. From where I sit, it all sits one layer above what Loom does well.

Why this isn't competition

Multi-project coordinator (Gas Town: Mayor, Beads, Mail, Convoys)
              │
              ├── Forge abstraction (Loom's ForgeClient) ← the bridge
              │
       Per-rig agent execution (Loom's shepherd/worker pattern)
              │
              └── Worktree + tmux + claude (both stacks share this)

The thing Gas Town doesn't have today: forge-aware bead↔issue sync. Beads exist in GT's local ledger; they don't materialize as GitHub issues automatically. Your ForgeClient abstraction with 21 unified methods is exactly what GT needs to close that gap.

The thing Loom doesn't have today: a coordinator above the daemon that can reason across repos. Steve's Mayor concept is exactly that.

Two halves of the same system, built by two different people, solving adjacent problems with non-overlapping primitives.

What I'm flagging, and what I'm not

I'm not proposing a merger — I have no standing to. I don't know Steve, and I'm not building either of these projects. I'm a user of GT who walked into Loom from the outside and saw an architectural pattern that felt worth naming out loud.

Two reasons it might be worth your time:

1. If you ever hit the multi-project wall I described, the work to solve it has already been done in a different repo by someone else. Worth knowing it exists before reinventing it.
2. The ForgeClient abstraction you've built is, from a user's seat, exactly the missing piece in GT — beads don't sync to GitHub issues today. Whether that's interesting to you depends on whether you ever want to talk to someone outside Loom about shared infrastructure.

Curious whether the overlap is as visible from the Loom side as it is from the user side. Either way, the worldview behind Loom — GitHub-shaped rituals priming agents to perform like real engineers — is the part I'll be carrying with me regardless.

— Vivake Gupta

---

Appendix: why your worldview matters

The "GitHub-shaped rituals prime agents to perform like professionals" insight is, I think, the most underrated point in your repo's docs. LLMs trained on GitHub corpora have absorbed millions of well-formed issues, PR descriptions, code review threads, and conventional commits. Agents inside that ritual activate an enormous embedded prior — they already know what professional looks like, because the training corpus is that.

Bespoke orchestration vocabularies (bead, wisp, polecat, hook, rig — Gas Town's terms; or any other custom system's invented nouns) are creatively coherent but they're a novel role-context the agent has to be taught every session. Cognitive tax.

The right architecture probably isn't "Loom's view or Gas Town's view." It's GitHub-shaped surface for the agents (Loom's domain) sitting on top of cross-project coordination infrastructure (Gas Town's domain). The polecat doesn't need to know it's a polecat. It needs to know it's a senior engineer with an issue assigned. Loom does that beautifully today.

[rjwalters]

Vivake — thanks for taking the time. This is the most useful piece of outside reading I've gotten on Loom in months, partly because you're describing a wall you've actually hit and partly because you're explicitly not asking me to do anything about it.

A few honest reactions.

The worldview point lands. "GitHub-shaped rituals as embedded prior" is a sharper articulation of why Loom uses labels and PR-shaped workflows than I've ever written down. Stealing it for the docs if you don't mind.

Where I want to push back is on the "multi-project wall" being a wall at all. Loom is per-repo because Git is per-repo and GitHub is per-repo, and that's not an accident — the repo is the unit of conceptually coherent software. If three projects need to coordinate so much that you want a Mayor reasoning across them, the first question I'd ask is whether they're actually three projects or one project that's been over-fragmented. Monorepo dissolves the wall by recognizing that "things that coordinate" and "things that live together" should be the same set. And if the projects genuinely don't share concerns, they don't need cross-project coordination either — they need N parallel Loom instances and a human who context-switches. The genuinely narrower problem that remains is federation across organizations — different companies, different forges. That one's real, and I'm not sure Loom should be the thing solving it.

By the same logic, "two halves" doesn't quite hold. The thing you praised — GitHub-shaped rituals as the coordination surface — is in tension with adding a parallel coordination substrate above it. Loom's bet is that the forge is canonical: any state outside the forge eventually drifts. A Mayor + Dolt + Mail stack is, architecturally, a second source of truth. Federation across orgs needs that; one studio's work doesn't.

And on the primitives themselves — your own appendix cuts harder than you let it. The cognitive-tax point about bespoke vocabularies (bead, wisp, polecat, rig) isn't a small footnote. If the value of GitHub-shaped rituals is that LLMs already know them, then inventing parallel nouns is the opposite move — every named entity is a thing the agent has to be taught from scratch every session, and a thing the human has to translate back to "oh, a bead is just an issue." Loom's role names (curator, builder, judge, doctor) are also names, but they're job titles a human engineer would recognize on a resume. Borrowing existing vocabulary compounds with the prior; inventing a frontier-town aesthetic competes with it.

ForgeClient as a bridge — yeah, the abstraction exists exactly because the per-repo-but-forge-portable assumption needed to be made explicit. If GT ever wants forge-aware bead↔issue sync, the surface area is small enough for an afternoon's work. No promises from this side, but the geometry is real.

Honestly, the simpler frame: I built Loom for myself, it's working for me, and I'm convinced the path is right. From where I sit Gas Town has chosen a different one — but that's a designer's view, not a marketer's, and the work has to speak for itself either way.

If you push back — especially on the monorepo bit — I'd want to hear where the argument breaks down for you.

— Robb

[v-good]

Robb — fair pushback. Three responses, in order of how much you've changed my mind.

On the monorepo critique you mostly win. "If three projects need to coordinate that much, ask whether they're really one project that's been over-fragmented" is the right first-question. For solo devs and integrated teams, the answer often is "yes, monorepo." Where I'd narrow your claim is the case where fragmentation is structural rather than over-engineered: separate GitHub orgs for IP/legal attribution boundaries, separate licenses, separate compliance regimes, separate funding sources. In my situation a non-profit (OSS, mission-bound) and a for-profit studio cannot share a repo for reasons the engineer in me wishes were technical. That's not "over-fragmented" — that's the territory the map has to fit. For developers who don't have that constraint, your point stands cleanly.

On second-source-of-truth drift, you're identifying a real cost. Dolt-as-ledger does add a coordination substrate above the forge, and yes, anything not derivable from forge state will drift. The operational counterweight is that the drift you avoid by not having a coordinator — me manually paging through eight repo issue lists every morning — is the worse failure mode in practice. The bet is "drift in a queryable substrate" beats "drift in a human's working memory." But the cost is real and worth naming, and your forge-canonical position is the more conservative bet.

On the cognitive tax — you're entirely right. "Bead, wisp, polecat, rig" is a mistake the moment GT is read by an LLM whose training corpus has no idea what a polecat is. The naming overhead burns prior every session. If GT ever rationalizes nouns, "issue," "task," "agent," "worker," "project" are the right targets. Loom's "curator/builder/judge/doctor" is the better pattern — job titles a human engineer could put on a CV. Stealing this critique back into the GT side regardless of what happens between the projects.

On ForgeClient as bridge — yes, I'd take you up on that geometry if you ever want to point a curious agent at it. Forge-aware bead↔issue sync is the most concrete unlock between the two stacks, and an afternoon's work on your end could save weeks of reinvention on someone else's. No ask attached; just acknowledging the offer is real.

The simpler frame, which I think we agree on: you've optimized for "the forge is canonical and the prior compounds." I've optimized for "I have eight projects and one head." Those aren't the same problem, and Loom's path doesn't need to bend to fit mine. From this side, both halves have been clarified by the exchange.

— Vivake