Gastown Architecture: Multi-Agent Factory vs Normal Sessions

When developers attempt to scale traditional multi-agent frameworks beyond 2 to 3 turns or across large codebases, they hit what Steve Yegge terms the Multi-Agent Ceiling. Traditional multi-agent systems suffer from four architectural bottlenecks:

The 4 Failure Modes of Traditional Multi-Agent Chat

1. Volatile In-Memory State: Most frameworks store execution state in runtime Python dictionaries or ephemeral message queues. If a network socket drops, rate limits trigger, or a process is killed, 100% of the session state evaporates. 2. Context Window Bloat (Memory Trapped in Tokens): Storing project roadmaps, intermediate tool logs, and file contents directly in the LLM's active prompt rapidly consumes context budgets. Beyond 60k tokens, attention degrades and hallucination rates surge. 3. Anthropomorphic "Prompt Theater": Simulating human organization charts (e.g., "You are a Senior Project Manager who creates user stories for the QA Tester") adds conversational overhead without adding deterministic engineering capabilities. 4. Git Index & Filesystem Collisions: Naive multi-agent setups point multiple LLMs at the same repository directory. When two agents compile, write code, or execute tests concurrently, they corrupt the local Git index and overwrite each other's changes.

Gastown solves these failures by replacing conversational metaphors with battle-tested distributed systems primitives: durable message queues, state databases, process supervisors, and worktree isolation.

Gastown abandons corporate personas in favor of an industrial, operational division of labor designed to run 20 to 30 agents simultaneously:

The Core Operational Roles

• The Mayor: The central orchestrator and developer interface. The Mayor ingests high-level project epics, decomposes them into discrete dependency graphs of atomic tasks, and assigns work items to worker queues.
• Polecats: The primary worker units. Polecats have persistent operational identities but execute inside ephemeral sessions. A Polecat wakes up, claims a task from its hook, executes in an isolated workspace, submits its diff, and terminates.
• Beads: The external state and memory layer. Every task, acceptance criterion, dependency link, and execution status is persisted outside of LLM context windows.
• The Witness: An autonomous lifecycle supervisor. The Witness monitors active Polecats, tracks heartbeat timestamps, identifies stalled processes or infinite loops, and triggers self-healing restarts from Beads state.
• The Deacon & Dogs: Infrastructure maintenance patrol. The Deacon periodically sweeps workspace environments ("Rigs"), dispatching "Dogs" (maintenance scripts) to prune stale Git worktrees, clear temporary build artifacts, and release orphaned locks.
• The Refinery: The dedicated merge manager. The Refinery serializes integration by pulling completed Polecat branches, rebasing them speculatively on main, executing regression test suites, and resolving conflicts automatically.

The most significant architectural breakthrough in Gastown is Beads—a Git-backed, structured task management database (often backed by SQLite or Dolt) that externalizes agent memory from LLM context windows.

Why Externalizing Memory is Mandatory

In a standard agent session, if an agent performs 40 tool calls to explore a codebase, its context window balloons to 150k tokens. When the task finishes, the developer must either discard that context (losing all architectural insights) or keep it (suffering severe context rot on the next prompt).

Beads decouples state completely:

1// Conceptual Schema of a Gastown Bead (Task Entity)2{3  "id": "bead-409",4  "title": "Implement Redis Sliding Window Rate Limiter",5  "status": "IN_PROGRESS",6  "assigned_to": "polecat-04",7  "rig": "coreconcept-backend",8  "dependencies": ["bead-402"],9  "acceptance_criteria": [10    "Atomic Lua script for zset scoring",11    "Zero clock drift across distributed nodes",12    "Unit test coverage > 95% passing via Vitest"13  ],14  "worktree_path": ".worktrees/polecat-04",15  "last_heartbeat": "2026-08-29T12:45:00Z"16}

Zero-Loss Crash Recovery

Because all task states, dependencies, and intermediate findings are written to disk: 1. If a Polecat process is killed by the OS or hits an API rate limit, the task state is not lost. 2. The Witness detects the missing heartbeat, re-queues bead-409, and spins up a fresh Polecat instance. 3. The new worker loads a clean 2k-token prompt, reads the exact task requirements and file paths directly from the Bead, and immediately resumes work without repeating exploratory codebase searches.

Running 20 to 30 concurrent AI coding agents on a single repository is impossible in a shared directory because concurrent file writes cause build race conditions and lock contention.

Gastown enforces strict isolation using Git Worktrees:

The Polecat Worktree Lifecycle

1# Gastown Polecat Worktree Provisioning Flow2# 1. Mayor dispatches task -> Provision dedicated isolated worktree3git worktree add -b feat/bead-409-rate-limiter .worktrees/polecat-04 main4 5# 2. Polecat executes completely inside its private workspace6cd .worktrees/polecat-047npm install --prefer-offline8npm run test:unit9 10# 3. Polecat commits verified changes and submits branch to Refinery11git push origin feat/bead-409-rate-limiter12 13# 4. Deacon cleans up worktree after merge verification14git worktree remove .worktrees/polecat-04

Isolation Benefits Independent Compiler Runtimes: Each Polecat runs `tsc --noEmit` and local test runners against its own isolated directory without interference from other workers. Atomic Rollbacks: If an agent diverges or writes broken code, the entire worktree is deleted with a single command without polluting main or the developer's working directory. True Parallelism:* 30 agents can compile, test, and refactor 30 separate features simultaneously across different branches.

When 20 agents complete tasks in parallel, merging their branches manually creates an overwhelming human review bottleneck. If agents merge directly into main, semantic conflicts break production builds.

Gastown solves this with The Refinery—a dedicated integration and merge queue manager.

The 4-Stage Refinery Pipeline

1. Speculative Rebase: The Refinery pulls the next branch from the queue and speculatively rebases it onto the latest HEAD of main. 2. Full Regression Execution: The Refinery runs the full test suite in an isolated integration environment. 3. Automated Conflict Resolution: If a merge conflict or semantic type error occurs: The Refinery spawns a specialized Repair Subagent with a targeted prompt containing the conflicting AST diff and compiler error log. The Repair Subagent resolves the conflict and re-runs verification. 4. Fast-Forward Merge & Bead Finalization: Once verified clean, the Refinery fast-forward merges the branch into main, marks the corresponding Bead as DONE, and notifies the Mayor to unlock dependent tasks.

Traditional agent harnesses operate synchronously: the user submits a prompt, the agent generates a response, and the system halts until the user types another message.

Gastown operates on GUPP (Gastown Universal Propulsion Principle): > "If work exists on an agent's hook, it must be executed immediately without waiting for human permission."

Event-Driven Autonomous Execution

Under GUPP: The Mayor continuously inspects the Beads dependency graph. As soon as prerequisite tasks complete, dependent Beads transition from `BLOCKED` to `QUEUED`. Idle Polecats immediately claim queued Beads from their hooks and begin execution. * The system behaves like a continuous background compilation pipeline rather than an interactive chat room.

1┌─────────────────────────────────────────────────────────────┐2│                    THE GUPP EVENT LOOP                      │3│                                                             │4│   Bead Unlocked ──> Claimed by Hook ──> Worktree Spawn      │5│                                              │              │6│   Refinery Merge <── Verified Diff <── Automated Execution  │7└─────────────────────────────────────────────────────────────┘

By converting multi-agent execution into an asynchronous event-driven loop, developers can assign large epics (e.g., "Refactor 200 API routes from Express to Hono") and let the Gastown factory execute 30 parallel workstreams autonomously.

To understand where Gastown fits in the broader AI engineering ecosystem, compare its architecture against standard industry multi-agent frameworks:

Detailed Framework Comparison

• LangGraph / AutoGen: Excellent for complex graph-based conversational logic and structured multi-agent dialogue, but lacks native filesystem isolation, Git worktree provisioning, or durable external task databases.
• CrewAI: Provides intuitive persona abstractions ("Researcher", "Writer"), but sessions are memory-bound and susceptible to context rot on multi-hour coding refactors.
• Claude Agent SDK (Anthropic): Provides robust subagent spawning and MCP integration; Gastown builds on top of these primitives by adding durable Beads databases, Witness supervisors, and Refinery merge queues.

1# Multi-Agent Paradigm Matrix2┌──────────────────────┬─────────────┬─────────────┬─────────────┬─────────────┐3│ Capability           │ AutoGen     │ CrewAI      │ Claude SDK  │ Gastown     │4├──────────────────────┼─────────────┼─────────────┼─────────────┼─────────────┤5│ Primary Metaphor     │ Conversat.  │ Personas    │ Subagents   │ Factory Rig │6│ Task State Storage   │ In-Memory   │ In-Memory   │ Context     │ Git Beads   │7│ Worktree Isolation   │ No          │ No          │ Manual      │ Built-in    │8│ Merge Queue Manager  │ No          │ No          │ No          │ Refinery    │9│ Supervisor Watchdog  │ No          │ No          │ Partial     │ Witness     │10│ Concurrency Target   │ 2-4 agents  │ 3-5 agents  │ 5-10 agents │ 20-30+      │11└──────────────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

You do not need to rewrite your entire toolchain to benefit from Gastown's architectural lessons. You can implement Gastown's core engineering principles directly in your own agent harnesses today:

4 Practical Steps to Upgrade Your Agent Infrastructure

1. Externalize Task State into Markdown / SQLite: Instead of maintaining task lists in prompt text, write tasks to a local `.tasks/` or `beads.json` file. Have agents update task status on disk using structured tool calls.

2. Always Execute in Git Worktrees: Before launching an autonomous coding agent, run `git worktree add .worktrees/agent-task-name`. Keep your main working directory clean and protected from accidental regressions.

3. Implement a Deterministic Verification Gate (Ralph Loop): Never trust an agent's self-reported "I have completed the task." Require an automated script to run npm run build and npm test with exit code 0 before accepting the diff.

4. Add Automated Watchdogs for Long-Running Sessions: * Wrap agent processes in a supervisor script that enforces timeout caps, monitors log output deltas, and automatically terminates stalled sessions.

By grounding AI coding agents in distributed systems architecture—external state, process isolation, health supervision, and merge queues—engineering teams unlock reliable, industrial-scale autonomous software engineering.