Loom Fork Watch: Multi-Agent Coordination and Local Development

The Signal in the Noise

Three days ago I wrote about tracking Loom forks. Back then: 154 forks, 5 with modifications. Today: 164 forks, and two new ones that change everything.

Someone is building multi-agent coordination on top of Loom. Another is making it run without Kubernetes. Meanwhile, Geoff himself is building crash monitoring.

Loom Forks: What 154 GitHub Forks Tell Us About AI Agent Development

Previously: The original fork analysis from January 19, 2026

ii.coop

What Geoff's Been Up To

Upstream Loom got 15+ commits in the last two days. The direction is clear: crash monitoring. Think Sentry, but built into Loom.

• Project and issue management API endpoints
• Event queries with filtering
• Release health tracking (resolved_in_release)
• API key authentication for SDK capture
• CLI commands for crash analytics

This fits the pattern. Loom isn't just a coding agent—it's evolving into full-stack developer infrastructure. Observability built in from the start.

The Big Discovery: bgyss/loom

11 commits ahead. Three new crate families. This is the most significant community contribution I've seen.

What they built:

Orchestrator (singleton coordinator)
    ↓
Domain Planners (area experts, file-pattern based)
    ↓
Workers (task executors wrapping core Agent)
    ↓
Judge Agent (evaluates completions, determines iteration)

This enables 10-100+ concurrent agents working on a single codebase. The architecture is clean:

• loom-multi-agent-core - Task types, domain management, project state
• loom-multi-agent-events - Event bus with backpressure control
• loom-context-core - Context drift detection and correction

Tasks have dependencies, iterations, deadlines. Domains are defined by file patterns (web/**/*.tsx). The Judge evaluates completions and decides if more iteration is needed.

The event bus handles backpressure—when planners generate tasks faster than workers can complete them, the system adapts. Events can persist across restarts.

Also Found: alan-roe/loom

12 commits ahead. Local execution backend.

Loom normally runs "weavers" as Kubernetes pods. alan-roe's fork lets you run them as local processes using tmux for session persistence. No K8s required for development.

This is the macOS developer experience fix. You can now hack on Loom without container orchestration.

Updated Fork Tracking

No deletions detected. All previously tracked forks still exist.

The Pattern

Three complementary directions are emerging:

1. Geoff (upstream) - Infrastructure: crash monitoring, observability, enterprise features
2. bgyss - Scale: multi-agent coordination for massive codebases
3. alan-roe - Accessibility: local development without K8s

The documentation forks (Skeptomenos, harry-hathorn) answered "how does Loom work?" These new forks are answering "how do we make Loom work better?"

What I'm Watching

• Will bgyss's multi-agent work get upstreamed?
• Does the crash monitoring signal a commercial Sentry competitor?
• Which forks disappear next? (Deleted forks often mean someone extracted value and cleaned up)

The Question for Geoff

Here's what I keep wondering: what does community involvement actually look like for Loom?

The repo says "if your name is not Geoffrey Huntley then do not use loom." Fair enough—it's research code. But people are clearly hungry to participate. They're writing 316KB of documentation. They're building multi-agent coordination systems. They're making it run on macOS.

The fork pattern shows three types of contributors emerging:

• Documenters — Skeptomenos and harry-hathorn are making the system understandable. Is this useful? Should they coordinate with you?
• Extenders — bgyss is building multi-agent coordination. Is this the direction you're going anyway? Would you accept PRs?
• Porters — alan-roe, denverbaumgartner, iamngoni are making it run in more places. Do platform compatibility fixes align with your goals?

Either answer is valid. But with 164 forks and growing, the community is forming whether you plan for it or not.

I'd love to hear how you think about this.