GUPP — Gas Town Universal Propulsion Principle
Source: Steve Yegge, "Welcome to Gas Town," Jan 1, 2026
Related: [[steve-yegge-gas-town]], [[steve-yegge-beads]], [[steve-yegge-hierarchy]]
Why GUPP Exists
Most agentic systems — and most people's intuition about AI agents — follows an ask-then-wait model: you present a task, the agent works on it, you wait for a response. This is the SaaS mental model: request comes in, response goes out. It works fine for single-agent interactions but completely breaks down in multi-agent orchestration.
In a multi-agent system where agents can spawn sub-agents, wait for results, hand off work, and defer to later, yielding is contagious. If Agent A yields while waiting for Agent B, and Agent B yields while waiting for Agent C, the entire pipeline stalls. The system becomes a synchronous call chain masquerading as an asynchronous agent swarm.
GUPP exists to eliminate this class of failure entirely. The hook is a data structure (implemented as a Bead queue in Gas Town's architecture) representing pending work assigned to a given agent. GUPP's rule is absolute: if your hook is non-empty, you are running. No exceptions, no deferring, no "I'll check back later."
GUPP and the Deacon
The natural failure mode of GUPP is a stuck agent — an agent whose hook is non-empty but which has stopped processing (crashed, deadlocked, or gone off into an infinite loop). Gas Town addresses this with the Deacon daemon (see [[steve-yegge-hierarchy]]).
The Deacon patrols all hooks in the system. If any hook has been non-empty for longer than a configured timeout, the Deacon kills the responsible agent and re-queues the Bead for another agent to claim. This is the operationalization of GUPP: the principle says "always run," and the Deacon ensures that "always" actually means always.
Yegge describes early versions of Gas Town as plagued by "worker corpses" — polecats that had stopped processing but whose hooks still showed pending work. The Deacon was added specifically to handle this failure mode.
Kelly Parallel
| GUPP Concept | Kelly Equivalent |
|---|---|
| Hook-based work assignment | Kelly's **sub-agent spawning** — parent spawns child with specific work; child must execute |
| GUPP's "no yielding" rule | Kelly's **autonomous continuation** — agents continue working without requiring the parent to poll or re-invoke |
| Deacon timeout enforcement | Kelly's **heartbeat check-in** mechanism — periodic liveness signals detect stuck agents |
| Re-queuing on failure | Kelly's **retry/re-spawn** on sub-agent failure within the router pattern |
| "Always running when work exists" | Kelly's **cron-driven heartbeat** + **TaskFlow background jobs** — persistent execution vs event-driven yield |
Key gap: Kelly has no formal equivalent to GUPP's absolute "must-run-when-hook-is-non-empty" rule. Kelly's autonomous continuation is respected in practice (sub-agents run to completion), but there is no hook-based mechanism that enforces it at the architectural level. A Kelly-style system would benefit from GUPP's framing: work persistence via hooks, with a Deacon-equivalent to handle the stuck-agent problem.
Kelly's heartbeat serves a similar operational function to the Deacon (detecting stuck agents), but heartbeat is file-based and requires the agent to actively update it. The Deacon is a daemon that actively patrols. GUPP's approach is more robust because the enforcement is external to the agent itself.