Steve’s Term</th>	Real-World Definition</th>	Alternative Term</th></tr></thead>
Town</td>	Top-level folder containing your individual projects. The `gt</code> binary manages projects under this folder.</td>`	Workspace</td></tr>
Rig</td>	A project. It’s a folder tracked by a unique Git repository within your workspace.</td>	Project</td></tr>
Overseer</td>	The user (you). You have an “inbox” to receive notifications from agents in your projects.</td>	User</td></tr>
Mayor</td>	The managing agent for a project. Usually you send this agent messages, and it coordinates the work of other agents in the project.</td>	Manager Agent</td></tr>
Polecat</td>	Worker agent, taking commands from the mayor, doing some work, submitting a Merge Request, and then stopping.</td>	Worker Agent</td></tr>
Refinery</td>	Merge agent, who coordinates and makes decisions about merge requests coming from Worker Agents.</td>	Merge Agent</td></tr>
Witness</td>	Fixer agent, that watches the worker agents and tries to fix any that are stuck.</td>	Fixer Agent</td></tr>
Deacon</td>	Maintenance agent, runs a consistent workflow in a loop, unlike “worker agents” who do arbitrary tasks and then die.</td>	Maintenance Manager Agent</td></tr>
Dogs</td>	Maintenance worker agents who do cleanup tasks, directed by the Maintenance Agent.</td>	Maintenance Worker Agents</td></tr>
Boot the Dog</td>	Maintenance Manager checker agent, just checks on the Maintenance Manager Agent periodically to see if it needs a reboot or anything else.</td>	Maintenance Manager Checker Agent</td></tr>
Crew</td>	Persistent Worker Agents, which you talk to directly (not through the Mayor), and which persist after their tasks are done, to be reused. These are per-Project.</td>	Persistent Worker Agents.</td></tr>
Beads</td>	System for tracking work history across the system.</td>	Work Tracker</td></tr>
Rig Beads</td>	Project-specific work, tracked in the Work Tracker.</td>	Project Work</td></tr>
Town Beads</td>	Whole-workspace work, tracked in the Work Tracker.</td>	Workspace Work</td></tr> </tbody></table> Even with these definitions and alternative terms, Gas Town is still a bit of a mess, with watchers-on-watchers at times (do we really need a Maintenance Manager Checker Agent?). That said, hopefully this decoder at least makes understanding what Gas Town is</em> easier.</p> Passkey PRFs and the Passkey Loss Blast Radius 2026-01-14T00:00:00+00:00 Yesterday, Ars Technica reported</a> on Confer</a>, an AI company created by Moxie Marlinspike</a>, who also created the secure messaging app/protocol Signal</a>.</p> In Confer’s blog post “Making end-to-end encrypted AI chat feel like logging in,”</a> Moxie writes about how Confer uses passkey PRFs to encrypt chats. As the blog post describes, the PRF extension allows Confer to derive a new key deterministically from a user’s passkey, so they can then use this new key to encrypt other material.</p> While passkey PRFs are powerful, and have legitimate uses, they carry a real risk: passkey PRFs increase the blast radius of passkey loss.</strong></p> When a passkey PRF is used to encrypt material associated with a user, and that user loses their passkey, the encrypted material is also lost. Today, if a user loses a passkey used to log in to a service, they can usually recover their account somehow</em>, but if materials tied to that account were encrypted with a passkey PRF, those materials are gone even when the user regains account access.</p> Passkey loss can happen for many reasons! Loss of a device or hardware token for keys that aren’t synced, lockout from a platform (such as an Apple ID) for passkeys kept in a platform-specific keystore, or even a user’s death for passkeys whose decryption mechanism expects biometrics. The fact that people have repeatedly lost cryptocurrency keys worth enormous sums of money shows that even with strong financial incentives, mistakes happen and keys get lost.</p> So while passkey PRFs are powerful</em> (they let you tie encryption material to an authenticated user’s private key), they also require platforms to prepare users for what they’d lose if their passkey is lost.</p> The Confer article lists alternatives, such as giving the user a long passphrase to remember (which many will forget or store insecurely), encrypting based on a user’s password (which is phishable), or using a device-key (which blocks cross-device access). These trade-offs make passkey PRFs compelling! It’s just worth remembering it’s not a free lunch.</p> 'Memory Safety for Skeptics' in the ACM Queue 2025-12-01T00:00:00+00:00 I’m a bit late to sharing it here, but an article of mine</a> was in the November issue of the ACM Queue! Called “Memory Safety for Skeptics,”</a> it argues for why memory safety is worth pursuing amid competing priorities. It was a lot of fun to write, and is purposefully not</em> an article about rewriting codebases in Rust. Check it out!</p> Tracking Software ID Schemes 2025-04-10T00:00:00+00:00 Part of my life is working on the problem of software identification. I’m on the Core Team for OmniBOR</a>, a reproducible software identifier scheme, and my other work in software supply chain security and vulnerability management often bumps up against challenges with identifying software at differing levels of granularity, mapping vulnerabilities or SBOMs (Software Bills of Material) to specific software.</p> It may surprise you to learn there are a lot of software identifier schemes. Some of them are general purpose and used across different ecosystems, while some are ecosystem or even tool- or API-specific.</p> To help track those identifiers and link to their specifications, I’ve made a new Software ID tracker</a>. It’s up on GitHub</a> and contributions are welcome!</p> The Best Monad Tutorial Ever Written 2025-02-19T00:00:00+00:00 When Rain</a> mentioned recently they had a draft monad tutorial that explains them without mathematical jargon</em>, with practical examples</em>, and as a design pattern</em>, I knew it was going to be good. Of course, it is even better than I hoped</strong>.</p> “Demystifying monads in Rust through property-based testing”</a> is an undersell of a title. If you’ve floated around the world of functional programming long, you’ve probably seen one of the many attempts at explaining monads. Many are from the perspective of a formalism—the monad laws—and written with Haskell—the language that made them a central feature with syntactic sugar and a direct to how IO is done.</p> Rain instead introduces monads with a practical example of how their flexibility actually makes some work harder, motivated with a concrete example of how “shrinking,” a core operation for doing practical property-based testing, becomes much more difficult when monadic operations are used to generate test inputs. Instead of Haskell, the tutorial uses Rust.</p> Thanks Rain for the best monad tutorial I’ve ever read!</p> Jujutsu is the Future 2025-02-14T00:00:00+00:00 I’d like to stake a radical position: the Git</a> Version Control System (VCS) will be declining in popularity in 5 years, and Jujutsu</a> (`jj</code>) will be gaining popularity in its place.</p>` `Of course, Git is the most popular VCS today by a wide margin, with a large ecosystem of companies and tools built around it.</p>` `However, I believe Jujutsu will displace it for three reasons:</p>` `Jujutsu can be adopted locally on Git projects.</strong> You can use Jujutsu as an individual contributor on a project that doesn’t use it. It can be adopted incrementally by teams, and does not require a cutover from one VCS to another, which history has shown to be a slow, expensive, and difficult process.</li>`Jujutsu’s design makes dev work easier.</strong> Jujutsu has learned from Git, Mercurial, and others, and features a model which is, to paraphrase Steve Klabnik, “simpler and more powerful”</a> than Git’s. By removing edge cases and sources of complexity from Git, Jujutsu’s features compose better together, allow more powerful control over your commit history, and make day-to-day operations on collaborative software projects easier.</li> Jujutsu’s interface is easier to use.</strong> Not only is Jujutsu’s data model simpler and more powerful, but its Command Line Interface (CLI) is also much easier to understand than Git’s. This is both because</em> the data model is simpler (so fewer flags to handle edge cases are needed), and because the CLI itself is better designed. Flags are more consistent across commands, terminology is more consistent, undoing operations is predictable and much easier.</li> </ol> Of course, I may be wrong. Jujutsu is production ready for many users, but it has not reached version 1.0 yet. Displacing an entrenched technology is also difficult, and there are many ways it could go wrong.</p> Yet using Jujutsu, I have the same feeling I had writing Rust in 2014 as a C++ programmer: this is better. This is a system that makes many of the failure cases I’ve encountered impossible, and makes the few remaining tough cases much easier to resolve. Day-to-day, I find myself less worried about managing my changes to reduce the likelihood of possible merge conflicts; in fact I am rarely worried about conflicts at all. It’s easier to use, easier to teach, and lets me move faster and with more confidence.</p> One of Rust’s historic taglines was “Fearless Concurrency.”</a> Maybe Jujutsu’s should be “Fearless Collaboration.”</p> Safety Hygiene 2025-02-10T00:00:00+00:00 I really like Jack Wrenn’s new article “The Three Basic Rules of Safety Hygiene,”</a> which covers how to handle unsafe code when you have to write it, through a hygiene checklist for expressing and validating compliance with safety conditions in the code.</p> Rust’s goal is not to eliminate unsafe code, but to contain it in isolated modules</a> you can audit</a> and which provide safe interaces to external users. Sometimes unsafety is necessary, and having a process</em> for how to handle that unsafety is a key development.</p> Research on how to reduce things like industrial accidents, medical incidents, and airplane crashes all consistently find that checklists and procedures work</em>. Humans are fallible, and being accountable to a checklist or a process defends against our propensity to make mistakes.</p>

Andrew Lilley Brinker - Miniblog

Move Over Gas Town, Claude Has First-Party Agent Orchestration

2026-02-05T00:00:00+00:00

While Gas Town</a>, the hallucinatory fever dream / slopware project by Steve Yegge, was first on the scene for agent orchestration, it was never going to be the end. Gas Town, as Yegge himself admitted, is an experiment intended to explore the limits and problems of agent orchestration without concern for cost or quality. It would never work as a serious professional tool.

Today, Anthropic announced an experimental alternative for agent orchestration, which they call “Agent Teams.”</a> This is actually the second system Claude has grown for orchestration, the first being “subagents.”</a>

In Agent Teams, one agent oversees a collection of worker agents. The worker agents all maintain their own independent context, and can message between each other to coordinate work. Per Anthropic’s documentation, Agent Teams are best deployed in contexts where they can work on independent efforts on a shared codebase without overlapping.

By contrast, subagents work serially, and share context, with each subagent being specialized for specific tasks. They’re intended to be used in contexts where you have a single problem or series of tasks which benefit from specialization, but which require coordination and shared state between agents. Subagents, unlike Agent Teams, are not considered experimental.

I doubt that Agent Teams will be the final word from Anthropic on multi-agent orchestration, but I am both glad to see Anthropic pursuing a first-party solution in this space, and unsurprised.

Back in the era of containers, Docker had first-mover advantage and were in position to develop a strong first-party solution for container orchestration. Unfortunately, despite efforts in that area, they were unable to satisfy the needs of their users, leaving room for Kubernetes to emerge and take pole position, which limited Docker, Inc.’s ability to monetize that opportunity.

With that well-known example in mind, it was hard to imagine that Anthropic would risk missing the train on agent orchestration by not developing first-party solutions.

It’s doubtful this is the last option we’ll see in the agent orchestration space. Users and AI companies are still figuring out the pitfalls and what seems to work well for coordinating the work of multiple agents. As we’ve seen with Gas Town, solutions which involve the application of ever more specialized agents can become quite expensive!

Agent Teams certainly have fewer unique agent roles compared to Gas Town, and we’ll see what impact (if any) that has on the ability of the agents to remain on-task over time and to coordinate on work.

Rust's Culture of Semantic Precision

2026-01-16T00:00:00+00:00

Last week, LWN published “READ_ONCE()</code>, WRITE_ONCE()</code>, but not for Rust”</a>, which described an issue encountered as part of integrating more Rust into the Linux kernel: namely that the READ_ONCE</code> and WRITE_ONCE</code> macros are in practice used for diverging purposes in different contexts, implicitly encoding an inconsistent set of semantic guarantees. The article then describes how the Rust contributors to Linux are working to determine how to more accurately express the specific semantic guarantees associated with the Rust-side of APIs which use these macros on the C-side.
This situation, of identifying an API which is implicitly encoding multiple distinct semantic guarantees, and thereafter wanting to disentangle them, is a familiar one for Rust developers. One little-discussed cultural norm in the Rust ecosystem is that APIs should be designed to encode semantic guarantees as precisely as possible.
This is shown in things like the design of container types, such as Rust’s various “cell” types (Cell</code>, RefCell</code>, OnceCell</code>, etc.), as well as pointer-associated types such as Unique</code> (internal to the Rust standard library, where it is used heavily) or NonNull</code> (part of the std::ptr</code> API). As Manish Goregaokar described in“Wrapper Types in Rust: Choosing Your Guarantees”</a>, Rust tries to disentangle unique semantic guarantees which users can then compose together to express precisely what they need.
It also appears in Rust’s ongoing discussion around amending the Copy</code> / Clone</code> trait hierarchy to enable more precision</a>. Copy</code> is a trait intended for types which are trivially-copyable, meaning their full contents can be copied with a single memcpy</code>. Clone</code> is intended for more “expensive” copies, for example copies which require duplication of data on the heap and adjustment of pointers to point to the copied data. Over time, Rust developers have identified types with a different sort of copy semantics, such as Rc</code> or Arc</code>, where cloning the data in fact means cloning the handle to the underlying data, not the data itself.
The Rust community’s desire for precise semantics, in the long run, leads to more robust software systems. In the short run, as the Linux devs are encountering, it can be challenging to introduce greater semantic precision in systems which were previously more ambiguous about guarantees and requirements. Personally, I’m glad Rust has this norm, and it’s something I find appealing about Rust as a culture, not just a language, and I remain optimistic that Linux will be better off because of it.
Gas Town is not Urbit 2026-01-15T00:00:00+00:00 Yesterday I wrote “Gas Town Decoded,”</a> a brief guide to the insular language Steve Yegge uses to describe Gas Town</a>. Gas Town, for those out of the loop, is Yegge’s attempt to build a system for AI agent orchestration. Today, Steve Klabnik wrote “How to think about Gas Town,”</a> which analyzes why Gas Town chose to use such strange language in the first place. It’s a great piece, and one with which I agree. You should read it! In discussions around Gas Town, I and many others have noted the parallels to another infamous software system that used insular language: Urbit. While it’s true that both Gas Town and Urbit invent their own language specific to their projects, they are otherwise extremely different. Urbit is fascist, Gas Town is not. As Klabnik describes in his piece, Gas Town’s insular language is used by Yegge to signpost the experimental nature of the project and to discourage production use. Klabnik argues Yegge did this because, as someone who is programmer-famous, he knows anything he works on will be taken seriously by others. Urbit, on the other hand, used insular language to create a sense of exclusivity and complexity, as part of Curtis Yarvin’s attempt to gain an audience for his fascist political ideas. Throughout the 2010’s, Yarvin leveraged Urbit to gain entry to programmer forums and conferences, where he could then spread his politics alongside his software. So, while it’s true both Gas Town and Urbit use insular language, we shouldn’t consider them similar beyond that. Gas Town Decoded 2026-01-14T00:00:00+00:00 On January 1st, Steve Yegge published “Welcome to Gas Town,”</a> an introduction to his new AI agent orchestration tool written in a loose and chaotic mode, and accompanied by AI-generated images depicting a fictional industrial city populated with weasels (yes, really). Reactions were swift, mostly agog at the scale and hubris of such a (self-admittedly) wasteful and obscenely expensive system, and alternately confused or amazed at the amount of new, insular language tailor-made to describe it. In the interest of making Gas Town intelligible (because, despite the prose, the idea of agent orchestration it describes will be important), I’d like to share a quick decoder for the many new terms Steve introduces. His article itself offers definitions, but those definitions reuse his insular terms, making by-hand decoding tedious. Here, I’ve done the work for you. Steve’s Term</th> Real-World Definition</th> Alternative Term</th></tr></thead> Town</td> Top-level folder containing your individual projects. The gt</code> binary manages projects under this folder.</td> Workspace</td></tr> Rig</td> A project. It’s a folder tracked by a unique Git repository within your workspace.</td> Project</td></tr> Overseer</td> The user (you). You have an “inbox” to receive notifications from agents in your projects.</td> User</td></tr> Mayor</td> The managing agent for a project. Usually you send this agent messages, and it coordinates the work of other agents in the project.</td> Manager Agent</td></tr> Polecat</td> Worker agent, taking commands from the mayor, doing some work, submitting a Merge Request, and then stopping.</td> Worker Agent</td></tr> Refinery</td> Merge agent, who coordinates and makes decisions about merge requests coming from Worker Agents.</td> Merge Agent</td></tr> Witness</td> Fixer agent, that watches the worker agents and tries to fix any that are stuck.</td> Fixer Agent</td></tr> Deacon</td> Maintenance agent, runs a consistent workflow in a loop, unlike “worker agents” who do arbitrary tasks and then die.</td> Maintenance Manager Agent</td></tr> Dogs</td> Maintenance worker agents who do cleanup tasks, directed by the Maintenance Agent.</td> Maintenance Worker Agents</td></tr> Boot the Dog</td> Maintenance Manager checker agent, just checks on the Maintenance Manager Agent periodically to see if it needs a reboot or anything else.</td> Maintenance Manager Checker Agent</td></tr> Crew</td> Persistent Worker Agents, which you talk to directly (not through the Mayor), and which persist after their tasks are done, to be reused. These are per-Project.</td> Persistent Worker Agents.</td></tr> Beads</td> System for tracking work history across the system.</td> Work Tracker</td></tr> Rig Beads</td> Project-specific work, tracked in the Work Tracker.</td> Project Work</td></tr> Town Beads</td> Whole-workspace work, tracked in the Work Tracker.</td> Workspace Work</td></tr> </tbody></table> Even with these definitions and alternative terms, Gas Town is still a bit of a mess, with watchers-on-watchers at times (do we really need a Maintenance Manager Checker Agent?). That said, hopefully this decoder at least makes understanding what Gas Town is easier. Passkey PRFs and the Passkey Loss Blast Radius 2026-01-14T00:00:00+00:00 Yesterday, Ars Technica reported</a> on Confer</a>, an AI company created by Moxie Marlinspike</a>, who also created the secure messaging app/protocol Signal</a>. In Confer’s blog post “Making end-to-end encrypted AI chat feel like logging in,”</a> Moxie writes about how Confer uses passkey PRFs to encrypt chats. As the blog post describes, the PRF extension allows Confer to derive a new key deterministically from a user’s passkey, so they can then use this new key to encrypt other material. While passkey PRFs are powerful, and have legitimate uses, they carry a real risk: passkey PRFs increase the blast radius of passkey loss. When a passkey PRF is used to encrypt material associated with a user, and that user loses their passkey, the encrypted material is also lost. Today, if a user loses a passkey used to log in to a service, they can usually recover their account somehow, but if materials tied to that account were encrypted with a passkey PRF, those materials are gone even when the user regains account access. Passkey loss can happen for many reasons! Loss of a device or hardware token for keys that aren’t synced, lockout from a platform (such as an Apple ID) for passkeys kept in a platform-specific keystore, or even a user’s death for passkeys whose decryption mechanism expects biometrics. The fact that people have repeatedly lost cryptocurrency keys worth enormous sums of money shows that even with strong financial incentives, mistakes happen and keys get lost. So while passkey PRFs are powerful (they let you tie encryption material to an authenticated user’s private key), they also require platforms to prepare users for what they’d lose if their passkey is lost. The Confer article lists alternatives, such as giving the user a long passphrase to remember (which many will forget or store insecurely), encrypting based on a user’s password (which is phishable), or using a device-key (which blocks cross-device access). These trade-offs make passkey PRFs compelling! It’s just worth remembering it’s not a free lunch. 'Memory Safety for Skeptics' in the ACM Queue 2025-12-01T00:00:00+00:00 I’m a bit late to sharing it here, but an article of mine</a> was in the November issue of the ACM Queue! Called “Memory Safety for Skeptics,”</a> it argues for why memory safety is worth pursuing amid competing priorities. It was a lot of fun to write, and is purposefully not an article about rewriting codebases in Rust. Check it out! Tracking Software ID Schemes 2025-04-10T00:00:00+00:00 Part of my life is working on the problem of software identification. I’m on the Core Team for OmniBOR</a>, a reproducible software identifier scheme, and my other work in software supply chain security and vulnerability management often bumps up against challenges with identifying software at differing levels of granularity, mapping vulnerabilities or SBOMs (Software Bills of Material) to specific software. It may surprise you to learn there are a lot of software identifier schemes. Some of them are general purpose and used across different ecosystems, while some are ecosystem or even tool- or API-specific. To help track those identifiers and link to their specifications, I’ve made a new Software ID tracker</a>. It’s up on GitHub</a> and contributions are welcome! The Best Monad Tutorial Ever Written 2025-02-19T00:00:00+00:00 When Rain</a> mentioned recently they had a draft monad tutorial that explains them without mathematical jargon, with practical examples, and as a design pattern, I knew it was going to be good. Of course, it is even better than I hoped. “Demystifying monads in Rust through property-based testing”</a> is an undersell of a title. If you’ve floated around the world of functional programming long, you’ve probably seen one of the many attempts at explaining monads. Many are from the perspective of a formalism—the monad laws—and written with Haskell—the language that made them a central feature with syntactic sugar and a direct to how IO is done. Rain instead introduces monads with a practical example of how their flexibility actually makes some work harder, motivated with a concrete example of how “shrinking,” a core operation for doing practical property-based testing, becomes much more difficult when monadic operations are used to generate test inputs. Instead of Haskell, the tutorial uses Rust. Thanks Rain for the best monad tutorial I’ve ever read! Jujutsu is the Future 2025-02-14T00:00:00+00:00 I’d like to stake a radical position: the Git</a> Version Control System (VCS) will be declining in popularity in 5 years, and Jujutsu</a> (jj</code>) will be gaining popularity in its place. Of course, Git is the most popular VCS today by a wide margin, with a large ecosystem of companies and tools built around it. However, I believe Jujutsu will displace it for three reasons: Jujutsu can be adopted locally on Git projects. You can use Jujutsu as an individual contributor on a project that doesn’t use it. It can be adopted incrementally by teams, and does not require a cutover from one VCS to another, which history has shown to be a slow, expensive, and difficult process.</li> Jujutsu’s design makes dev work easier. Jujutsu has learned from Git, Mercurial, and others, and features a model which is, to paraphrase Steve Klabnik, “simpler and more powerful”</a> than Git’s. By removing edge cases and sources of complexity from Git, Jujutsu’s features compose better together, allow more powerful control over your commit history, and make day-to-day operations on collaborative software projects easier.</li> Jujutsu’s interface is easier to use. Not only is Jujutsu’s data model simpler and more powerful, but its Command Line Interface (CLI) is also much easier to understand than Git’s. This is both because the data model is simpler (so fewer flags to handle edge cases are needed), and because the CLI itself is better designed. Flags are more consistent across commands, terminology is more consistent, undoing operations is predictable and much easier.</li> </ol> Of course, I may be wrong. Jujutsu is production ready for many users, but it has not reached version 1.0 yet. Displacing an entrenched technology is also difficult, and there are many ways it could go wrong. Yet using Jujutsu, I have the same feeling I had writing Rust in 2014 as a C++ programmer: this is better. This is a system that makes many of the failure cases I’ve encountered impossible, and makes the few remaining tough cases much easier to resolve. Day-to-day, I find myself less worried about managing my changes to reduce the likelihood of possible merge conflicts; in fact I am rarely worried about conflicts at all. It’s easier to use, easier to teach, and lets me move faster and with more confidence. One of Rust’s historic taglines was “Fearless Concurrency.”</a> Maybe Jujutsu’s should be “Fearless Collaboration.” Safety Hygiene 2025-02-10T00:00:00+00:00 I really like Jack Wrenn’s new article “The Three Basic Rules of Safety Hygiene,”</a> which covers how to handle unsafe code when you have to write it, through a hygiene checklist for expressing and validating compliance with safety conditions in the code. Rust’s goal is not to eliminate unsafe code, but to contain it in isolated modules</a> you can audit</a> and which provide safe interaces to external users. Sometimes unsafety is necessary, and having a process for how to handle that unsafety is a key development. Research on how to reduce things like industrial accidents, medical incidents, and airplane crashes all consistently find that checklists and procedures work. Humans are fallible, and being accountable to a checklist or a process defends against our propensity to make mistakes.