What Makes Gas Town Different

aidebatable

Four genuine innovations that enable autonomous multi-agent systems.

Not complexity. Four simple ideas applied consistently that enable 20-30 agents working autonomously for days.

Skip the orchestration hype. This is how it actually works.

The Core Insight

It's Not About Orchestration. It's About Self-Propulsion.

Most agent frameworks have an orchestrator at the center: something that pushes work to agents, monitors them, handles failures, reassigns. Gas Town inverts this entirely. Work is attached to agents and executes itself.

Traditional Multi-Agent
  • × Central orchestrator bottleneck
  • × Session death = work death
  • × State files that lie
  • × Mechanical health checks
  • × Context limits matter
  • × Crashes need intervention
Gas Town
  • ✓ Work propels itself via hooks
  • ✓ Sessions disposable, sandbox persists
  • ✓ Reality is the source of truth
  • ✓ AI patrol with judgment
  • ✓ Context externalized to git
  • ✓ Self-healing by design

The key realization: autonomous multi-agent coordination doesn't require complex orchestration. It requires four simple primitives that reinforce each other: self-propelling work, ephemeral sessions, observable state, and AI patrol.

Insight #1

Work Propels Itself

Most agent systems have an orchestrator that pushes work to agents. Gas Town inverts this: work is attached to agents and executes itself.

Traditional
Orchestrator polls for work, assigns to agent, monitors completion, handles failures, reassigns. The orchestrator is a bottleneck and single point of failure.
Gas Town
Work is written to agent's hook_bead. When session starts, hook fires automatically. Agent runs work. No orchestrator needed.
WORK ASSIGNMENT FLOW

  gt sling issue-123 polecat/Toast
       │
       ▼
  writes hook_bead field to agent's database row
       │
       ▼
  session starts
       │
       ▼
  SessionStart hook fires → gt prime --hook
       │
       ▼
  agent reads hook → executes work → gt done

Why this matters: if an agent crashes mid-work, the hook is still set. Next session starts, hook fires, work continues. Zero human intervention. The work itself is the propulsion mechanism.

Insight #2

Sessions Die, Sandboxes Live

The key insight: agent identity and work state are completely decoupled from the session (context window).

Traditional
Agent session = agent state. When context fills, you either lose history or pay for expensive context management. Session death = work death.
Gas Town
Session is disposable. Sandbox (git worktree + branch + beads) persists. Kill session anytime. New session inherits full state via git and hook.
SESSION LIFECYCLE

  Session 1 → dies → Session 2 → dies → Session 3 → ... → Session N
      │                 │                 │                    │
      └─────────────────┴─────────────────┴────────────────────┘
                                  │
                                  ▼
      Same branch. Same worktree. Same bead state. Accumulated cv_chain.

Why this matters: context windows are finite. Gas Town treats them as expendable resources. An agent can work for days across hundreds of sessions without losing context, because context is externalized to git.

Insight #3

Observable State, Not Stored State

Gas Town doesn't track state in files. It observes reality directly: tmux sessions, git branches, beads database.

Traditional
State file says agent is running. But process crashed. State file is now lying. System is confused. Manual intervention required.
Gas Town
Is tmux session alive? That's the truth. Is branch pushed? Check git. What's the hook? Query beads. Reality is the source of truth.

This is called ZFC (Zero-File-Config). The daemon doesn't read state files. It observes:

STATE OBSERVATION

  Session alive?  → tmux has-session -t name
  Current work?   → SELECT hook_bead FROM agents
  Changes pushed? → git log origin/branch..HEAD

Why this matters: state files corrupt. Processes crash between write and flush. By observing reality instead of tracking state, Gas Town eliminates an entire class of consistency bugs. Recovery is always possible because truth is discoverable.

Insight #4

AI in the Patrol Loop

The Witness isn't a script. It's an AI agent that makes judgment calls about other agents.

Traditional
Health check: no output for 5 minutes = dead. But what if the agent is thinking about a hard problem? False positive. Kill productive work.
Gas Town
Witness (AI) checks agent. Reads recent output. Understands context. Decides: "still thinking" vs "actually stuck" vs "needs help".

The patrol hierarchy uses graduated intelligence:

PATROL HIERARCHY

  Daemon   │ Mechanical. 3-min heartbeat. Detects obvious failures.
           ▼
  Deacon   │ AI. Town-wide triage. Handles cross-rig issues.
           ▼
  Witness  │ AI. Per-rig intelligence. Understands agent context.
🔍
Contextual Judgment
AI patrol reads agent output and reasons about whether silence is productive or problematic.
🛡️
No False Positives
Mechanical checks can't understand nuance. AI watching AI prevents killing productive work.
🔄
Intelligent Recovery
Witness can decide to restart, reassign, or escalate based on actual understanding of the situation.
📊
Graduated Response
Daemon handles the obvious, Deacon coordinates across rigs, Witness handles nuanced per-agent decisions.

Why this matters: mechanical health checks can't understand nuance. An AI watching AI can reason about whether silence is productive or problematic. This prevents false positives while catching real failures.

The Synthesis

Why These Four Together

Each insight enables the others. Remove one and the system degrades.

THE GAS TOWN COMPOSITION

  Self-propelling work   → No orchestrator bottleneck
        +
  Ephemeral sessions     → Context limits don't matter
        +
  Observable state       → Crashes don't corrupt
        +
  AI patrol              → Intelligent recovery, no false positives

  ════════════════════════════════════════════
                        │
                        ▼

  Agents that run for days without human intervention.
  20-30 agents working on a shared codebase, cycling
  through sessions, self-healing from failures, for
  as long as there's work to do.
Why others struggle
They optimize orchestration logic instead of the primitives that make orchestration unnecessary.
Why Gas Town works
It treats sessions as disposable, work as self-propelling, state as observable, and patrol as judgment-based.

The Deeper Pattern

What's actually happening here is simple: the system externalizes everything fragile and automates only what can be made durable.

  • Context is fragile → externalize it to git and beads
  • Sessions are fragile → make them disposable
  • State files are fragile → observe reality directly
  • Mechanical health checks are fragile → put AI where judgment is required

That is the pattern. Not agent orchestration. Not prompt engineering. System design that assumes LLMs and processes will fail, then routes around those failures by construction.

This is why Gas Town feels qualitatively different from most multi-agent demos. It's not more complicated. It's more honest about where reality breaks.