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

Definition

GUPP (Gas Town Universal Propulsion Principle) is the core execution axiom of the Gas Town orchestrator:

If there is work on your hook, you MUST run it. No yielding, no waiting — relentless execution.

That's the entire principle. It sounds simple. It is simple. And it is the reason most agent frameworks fail.

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."

The Hook

The hook is GUPP's mechanism. Each agent in Gas Town has a hook — a queue of Beads representing work assigned to it. When a Mayor assigns a Bead to a polecat, that polecat's hook is non-empty. GUPP dictates that the polecat must immediately begin processing.

In practice, the hook is not a simple FIFO queue. Gas Town's hook supports:

  • Priority ordering — critical Beads can preempt lower-priority ones
  • Dependency tracking — a Bead may not be actionable until a parent Bead is complete
  • Timeout semantics — stale Beads on a hook trigger the Deacon to intervene (see steve-yegge-hierarchy)

But these are implementation details. The GUPP principle is clean: non-empty hook → running. End of story.

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.

GUPP vs Yielding

The contrast with the "normal" agent mental model is stark:

Behavior GUPP (Gas Town) Standard Agent Framework
Empty hook Idle (ok) Idle (ok)
Non-empty hook Must run immediately May defer, batch, or schedule
Waiting on sub-agent Work continues on other hook items Blocked until sub-agent returns
Sub-agent fails Bead re-queued; operator notified Propagation up call chain; possible total failure
Timeout Deacon kills and re-queues Varies; often no timeout enforcement

The key insight: GUPP treats the hook as a promise — when work appears on your hook, you are contractually obligated to execute it. Standard agent frameworks treat the hook as advice — nice to have, worth processing when convenient.

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.

Source Attribution

  • Steve Yegge, "Welcome to Gas Town," Jan 1, 2026 — GUPP introduced as the core execution axiom of Gas Town

Bibliography

steve-yegge-beads, steve-yegge-gas-town, steve-yegge-hierarchy