Building with Gas Town: Multi-Agent AI Development Guide
Gas Town is a multi-agent orchestration system that transforms development from working with a single AI co-pilot into supervising an autonomous factory of agents building, testing, and shipping features in parallel. As AI-driven software development evolves, the shift is moving beyond chat-based assistants toward coordinated, persistent automation. Gas Town introduces a new paradigm where multiple specialized agents collaborate simultaneously under your direction.
In this article, you’ll explore how Gas Town works, how its architecture enables large-scale parallel execution, and why its approach to persistence and orchestration expands what is possible in AI-assisted development. You’ll see how a single high-level prompt can activate a coordinated team of AI agents to design, implement, and refine a complete JWT authentication system. By the end, you’ll understand its strengths, its trade-offs, and whether this autonomous workflow fits your development process.
Understanding the Gas Town architecture: your AI development factory
Before effectively using Gas Town, understanding its philosophy and the components that make it work is crucial. It's fundamentally different from tools like GitHub Copilot or a standard ChatGPT session. Gas Town doesn't just assist; it manages and executes an entire development workflow.
What is Gas Town? An orchestrator, not a model
The first and most important thing to grasp is that Gas Town is not an AI model. It is an open-source orchestration layer that sits on top of existing large language models (LLMs) like Anthropic's Claude, OpenAI's GPT series, or Google's Gemini. Think of it like Kubernetes for AI development workflows. Kubernetes doesn't run your application code itself; it manages, scales, and orchestrates the containers that do. Similarly, Gas Town doesn't write the code; it coordinates a team of AI agents, powered by models like Claude Code, to carry out a complex plan.
This distinction is key. Gas Town's purpose is to solve the inherent limitations of single-agent systems, such as losing context on restart, the chaos of managing more than a few agents manually, and the loss of work state stored only in memory.
The core components of a Gas Town workspace
Gas Town uses a unique and thematic set of terms to describe its components. Understanding this vocabulary is essential to using the tool effectively. The entire system is structured around a central ~/gt directory, which is the "Town Workspace."
The Mayor: the AI project manager
At the top of the hierarchy is The Mayor. This is the primary AI coordinator. Your role as the developer is to provide a high-level goal to the Mayor. You don't give it step-by-step instructions. Instead, you describe the entire feature you want to build in as much detail as possible in a single prompt. The Mayor's job is to analyze this goal, understand the existing codebase, and decompose the complex request into a structured plan of smaller, executable tasks.
Rigs: your project sandboxes
In Gas Town terminology, a project is called a Rig. A Rig is essentially a Git repository that Gas Town is managing. When you add a new project, you are creating a new Rig within your Town Workspace. Each Rig is a self-contained environment with its own set of agents, work history, and state, all managed through a dedicated Git repository structure.
Beads and convoys: structuring the work
Once the Mayor has a plan, it breaks the work down into structured task units called Beads. A Bead is a specific, well-defined piece of work. For example, if you ask for a full authentication system, the Mayor might create separate Beads for creating database migration for the users table, implementing JWT generation and validation logic, building the HTML for the login and registration forms, and writing integration tests for the registration endpoint.
These Beads are then grouped into Convoys for execution. This structured approach allows Gas Town to track dependencies and manage the flow of work in a clear and organized manner.
Polecats: the parallel worker agents
The agents that actually perform the coding tasks are called Polecats. These are the individual workers on your AI factory floor. When the Mayor dispatches a Bead, it "slings" it to a Polecat. Gas Town can spin up dozens of these Polecats, each working on a different Bead simultaneously. Each Polecat operates in its own isolated Git branch, preventing it from interfering with the work of other agents. This parallel execution is the source of Gas Town's incredible speed and scalability.
The power of Git-backed persistence and parallelism
Two core principles make Gas Town exceptionally powerful: its deep integration with Git and its ability to manage parallel workflows.
Never lose your work again: how Git persistence solves the context problem
A common frustration with single-session AI assistants is that if the session crashes or you need to restart, the entire context is lost. You have to start over, re-explaining your goals and feeding the AI the code it already wrote.
Gas Town solves this brilliantly by using Git as its state machine. Every action, every piece of code written by a Polecat, and every decision made by the Mayor is persisted in a Git repository. Each Polecat's work is done on a feature branch, the status of each Bead is tracked within the Git history, and if the system crashes, you can simply restart it. Gas Town will read the Git history, understand exactly what was being worked on, and resume the process from where it left off. No work is ever lost.
Horizontal scaling for cognition: the multi-agent advantage
The video's author uses the brilliant phrase "horizontal scaling for cognition." This perfectly captures the essence of Gas Town's multi-agent approach. Instead of a single AI "brain" working through a list of tasks one by one (sequentially), Gas Town spins up many "brains" (Polecats) to tackle the problem from multiple angles at once (in parallel).
This is analogous to a modern software team. You wouldn't have a single developer build the database, the API, the front-end, and the tests one after the other. You have a backend developer, a frontend developer, and a QA engineer working concurrently. Gas Town applies this same principle to AI agents, dramatically reducing the total time required to complete a large feature.
Getting started: setting up your first Gas Town project
Understanding the concepts sets the foundation for walking through the process of setting up and using Gas Town.
Prerequisites and initial setup
The initial setup can be challenging. Gas Town is a powerful tool with several dependencies. Before beginning, you'll need a development environment with tools like Git, Go programming language, a package manager like Homebrew (on macOS) for installing dependencies, and an API key for an LLM provider (e.g., Anthropic Claude).
You would follow the official Gas Town documentation to install the gt command-line interface and configure it with your API keys.
Adding a project to Gas Town (creating a rig)
First, you need to tell Gas Town about the project you want it to work on. The video uses a simple Go-based to-do list application from GitHub.
Use the gt rig add command. This command initializes a new project within Gas Town. You provide it with a name for the rig and the URL of the Git repository:
Gas Town will clone the repository, create a shared bare repo for its internal management, initialize the beads database, and set up the necessary worktrees and agent configurations. This process establishes the entire managed environment for your project.
Creating your personal workspace (joining the crew)
Gas Town is designed for collaboration, even if you're the only human user. You create a personal workspace, which is referred to as joining the "crew."
Use the gt crew add command. This creates a dedicated space for you to interact with the rig:
After the command completes, you will change your directory into your new crew workspace to begin working:
Engaging the Mayor and defining the goal
This is where the magic begins. You will now "attach" to the Mayor's session to provide your high-level instructions.
Attach to the Mayor using the gt mayor attach command to enter an interactive session with the main AI coordinator. Craft a detailed, high-level prompt. This is the most critical step from the user's perspective. You need to provide a single, comprehensive description of the entire feature. The more detail you provide upfront, the better the Mayor's plan will be. In the video, the prompt is:
"Add full JWT-based user authentication to this TODO app: SQLite user database with email/password, POST /register and POST /login endpoints that return JWT, protect all existing TODO routes with JWT middleware, simple HTML login/register forms, add tests, and a Dockerfile. Use feature branches and merge when ready."
Notice how this single prompt covers the database, API endpoints, security, frontend, testing, and deployment aspects of the feature. This is the level of detail required for the Mayor to create a successful plan.
A practical walkthrough: adding JWT authentication
With the prompt submitted, Gas Town takes over. The developer's role now shifts from active coder to supervisor and reviewer.
The Mayor's plan: decomposing the feature into Beads
The first thing the Mayor does is "think." It analyzes the prompt, inspects the existing codebase, and formulates a plan. This plan takes the form of multiple distinct Beads. As shown in the video's terminal output, the Mayor creates separate tasks for core auth backend (switching the database, creating user models, and implementing JWT endpoints), HTML forms (creating the login.html and register.html views), auth tests (writing Go test files to cover the new authentication system), and Dockerfile (creating a multi-stage Dockerfile for the application).
Unleashing the Polecats: parallel execution in action
Once the plan is set, the Mayor starts "slinging" the unblocked Beads to Polecat agents. The terminal scrolls rapidly as Gas Town allocates Polecats (giving names to the worker agents like obsidian, quartz, jasper), spawns sessions (each agent begins its work in a dedicated, isolated session), and executes in parallel (multiple agents work at the same time).
While one is working on the database backend, another is creating the Dockerfile, and a third is building the HTML views. Each agent commits its work to its own feature branch.
Observing the process: monitoring and merging
Throughout this process, the Mayor monitors the progress of the Polecats. As agents complete their tasks, they are "nuked" (terminated), and their feature branches are merged into a primary integration branch. The Mayor intelligently manages dependencies. For example, it waits for the core backend Bead to be complete before it starts the Bead for writing integration tests, as the tests depend on the API endpoints existing.
Reviewing the output: from code generation to a working application
After a few minutes, the entire process is complete. All the individual pieces of work done by the Polecats have been automatically merged into the master branch of the project's repository.
Analyzing the generated codebase
The video shows the final state of the project in a GitHub repository. The results are impressive. Gas Town has: added a config directory with database setup code, created a controllers directory with auth.go to handle login and registration, implemented a middleware directory with the JWT protection logic, added new models for the user, updated the routes to include the new auth endpoints and protect the old ones, created a views directory with the HTML forms, added a complete auth_test.go file, and created a multi-stage Dockerfile.
All of this was generated and integrated automatically from a single prompt, with multiple agents working in parallel.
Final test: running the completed application
The final proof is running the application. The video shows the new login and registration pages, which are styled and functional. After registering and logging in, the user is taken to the to-do list, which works as it did before, but is now secured behind the new authentication layer. The feature was implemented successfully from end to end.
The bigger picture: pros, cons, and the future of AI development
Gas Town is a powerful glimpse into the future, but it's not without its challenges. Weighing the benefits against the current trade-offs is important.
The pros: where Gas Town shines
Unprecedented scalability and speed: The ability to run 20, 30, or even more agents in parallel means that features that could take a human developer days can be scaffolded and implemented in minutes.
Robustness and fault tolerance: By using Git for persistence, Gas Town is incredibly resilient. Crashes, network issues, or rate limits don't result in lost work. The system can simply be resumed.
True cognitive offloading: The developer's primary job shifts from low-level implementation to high-level planning and review. You define the "what," and Gas Town's Mayor and Polecats handle the "how," managing the entire project plan for you.
The cons: the real-world trade-offs
The overhead of complexity and setup: Getting Gas Town and its dependencies installed and configured correctly is not a trivial task. It's a professional tool with a steeper learning curve than a simple chatbot.
The challenge of oversight fatigue: While you're not writing the code, you are ultimately responsible for it. The sheer volume of code produced by dozens of agents can be overwhelming to review. You shift from writing code to reviewing massive, automatically generated pull requests.
The financial cost of parallelism: Running numerous powerful AI agents concurrently can burn through API tokens very quickly. The speed and scalability come at a direct monetary cost that can add up, especially on large projects.
The risk of unsupervised automation: The agents have full access to your repository. A misinterpretation of the prompt or a bug in an agent's logic could lead to it "wrecking your repo." Careful supervision and version control practices are non-negotiable.
Final thoughts
Gas Town signals a major shift in how you use AI for software development. Instead of relying on a single assistant, you orchestrate an entire AI workforce. Its core idea of breaking a high-level objective into parallel, persistent, independently executed tasks mirrors how real engineering teams scale and operate.
The platform is still early, and you must account for infrastructure demands, coordination complexity, and model costs. Even so, it offers a compelling glimpse into what development workflows are becoming. You are no longer just pairing with an AI. You are directing a system that manages multiple specialized agents on your behalf.
As tools like this mature, they could redefine your role from hands-on implementer to system architect and orchestrator. The future of development may be less about writing every line yourself and more about designing, supervising, and refining autonomous systems that build at unprecedented speed.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.