Two weeks ago, Steve Yegge released GasTown, a multi-agent orchestrator he describes as "an industrialized coding factory manned by superintelligent chimpanzees." A few days later, Dan Lorenc quietly pushed multiclaude, built on what he calls the "Brownian Ratchet" principle: chaos is fine, as long as we ratchet forward.
While the projects are separate, Dan says he was deeply inspired by Gas Town. However, they, and many others like them, landed on almost identical foundational architecture: detached UI for observability, git worktrees for isolation, external state persistence, and CI as the final arbiter. That convergence tells us something important about where agent tooling is heading.
The Problem Both Solve
Running one Claude Code instance is straightforward, but running twenty in parallel on the same codebase is a distributed systems problem. The challenges are familiar to anyone who's operated infrastructure at scale: agent sessions crash, work gets duplicated, changes conflict, and state disappears when processes restart. Without proper isolation, a single runaway agent can corrupt shared resources, and without observability you can't debug what's happening. If state doesn't persist, progress evaporates the moment something fails.
In source code, people saw this same problem (lots of people working on the same thing), and solved it incrementally with things like SVN, and then Git (with many others as well).
Every multi-agent orchestration system has to answer these questions about multiple things working on a single thing, and what's interesting is watching how different systems answer them.
Two Philosophies, Same Primitives
GasTown takes the comprehensive approach, with seven distinct agent roles that divide responsibilities across the system. The Mayor coordinates overall work, Polecats handle ephemeral tasks, the Refinery manages merge queues, and so on through Witness, Deacon, Dogs, and Crew. Work flows through what Yegge calls the MEOW stack (Molecules, Epics, Work orders), with state persisting through git-backed "hooks" and the Beads memory framework. Agents maintain persistent identities that survive session crashes via the GUPP principle: "If there is work on your hook, YOU MUST RUN IT." This is ... confusing ... but i have to respect explicitly naming everything. Gives you an unequivocal way to know what (and who) is doing what, at the cost of a lot of UX affordance up front.
multiclaude takes the minimalist path with just three roles: a supervisor that coordinates, workers that execute tasks, and a merge-queue agent that handles CI. State lives in a JSON file and the filesystem, communication happens through simple message passing, and the philosophy is explicit: "Trying to perfectly coordinate agent work is both expensive and fragile. Instead, we let chaos happen and use CI as the ratchet that captures forward progress."
The rhetoric differs dramatically between the two projects. Yegge's documentation reads like a manifesto, complete with warnings that you shouldn't use GasTown if you "care about money" or are "more than 4 feet tall." Lorenc's README is Unix-philosophy spare, with clean diagrams and matter-of-fact explanations. But underneath the different personalities, you find the same primitives.
Primitive
GasTown
multiclaude
Process isolation
tmux windows
tmux windows
Code isolation
git worktrees
git worktrees
State persistence
Git-backed hooks
JSON + filesystem
Quality gate
CI (automated merging)
CI ("the ratchet")
Observability
Attach to any session
Attach to any session
Both folks recognized that you can't just spawn Claude instances and hope for the best. You need boundaries.
What the Convergence Reveals
When two experienced engineers arrive at the same architectural primitives, that's signal worth paying attention to. It suggests these aren't arbitrary choices but structural requirements for the problem space.
Isolation requires more than process boundaries. Both projects use git worktrees rather than just separate directories because a worktree gives each agent its own branch, its own working copy, and its own commit history. Conflicts become merge conflicts, which git already knows how to surface, and the blast radius of any single agent is bounded by what it can do to its own worktree.
Observability can't be an afterthought. Both chose tmux as the primary interface rather than a web dashboard or log aggregator. A terminal multiplexer lets you attach to any agent's session, watch it work, and intervene if needed. This is distinctly different from how most "AI agent frameworks" approach the problem, with their emphasis on structured outputs and API-driven orchestration.
State must survive failures. GasTown invests heavily in crash recovery through git-backed hooks while multiclaude keeps it simpler with filesystem persistence, but both reject the idea of ephemeral agent state. When a session dies, the work shouldn't die with it.
CI becomes the coordination mechanism. In both systems, CI isn't just a quality check but the arbiter of what counts as progress. Lorenc is explicit: "If it passes, the code goes in. If it fails, it doesn't. The automation decides." Yegge's Refinery agent serves the same function, and this approach shifts coordination from real-time synchronization (expensive, fragile) to asynchronous validation (robust, scalable).
The Deeper Pattern: Scoped Autonomy
Strip away the specific implementations and you find a design pattern emerging for AI agent systems: scoped autonomy with external persistence. Give agents freedom to act within clear boundaries, let them fail without cascading damage, capture successful outcomes permanently, and accept that coordination is expensive and often unnecessary if your ratchet mechanism is good enough.
This isn't a new idea. It's how we've learned to build reliable distributed systems over the past two decades, and the insight here is that agent orchestration is distributed systems with the same principles applying. Kubernetes asks "Is it running?" and reconciles toward desired state while GasTown asks "Is it done?" and persists completed work. Both are control loops operating over unreliable workers, and both accept that perfect coordination is impossible and design around it.
Where They Diverge: Single-Player vs. MMORPG
The most interesting philosophical difference isn't about orchestration complexity but about the human model.
Lorenc frames multiclaude explicitly: "Gastown treats agents as NPCs in a single-player game. You're the player, agents are your minions. multiclaude treats software engineering as an MMORPG. You're one player among many."
In multiclaude, your workspace persists. You spawn workers, go to lunch, come back, and check what merged while you were away. Other humans can have their own workspaces on the same repo, and the system keeps running when you're not watching.
GasTown is designed around intensive engagement. Yegge describes watching 20-30 agents in parallel, making $100/hour decisions about what work to greenlight, experiencing "palpable stress" as the system runs at speeds too fast to comprehend. It's a powerful multiplier for an engaged operator rather than a fire-and-forget system.
Neither model is wrong since they're optimizing for different workflows, but the MMORPG framing points toward something important: these systems need to work when humans aren't actively supervising.
What This Means for the Industry
We're watching the orchestration layer crystallize in real time, and the patterns that emerge now will shape how agent systems get built for years.
The "19-agent trap" (simulating an org chart with Analyst → PM → Architect → Dev → QA handoffs) is giving way to operational models where agents have specific, bounded roles. The emphasis shifts from elaborate prompting frameworks to infrastructure primitives: isolation, persistence, observability.
The tooling will mature as costs drop. Right now, GasTown burns $100/hour in tokens, partly because the models are expensive and partly because the coordination overhead is high. Both factors will improve, and the architectural patterns being established now will outlast the current pricing structure.
For teams thinking about agent infrastructure, the lesson isn't "adopt GasTown" or "adopt multiclaude" since both are weeks old and explicitly experimental. The lesson is to watch what primitives they converged on, because if you're building agent systems you'll probably need them too: git worktrees for isolation, something tmux-like for observability, persistent state that survives session failures, and CI or some equivalent as the ratchet that captures forward progress.
The chimpanzee factory and the Brownian ratchet arrived at the same answer. That's worth paying attention to.
Repos:
- GasTown: github.com/steveyegge/gastown
- multiclaude: github.com/dlorenc/multiclaude
Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*
NOTE: I'm currently writing a book based on what I have seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. [I'd love to hear your thoughts**](https://github.com/aronchick/Project-Zen-and-the-Art-of-Data-Maintenance?ref=distributedthoughts.org)!**
Originally published at Distributed Thoughts.
Top comments (0)