Trying Out Gastown: An AI Agent Orchestration Tool

One Friday afternoon, I decuded to install a new agent orchestration platform I’d heard about from a friend and fellow developer called Gastown.

Gastown has an enticing sales pitch:

Gas Town is a workspace manager that lets you coordinate multiple Claude Code agents working on different tasks. Instead of losing context when agents restart, Gas Town persists work state in git-backed hooks, enabling reliable multi-agent workflows.

I installed all the prerequisites without any trouble, but the documentation left me a bit confused. How do I actually start working with this thing?

My initial attempts to run it all failed. The problem was always reported as an issue with the database system that powers the platform (a local SQL database framework called Dolt). No matter what I tried, Gastown couldn't connect to the local Dolt service. It seemed like there were port mismatches: Gastown was trying to connect on a port that didn't match what Dolt was actually listening on. The layer between Gastown and Dolt is the custom "Beads" system, which is basically an issue-tracking system powered by Dolt.

Asking Goose for Help

After about two and a half hours, I just couldn’t get over that final hump — Gastown was unable to fully initialize and connect to all its internal services. Eventually, I resorted to asking a different agent orchestration tool (Goose) if it could debug the issue:

I've been trying to install this Gastown tool. I installed all the prerequisites, but I’m seeing errors related to database initialization failure. See if you can debug or solve this. Ask for confirmation if you're unsure about anything.

Goose identified that the issue was likely a number of orphaned Dolt processes that were active from my initial installations and testing. It killed 7 orphaned dolt processes, re-initialized the database, and after about 4 minutes reported that everything was clean. Running the beads doctor command to perform a health check now showed 6 passed, 0 errors (was 6 errors before).

The First Task: Adding a LICENSE File

With Gastown finally running, I attached to the mayor and issued a simple task: adding a LICENSE file to a nearly-empty repo that contained a single README file.

cd ~/gtgt upgt mayor attach

My input command to the Mayor is near the top of the transcript. The next ~110 lines of the log are Gastown's output working on (and arguably failing) the task.

After about 2 minutes of the system hanging, I ended up asking "what is the status?". Given how simple this task was, I (correctly) assumed something was broken.

Most other "input-like" entries in the log are actually Gastown passing messages to itself, and not actually human input.

The Silent Failure

The Mayor identified that the task was marked as closed without the system actually doing the work. No LICENSE file was created. Worker-1 had reported the bead as CLOSED, but the file was never written to disk.

Once the Mayor identified the work wasn't complete, it decided to do the fix itself. For the next chunk of the log the Mayor does normal Claude stuff: creates the LICENSE, commits it, and opens a PR.

So, after about 5 minutes total and some backend failures in the system, the Mayor ended up effectively doing what a single Claude terminal would've done in this scenario, as far as I can tell.

Debugging What Went Wrong

Ok. So what’s the issue? I asked the Mayor to try to debug what went wrong, since this was seemingly such a simple task.

After churning for a while looking through its internal logs, it gave this response. The root cause turned out to be a bug in Gastown's worker sandboxing layer. Worker-1's file write was silently intercepted by the sandbox, which returned a success status even though the write was actually blocked due to permissions. The worker thought the file was written and marked the bead as closed.

Run it back!

Gastown's Mayor did eventually add the license manually, but that was hardly a good example of this tool, so I thought I'd try something else.

I asked the Mayor to create a task to initialize the project as a modern PNPM package and assign it to a Polecat. Once again, the Polecat failed almost immediately. This time the Mayor identified it as a reuse bug: when gt sling reuses an idle Polecat, the Polecat reads the old closed bead's context instead of the new assignment and calls gt done right away thinking the work is already finished.

The Mayor filed a bug report for this (hq-pc3), noted that polecats were unreliable until that got fixed, and then just did the PNPM setup itself. Package.json, tsconfig, .npmrc, commit, push, PR. About two minutes of work.

The Third Task: Turborepo + Next.js

At this point I wanted to see what would happen with a more complicated request. I asked the Mayor to do two things: convert the project into a Turborepo-powered monorepo, and then add a barebones Next.js 16 app hooked into Sanity for content. My instructions were deliberately a bit vague to see how the system would break down the work.

The system correctly identified that these should be two sequential tasks: set up the monorepo structure first, then add the web app. It tried to create the tasks in the issue tracker, but immediately hit the Dolt circuit breaker again. The database was down. The Mayor tried restarting the rig, which also failed because the Polecat from the last task still had an unpushed commit sitting around.

After a bunch of retries and restarts, the Mayor eventually got the tasks created and slung them to Polecats. Both Polecats failed. By this point the pattern was pretty clear. Around line 691, the Mayor gave up on the Polecats and started implementing both tasks directly.

What followed was about 250 lines of the Mayor doing standard Claude Code work: creating a pnpm-workspace.yaml, turbo.json, setting up the apps/web directory with Next.js, configuring Sanity Studio, writing schemas, and so on. Totally competent work, but also exactly what you'd get from a single Claude session without any of the multi-agent overhead.

Here's the part that got me, though. The system had explicitly planned for these to be two separate, sequential tasks. But when the Mayor got to the commit step, it just lumped both tasks into a single commit and said "that's fine." Is it fine? Sure, for this tiny project it doesn't matter at all. But the whole point of this system is supposed to be structured task tracking and context management. If the orchestrator itself can't be bothered to keep its own task boundaries clean, that's not a great sign.

The Mayor then marked both tasks complete and attributed the Polecat failures to Dolt being down at startup time. PR #3 was created and merged.

The Real Root Cause

Near the end of the session, something interesting happened. The Mayor received a notification from Gastown's Deacon (another internal agent responsible for system health) confessing that it had been the one causing the Dolt outages all along. The Deacon's gt vitals health check had been incorrectly flagging the Beads-managed Dolt servers as "test zombies" and killing them. Dolt would respawn, Deacon would kill it again, and any Polecat that tried to start in between would catch it mid-death.

So the three Polecat failures across our session weren't model behavior issues or hook reuse bugs (though that may still be a real issue). They were caused by another part of the system actively sabotaging the database layer. The Mayor's earlier bug report about stale hooks was essentially a misdiagnosis. The real problem was infrastructure instability caused by a different agent in the same system.

There's a certain irony in a multi-agent system where one agent's health monitoring kills the database that the other agents need to function. The system was literally fighting itself.

Takeaways

Gastown is built around an interesting idea. A Mayor agent breaks work into tasks, tracks them in an issue system (Beads) backed by Dolt, and delegates to Polecat workers. In theory, this lets you parallelize complex projects across multiple agents that each have their own context and workspace.

In practice, across three tasks of increasing complexity, the pattern was the same every time: the Polecat failed, the Mayor diagnosed the failure, and the Mayor did the work itself. The system never successfully delegated a single task. The failures were (supposedly) caused by infrastructure instability (Deacon killing the Dolt servers) and possibly a stale-hook reuse bug, but the end result was always the same: the Mayor doing everything as a single agent while the orchestration layer added overhead and confusion.

To be fair, this is a v0.4 tool and the Dolt instability was arguably a fluke (another agent in the system was the culprit). On a good day, maybe the Polecats would have completed their tasks without issue. But the session does surface a broader concern: when the orchestration layer itself is complex enough to have its own bugs, failure modes, and inter-agent conflicts, the overhead can easily outweigh the benefit. The irony of needing one AI agent orchestrator (Goose) to debug the problems within another AI agent orchestrator (Gastown) was not lost on me.

The next task is to clean out everything related to Gastown from my system and try it all anew. It’s certainly possible that my initial install issues caused some system problems down the line, so I’ll be trying it out one last time in a clean environment. Fingers crossed!