Stateless Agent Methodology vs Gas Town
A comparative analysis of two approaches to working effectively with LLM agents at different scales.
Executive Summary
Both methodologies address LLM agent limitations but target fundamentally different scales and concerns. Both recognize that Claude is not a knowledge worker—Claude is a stateless computation engine.
| Aspect | Stateless Agent Methodology | Gas Town |
|---|---|---|
| Origin | Theoretical framework from observed failure modes | Production multi-agent orchestration system |
| Scale | Single agent, sequential stages | 20-30+ concurrent agents across multiple projects |
| Primary Problem | Agent self-assessment failure | Agent coordination at enterprise scale |
| State Model | Stateless sessions + persistent artifacts (externalized memory) | Persistent identities + durable work graphs in a git-backed data plane |
| Implementation | Conceptual methodology | Orchestrator system described in “Gas Town” |
Problem Statement Comparison
Stateless Agent Methodology
Focuses on why individual agents fail:
- Long-context degradation (“context rot”): performance can drop as context length increases (including “lost in the middle” effects); avoid long sessions by bounding context per task/stage
- Knowledge cutoff / stale priors: the model can choose plausible but outdated patterns unless forced to ground against current sources/tools
- Cannot perform JIT knowledge gap identification
- Optimizes for apparent completion over correct completion
- Non-deterministic generation must be constrained by deterministic backpressure (tests/lint/static analysis/checklists) treated as ground truth
Gas Town
Focuses on why multi-agent systems fail:
- Agents lose context on restart
- Manual coordination doesn't scale
- Chaotic state in multi-agent environments
- Lost work when sessions crash
- No attribution or accountability
Overlapping Concerns
| Concern | Stateless Approach | Gas Town Approach |
|---|---|---|
| Context limits | Bound context per task/stage (avoid “everything in one prompt”) | Session recycling + durable work graphs + hook/queue semantics |
| Work tracking | Task files with constraints + verification steps | Beads ledger (git-backed) + activity/event trail |
| Verification | Independent forensic phase + deterministic checks | Multi-role oversight + merge/quality gates + deterministic checks |
| Coordination | Orchestrator dispatches workers | Durable coordination plane (mail/inboxes, queues/hooks, patrols/nudges) |
Architectural Comparison
Stateless Agent Methodology: Linear Stages
Discovery → Planning (RT-ICA) → Context Integration → Task Decomposition → Execution → Forensic Review
→ Orchestration Loop ↺ (dispatches follow-up tasks back to Execution as needed) → Final Verification
Each stage:
- Receives complete context
- Produces artifacts for next stage
- No memory dependency between stages
Gas Town: Persistent Mesh Architecture
┌─────────┐
│ Mayor │ (coordinates all)
└────┬────┘
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Rig A │ │ Rig B │ │ Rig C │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ Witness │ │ Witness │ │ Witness │
│Refinery │ │Refinery │ │Refinery │
│Polecats │ │Polecats │ │Polecats │
└─────────┘ └─────────┘ └─────────┘
Core entities:
- Mayor: Chief coordinator with cross-rig visibility
- Witness: Per-rig monitor for agent health
- Refinery: Per-rig merge queue processor
- Polecats: Ephemeral worker agents
- Deacon: System daemon watchdog
Core Concepts Mapping
| SAM Concept | Gas Town Equivalent | Key Difference |
|---|---|---|
| Stage | Molecule step | Molecules can span agent restarts |
| Task file | Bead | Beads persist in git, not files |
| Orchestrator | Mayor | Mayor coordinates multiple rigs |
| Execution agent | Polecat | Polecats are ephemeral by design |
| Forensic agent | Witness | Witness also handles nudging/cleanup |
| Task queue | Hook | Hooks are pinned Beads per agent |
| Artifact | Bead closure + git commit | Everything attributed and tracked |
State Management Philosophy
Stateless Agent Methodology
Principle: Statelessness is a feature, not a limitation.
- Each phase receives complete context
- No phase depends on agent "remembering"
- Task files contain all answers
- Fresh sessions + bounded context reduce long-context degradation pressure, but do not eliminate the need for deterministic verification
Implementation: Phase artifacts are the only state.
Gas Town
Principle: State must survive agent death.
- Work persists in git-backed hooks
- Agents spawn fresh but find work waiting
- Handoff mechanism transfers context between sessions
- Seance system queries previous sessions for history
Implementation: Three persistence layers:
| Layer | Component | Lifecycle |
|---|---|---|
| Session | Claude (tmux pane) | Ephemeral, cycles per step |
| Sandbox | Git worktree | Persistent until nuke |
| Slot | Name from pool | Persistent until nuke |
Key Insight
Stateless methodology says: "Don't rely on state—provide complete context."
Gas Town says: "State will be lost—persist it externally so agents can recover."
Both acknowledge the same problem; different solutions for different scales.
Execution Models
Stateless: Sequential Phases
Phase 1 completes → Artifact → Phase 2 starts → Artifact → Phase 3 starts ...
- One agent per phase (conceptually)
- Phases are independent units
- Sequential by design
- Parallelism not addressed
Gas Town: Propulsion Loop
1. gt hook # What's hooked?
2. bd mol current # Where am I in molecule?
3. Execute step
4. bd close <step> --continue # Close and auto-advance
5. GOTO 2
GUPP (Gas Town Universal Propulsion Principle):
"If there is work on your Hook, YOU MUST RUN IT."
- No confirmation needed
- No waiting for external input
- The hook IS the assignment
- Prevents stalling
Parallelism Comparison
| Aspect | Stateless | Gas Town |
|---|---|---|
| Concurrent agents | Not addressed | 20-30+ |
| Work distribution | Orchestrator dispatches | Slinging via gt sling |
| Dependency tracking | Phase order | Formula dependencies + topological sort |
| Synchronization | Phase boundaries | Mail protocol + Convoy tracking |
Agent Coordination
Stateless Methodology
Implicit coordination through artifacts:
- Discovery agent produces requirements
- Planning agent (RT-ICA) reads requirements, produces plan and prerequisite checks
- Context integration agent grounds the plan in the actual codebase/external sources
- Task decomposition agent produces executable tasks (inputs + constraints + verification steps)
- Execution agent implements tasks under deterministic backpressure
- Forensic review agent evaluates outputs against acceptance criteria and tool output
- Orchestrator loops: dispatches follow-up tasks back to Execution until convergence
- Final verification agent performs a final, end-to-end correctness check
Coordination mechanism: Artifacts passed between phases.
Gas Town
Explicit coordination through mail protocol:
| Message | Sender | Receiver | Purpose |
|---|---|---|---|
| POLECAT_DONE | Polecat | Witness | Signal work completion |
| MERGE_READY | Witness | Refinery | Branch ready for merge |
| MERGED | Refinery | Witness | Safe to cleanup |
| MERGE_FAILED | Refinery | Witness | Recovery needed |
Additional mechanisms:
- Nudging: Real-time messaging via
gt nudge - Handoff: Session refresh via
/handoff - Seance: Query previous sessions via
gt seance
Work Decomposition
Stateless Methodology
Feature → Requirements → Design → Tasks → Subtasks
Task files contain:
- Exact constraints
- Files to modify
- Style to follow
- Methodology to use
- Verification steps
- Definition of done
Gas Town (MEOW - Molecular Expression of Work)
Epic → Feature → Task → Bead → Molecule Step
Hierarchy:
| Level | Description | Tracking |
|---|---|---|
| Epic | Large goal | Bead with children |
| Feature | Logical unit | Bead with children |
| Task | Atomic work | Bead |
| Molecule | Multi-step workflow | Persistent, survives restarts |
| Step | Single action | Auto-advances via --continue |
Formula types:
- Workflow: Sequential steps with dependencies
- Convoy: Parallel legs with optional synthesis
- Expansion: Template-based parameterized workflows
- Aspect: Multi-aspect parallel analysis
Attribution and Accountability
Stateless Methodology
Not explicitly addressed. Implicit through:
- Task files record what was requested
- Forensic phase verifies completion
- Orchestrator tracks task status
Gas Town
Comprehensive attribution system (BD_ACTOR format):
mayor # Town-level
deacon # Town-level
gastown/witness # Rig-level
gastown/refinery # Rig-level
gastown/crew/joe # Crew member
gastown/polecats/toast # Polecat worker
Three-level attribution:
- Git commits:
GIT_AUTHOR_NAMEtracks who did work - Beads records:
created_by/updated_byfields - Event logging: All events include actor attribution
Benefits:
- Compliance audits
- Agent capability tracking (CV growth)
- Performance management
- Skill-based routing
Failure Handling
Stateless Methodology
| Failure Mode | Mitigation |
|---|---|
| Training data hallucination / stale priors | Grounding + explicit constraints + deterministic backpressure (treat tool output as ground truth) |
| Skipping prerequisites | Assessment phase blocks planning |
| Apparent vs actual completion | Forensic phase verification |
| Long-context degradation | Bounded context per task/stage + artifacts as source of truth |
Recovery: Manual intervention via orchestrator.
Gas Town
| Failure Mode | Mitigation |
|---|---|
| Agent crash | Hook persists, work recoverable |
| Stalled session | Witness nudges or respawns |
| Zombie agent | Witness cleanup protocol |
| Merge conflict | Refinery retry with intelligent resolution |
| Lost context | Handoff protocol + seance history |
Polecat states:
| State | Description | Recovery |
|---|---|---|
| Working | Actively executing | Normal operation |
| Stalled | Session stopped mid-work | Witness nudge |
| Zombie | Completed but failed to exit | Witness cleanup |
Key insight: No idle state. Polecats work or die.
Verification Models
Stateless: Independent Forensic Phase
Execution → Forensics → Complete/Incomplete → (loop if incomplete)
- Forensic agent validates against plan
- Reports status objectively
- Orchestrator creates follow-up tasks
Gas Town: Multi-Layer Verification
┌─────────────┐
│ Deacon │ (system health)
└──────┬──────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Witness │ │ Witness │ │ Witness │ (per-rig)
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│Refinery │ │Refinery │ │Refinery │ (merge gates)
└─────────┘ └─────────┘ └─────────┘
- Witness: Monitors polecats, handles failures
- Refinery: Merge queue with quality gates
- Deacon: System-wide watchdog
NDI (Nondeterministic Idempotence): Ensures useful outcomes even with unreliable processes through persistent Beads and oversight agents.
Scale Comparison
| Dimension | Stateless Methodology | Gas Town |
|---|---|---|
| Agents | 8 stages (incl. orchestration loop + final verification) | 20-30+ concurrent |
| Projects | Single feature | Multiple rigs (projects) |
| Organization | Single team | Federation across orgs |
| State persistence | No session memory; persistence lives in artifacts | Git-backed durable data plane |
| Tooling | None (methodology only) | Full CLI (gt, bd) |
| Runtime | Any LLM agent | Claude Code / Codex |
Enterprise Features (Gas Town Only)
Features not addressed by Stateless Methodology:
| Feature | Gas Town Implementation |
|---|---|
| Federation | Register and query remote workspaces |
| Model A/B testing | Deploy different LLMs on comparable tasks |
| Capability routing | Match work to agents by proven skills |
| Agent CVs | Track record of completed work |
| Real-time feed | Stream of system state changes |
| Cross-org visibility | Multi-team coordination |
Complementary Insights
What Gas Town Validates from Stateless Methodology
- Externalized assessment: Witness/Deacon separate from execution
- Complete context per unit: Hooks contain all work state
- Fresh sessions work: Polecats spawn fresh, find work waiting
- Verification independence: Refinery gates separate from execution
What Gas Town Adds
- Persistence layer: Work survives agent death
- Attribution system: Who did what, when, why
- Scale mechanism: Coordination for dozens of agents
- Recovery protocols: Nudge, handoff, seance
- Quality routing: Match work to capable agents
What Stateless Methodology Clarifies
- Why agents fail: Core dysfunction analysis
- Theoretical foundation: Principles behind the patterns
- Minimal viable process: 8-stage pipeline (incl. orchestration loop + final verification) without tooling overhead
- Agent-agnostic: Not tied to specific runtime
Synthesis: When to Use Each
Use Stateless Agent Methodology When
- Working with single agent or small team
- Need conceptual framework before tooling
- Target runtime is not Claude Code
- Emphasizing principles over implementation
- Teaching/explaining LLM agent design
Use Gas Town When
- Coordinating 5+ concurrent agents
- Need attribution and accountability
- Enterprise compliance requirements
- Multi-project orchestration
- Recovery from agent failures is critical
- Scale is the primary concern
Use Both When
- Designing new multi-agent systems
- Need theoretical grounding + practical implementation
- Building custom orchestration (use stateless principles, gas town patterns)
- Debugging coordination failures (stateless explains why, gas town shows how)
Architectural Pattern Comparison
Stateless: Pipeline Architecture
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│Discover│───▶│ Plan │───▶│Execute │───▶│ Verify │
│ │ │ │ │ │ │ │
│Complete│ │Complete│ │Complete│ │Complete│
│context │ │context │ │context │ │context │
└────────┘ └────────┘ └────────┘ └────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│Artifact│ │Artifact│ │Artifact│ │Artifact│
└───────┘ └───────┘ └───────┘ └───────┘
Gas Town: Mesh + Queue Architecture
┌─────────────────┐
│ Deacon │
│ (watchdog) │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Mayor │────────▶│ Convoy │◀────────│ Mail │
│(coord) │ │(batch) │ │(queue) │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ Rig │ │ Rig │ │ Rig │
│┌───────┐│ │┌───────┐│ │┌───────┐│
││Witness││ ││Witness││ ││Witness││
│├───────┤│ │├───────┤│ │├───────┤│
││Refnry ││ ││Refnry ││ ││Refnry ││
│├───────┤│ │├───────┤│ │├───────┤│
││Polcats││ ││Polcats││ ││Polcats││
│└───────┘│ │└───────┘│ │└───────┘│
└─────────┘ └─────────┘ └─────────┘
Conclusion
The Stateless Agent Methodology and Gas Town represent different points on the complexity spectrum.
| Dimension | Stateless | Gas Town |
|---|---|---|
| Complexity | Low (conceptual) | High (production) |
| Scale | 1-5 agents | 20-30+ agents |
| State | Stateless sessions + persisted artifacts | Persistent identities + durable work graphs |
| Focus | Why agents fail | How to coordinate many |
| Value | Principles | Implementation |
Key insight: Stateless methodology explains why certain patterns work. Gas Town implements those patterns at scale with the additional machinery needed for enterprise coordination.
They are not alternatives—they are different abstraction levels of the same fundamental understanding: LLM agents cannot self-assess, so systems must externalize assessment, provide complete context, and verify independently.
- Stateless Agent Methodology = Theory for single-agent reliability
- Gas Town = Implementation for multi-agent coordination
Together they span from "why does this work?" to "how do I run 30 agents across 5 projects?"
References
- Stateless Agent Methodology
- Stateless Software Engineering Framework
- Welcome to Gas Town (Yegge, 2026-01-01) (accessed 2026-01-26)
- Repo evidence (accessed 2026-01-26): README.md, go.mod