Gas Town’s Agent Patterns, Design Bottlenecks, and Vibecoding at Scale
2 points by Corbin
2 points by Corbin
There are two other Gas Town retrospectives this week, previously, on Lobsters and previously, on Lobsters. This one is interesting to me because it reverse-engineers the structure of Gas Town. Apologies in advance for using Yegge's terminology; please read the article first.
Yegge and others talk of Gas Town as an orchestrator. Let's make some simplifying assumptions and see what that would look like when properly engineered. We'll keep the human as Overseer and orchestrate a single machine. Every subagent relationship can be recast as a daemontools-style supervision relationship between services. We'll let the process supervisor take care of pings, so that the Boot and Dogs aren't needed. The Crew are like system services; the Permanent Crew are like boot-time services. Assuming that the Mayor can be replaced with an IDE which produces the tasks, it seems like the main workflow is for the user to create tasks which the system eventually merges within the Refinery. In terms of mutation, I reasoned that the tasks are the only things which meaningfully mutate relative to the rest of the system's state; all of the chatbot actions can be synchronized and turned into main effects, so the only side effects left are acting on tasks or the real world.
There's an entire facet to k8s-style orchestration which is absent from Gas Town: where are the Objects which the Controllers reconcile? Perhaps they are the Beads themselves. The Polecats do not act upon Beads in a coherent or holistic way; it's possible for a Polecat to fondly regard a Bead indefinitely. If so, then the Refinery generalizes all code changes, akin to something Spinnaker-shaped, which is fun until the Refinery starts overseeing itself. Maybe Dogs are humans too; maybe they're the humans who get paged when the cluster merges bad code to itself.
In the original Yegge post, there's this feeling of urgency around task creation. Gas Town is hungry for things to do. But we want orchestrated clusters to eventually settle into a quiescent state, both to save energy and to be simple to analyze over time. Any sort of queue or backlog should be the result of overly demanding management spending an afternoon typing tickets into the Mayor rather than an insistence that the system load should be a metric to maximize.
My takeaway is that Gas Town is a first-order scheduler that only has limited visibility into itself. It cannot be a true Gödel machine unless it can modify every part of itself. When we strip away the LLMs, the underlying structure can be mapped to a standard process-supervision tree rather than some new LLM-invented object.