# 743 Sam Vs Gastown 5c1ebae8 > Stateless Agent Methodology vs Gas Town - Skill: `tools-only/743-sam-vs-gastown-5c1ebae8` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/743-sam-vs-gastown-5c1ebae8` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/743-sam-vs-gastown-5c1ebae8/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tools-only/743-sam-vs-gastown-5c1ebae8 --- # 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 --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: 1. Discovery agent produces requirements 2. Planning agent (RT-ICA) reads requirements, produces plan and prerequisite checks 3. Context integration agent grounds the plan in the actual codebase/external sources 4. Task decomposition agent produces executable tasks (inputs + constraints + verification steps) 5. Execution agent implements tasks under deterministic backpressure 6. Forensic review agent evaluates outputs against acceptance criteria and tool output 7. Orchestrator loops: dispatches follow-up tasks back to Execution until convergence 8. 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**: 1. **Git commits**: `GIT_AUTHOR_NAME` tracks who did work 2. **Beads records**: `created_by`/`updated_by` fields 3. **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 1. **Externalized assessment**: Witness/Deacon separate from execution 2. **Complete context per unit**: Hooks contain all work state 3. **Fresh sessions work**: Polecats spawn fresh, find work waiting 4. **Verification independence**: Refinery gates separate from execution ### What Gas Town Adds 1. **Persistence layer**: Work survives agent death 2. **Attribution system**: Who did what, when, why 3. **Scale mechanism**: Coordination for dozens of agents 4. **Recovery protocols**: Nudge, handoff, seance 5. **Quality routing**: Match work to capable agents ### What Stateless Methodology Clarifies 1. **Why agents fail**: Core dysfunction analysis 2. **Theoretical foundation**: Principles behind the patterns 3. **Minimal viable process**: 8-stage pipeline (incl. orchestration loop + final verification) without tooling overhead 4. **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-agent-methodology.md) - [Stateless Software Engineering Framework](./stateless-software-engineering-framework.md) - [Welcome to Gas Town (Yegge, 2026-01-01)](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04) (accessed 2026-01-26) - Repo evidence (accessed 2026-01-26): [README.md](https://github.com/steveyegge/gastown/blob/main/README.md), [go.mod](https://github.com/steveyegge/gastown/blob/main/go.mod)