I planned to write about using Dolt for agentic memory today but I got nerd sniped. Instead, let me talk to you about a new coding agent called Gas Town. Gas Town is tangentially related to agentic memory but more of a use case showing why agentic memory matters.
What is Gas Town?#
Gas Town is a coding agent orchestrator released by Steve Yegge on January 1. Steve and I worked together long ago at Amazon. I’ve been a fan of his agentic software development takes ever since he introduced me to Claude Code. Steve has been consistently ahead of the curve on agentic software development so I take what he says and builds seriously. He literally wrote the book on vibe coding.
Gas Town presents itself as a Claude Code-like, single agent interface, but in the background, Gas Town spawns and manages a series of specialized agents, all with interesting names, to get many threads of work done in parallel. Gas Town is more like a coding agent factory than a coding agent. You talk to the factory foreman, or as Steve calls it, the “Mayor”, and that thing coordinates as many workers as it needs to get your tasks done. If you have ever thought “I wish I had 100 Claude Codes”, Gas Town is for you.
Personally, I’ve never felt constrained by a single Claude Code instance. I’m at coding agent stage 5. I do a lot of manual review and task management in my coding agent sessions. I do all the Git version control management myself. This cognitive load forces me to be single threaded.

But apparently, some people think if they daisy chain enough Claude Codes together, a computer will make software, and us software developers can play video games while we wait for it to finish. Steve is one of those people. It’s definitely worth a valiant attempt. Gas Town is Steve’s attempt, and it is valiant if I do say so myself.
The Journey to Gas Town#
The journey to Gas Town started with Beads, another less recent Steve Yegge creation. Beads is “a coding agent memory system”. It is built on a Git plus SQLite backend to provide version control to structured data. Dolt seemed like a better alternative to one of our long-time users, Prodo.
Prodo posted this in our Discord on Friday:
To which I replied, not realizing at first Beads was a Steve creation:
I hit Steve up on LinkedIn and he got back to me rather quickly with:

I didn’t know it yet but I had packed my bags and was heading down the road to Gas Town.
What is Beads?#
Beads is a command line tool, bd, coding agents use to manage tasks. Beads stores tasks as issues in a .beads directory in your project folder. You tell your coding agent to use Beads to manage its tasks, and voila, your coding agent will start to be able to accomplish longer tasks and remember things.
Anyone who has used a coding agent probably has run into a variant of the problem Beads solves. You ask a coding agent to fix an issue. The coding agent makes a change. You review it. It looks good. You push the change up to GitHub, create a Pull Request (PR), and ask for a review. You move onto something else. A fellow engineer suggests substantial changes to your PR a day later. You try and fail to find the coding agent session you used to make this change. So you start a new session. The agent has no context so it is starting over from scratch. This is at best a waste of time and money. At worst, the coding agent can’t get back to the state it was in and fails. If you tell coding agents to use Beads to manage their tasks, they can more easily pick up where they left off.
Your coding agent can very easily switch to using Beads.
# Install (macOS/Linux/FreeBSD)
curl -fsSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash
# Initialize (Humans run this once)
bd init
# Tell your agent
echo "Use 'bd' for task tracking" >> AGENTS.md
Why Git + SQLite?#
Let’s consult the Beads architecture documentation to explain why Beads used Git and SQLite.
┌─────────────────────────────────────────────────────────────────┐
│ CLI Layer │
│ │
│ bd create, list, update, close, ready, show, dep, sync, ... │
│ - Cobra commands in cmd/bd/ │
│ - All commands support --json for programmatic use │
│ - Tries daemon RPC first, falls back to direct DB access │
└──────────────────────────────┬──────────────────────────────────┘
│
v
┌─────────────────────────────────────────────────────────────────┐
│ SQLite Database │
│ (.beads/beads.db) │
│ │
│ - Local working copy (gitignored) │
│ - Fast queries, indexes, foreign keys │
│ - Issues, dependencies, labels, comments, events │
│ - Each machine has its own copy │
└──────────────────────────────┬──────────────────────────────────┘
│
auto-sync
(5s debounce)
│
v
┌─────────────────────────────────────────────────────────────────┐
│ JSONL File │
│ (.beads/issues.jsonl) │
│ │
│ - Git-tracked source of truth │
│ - One JSON line per entity (issue, dep, label, comment) │
│ - Merge-friendly: additions rarely conflict │
│ - Shared across machines via git push/pull │
└──────────────────────────────┬──────────────────────────────────┘
│
git push/pull
│
v
┌─────────────────────────────────────────────────────────────────┐
│ Remote Repository │
│ (GitHub, GitLab, etc.) │
│ │
│ - Stores JSONL as part of normal repo history │
│ - All collaborators share the same issue database │
│ - Protected branch support via separate sync branch │
└─────────────────────────────────────────────────────────────────┘
As you can see Beads requires fast queries of structured data but also requires version control for conflict resolution, agent collaboration, and sharing. SQLite provides the fast queries and Git provides the version control. But you have this potentially finicky sync mechanism between the two.
Can Dolt Help Beads?#
In Steve’s words:
Yeah, so in short. Yes. Beads is a product, sort of an interface for a work ledger. The sqlite+jsonl backend is clearly me reaching for Dolt without knowing about it…Prolly Trees were clearly designed for exactly my kind of use case.
If Dolt was used instead of Git and SQLite, the SQLite database and the JSONL persistence system could be combined into a single Dolt database. Dolt could be run embedded because Beads is written in Golang. Or Dolt could be run as a central server for a project with different Beads instances connecting to it. This would remove the need for syncing between two systems.
Hosted Dolt, DoltHub, DoltLab, or cloud storage can act as a remote repository. A pointer to these remotes can be stored in Git if necessary.
Moreover, the Beads Dolt database now has all the power of both SQL and Git. Dolt provides cell-based and JSON-document merging, meaning even fewer conflicts. If there is a conflict, agents will be able to reason more easily about which specific data is in conflict and resolve. What agent made a change to a specific cell? Just query the dolt_diff_<table> table. Want to make assertions on the structure of tasks stored in Beads? Add dolt_tests so agents can make sure their writes are correct. Dolt will unlock a host of additional capabilities for Beads.
When Do We Get to Gas Town?#
“I thought this blog was about Gas Town, not Beads?”
Well, Beads is a dependency of Gas Town. Beads acts as the central agent coordination persistence for Gas Town. Dolt can add additional capabilities to Beads that will be leveraged by Gas Town. As you’ll see, Gas Town spawns more agents than any reasonable operator can keep track of. Dolt’s version control capabilities in Gas Town’s central task persistence layer will make tasks easier to write, manage, and control.
Issue tracking is a prime example of traditionally human scale writes becoming machine scale. Gas Town agents require a different, more scalable issue tracking model and system. We’ll see more and more domains with this problem in the agentic AI era. Dolt becomes an essential tool to manage these now machine scale writes. Git-style branch, diff, and merge are a proven model to coordinate many long time horizon, untrusted writes. Dolt brings that version control to structured data.
So, with all this talk of Dolt potentially being useful in Gas Town, let’s take a tour.
Install Beads, tmux, and Gas Town#
In order to get started you must first install Beads, tmux, and Gas Town. I did those in reverse order as I hit dependency errors. I followed the GitHub instructions for Gas Town, used Homebrew for tmux, and followed the GitHub instructions for Beads. This all worked out of the box.
Fix Dolt Bats Tests#
Gas Town requires a rig: a project or Git repository to work on. I set up my rig as a clone of Dolt. I had Gas Town start trying to fix Bats tests, my go-to test for coding agents, except this time, four in parallel!
Once you run gt mayor attach, you are greeted by a familiar Claude Code interface. I was a bit confused at first. Was something broken? I soon realized everything was working. I just had a Claude Code session with the Mayor. I needed to tell it what to do. I started with a simple prompt: fix some bats tests.
If you’re not paying attention to the Claude Code output, you may not notice anything different between Gas Town and Claude Code. That’s a good thing. If you are paying attention to the Claude Code output, you’ll start to see Gas Town specific language like like slinging work to polecat.
The Mayor came back with the option to fix any of four tests it determined could be fixed easily. I enthusiastically replied fix all four in parallel.
Limitless Mode#
This is where you start to really feel the difference with Gas Town versus Claude Code. Gas Town feels like Claude Code in “limitless mode”, named after the 2011 movie about a drug that gives a person superhuman recall and speed.
Gas Town forked off a bunch of workers and started fixing all four skipped Bats tests in parallel. I watched output stream by, and unlike Claude Code, there’s really too much going on for you to reasonably comprehend and I’m just watching the Mayor thread. I know there’s 20 other agents in other terminals. Everything is moving so fast in Gas Town that you really just have to let go. I had a palpable sense of stress watching it. Gas Town was moving too fast for me.
Gas Town is tuned to “you only live once” (YOLO) even harder than the hardest YOLO mode: limitless mode. Gas Town pushes branches to GitHub, makes PRs, and, much to my surprise, merges them! After the first PR got merged autonomously, despite the integration tests failing, I quickly closed Gas Town. I had to get a colleague to reset --hard and force push the Dolt repository. Limitless indeed.
The Mayor#
I did have some back and forth with the Mayor about the status of work. At one point, only two PRs had been made, but the Mayor was reporting all the bugs were fixed. I told the Mayor that only two PRs had been created, and a bunch of agents spun up and figured out the work was in Git but not pushed up to GitHub on a branch. The Mayor got this all sorted and I eventually ended up with four PRs.
Working with the Mayor is a great Gas Town abstraction. You really feel like you are one layer removed from the nitty gritty of software development. You have an expert that knows how Gas Town works, and you just talk to that expert. This interface feels right.
Did It Work?#
Well, no. None of the PRs were good, and I ended up closing them all. I probably could have worked with Gas Town to fix them, but honestly, Gas Town was like riding a wild stallion that needed to be tamed. I wasn’t ready to unleash it on Dolt and probably shouldn’t have in the first place.
Also, as Steve warns, Gas Town burns money, not gas. This whole sixty minute experience cost me about $100 in Claude tokens. That’s about 10X the cost of a normal Claude Code session per unit time.
But the Potential!#
Gas Town is two weeks old. Gas Town will get better. Today, all the orchestration works. Many agents get spawned. The system prods them to finish tasks. Tests get run. PRs get made and…merged. The task I gave it is generally on the edge of current agent capabilities, and it was able to pull off four at once. Dealing with the Mayor is a joy.
I think if you start a new project with Gas Town and build the proper guard rails to its model, you might be able get to a point where the constraint on what you can build isn’t clock time but rather creativity and dollars in Claude Code tokens. That’s a big shift in the way software is developed.
When will I unleash Gas Town again on Dolt? I’m not sure but I’m definitely monitoring its progress.
Conclusion#
Have you ever thought “I wish I had 100 Claude Codes”? Take a trip to Gas Town. It’s a wild ride. We’ll see if Dolt can help tame the beast. Questions? Come by our Discord. We’re always happy to discuss.



