homebrew-gascity: The agent orchestrator that turns state into a database

A Homebrew tap for Gas City, an orchestration SDK that pairs terminal sessions, work tracking, and Dolt-backed history to make multi-agent systems inspectable, repeatable, and less of a black box.

8 min read • View on GitHub • More from gastownhall

A wide editorial scene of a dense city made from terminal windows, control towers, and a central ledger-like building beneath them. It suggests that multi-agent work is not just launched, but recorded and managed as durable state. — Gas City treats orchestration like infrastructure. Sessions, coordination, and history all belong to the same system.

Key Takeaways

Gas City stands out because it treats multi-agent orchestration as versioned state, not disposable prompts.
The Dolt-backed history model is the real differentiator, because it makes work inspectable and rewindable instead of opaque.
The stack looks opinionated but practical: tmux, flock, jq, git, and Dolt each solve a specific coordination problem.
The Homebrew tap matters because it turns that architecture into something operators can install and use consistently.

The black box problem in multi-agent work

Multi-agent systems fail in familiar ways. They drift, overlap, step on each other, and leave behind state that is hard to reconstruct. Gas City starts from that pain point and asks a better question: what if agent work behaved less like a prompt chain and more like a system you can inspect, query, and recover?

That is the real story behind homebrew-gascity. The tap is just the delivery surface. The bet underneath is that orchestration becomes much more useful when the runtime has a memory.

Gas City is an orchestration-builder SDK for multi-agent systems. It extracts the reusable infrastructure from Gas Town into a configurable toolkit with runtime providers, work routing, formulas, orders, health patrol, and a declarative city configuration.

Gas City README, Primary Documentation · Gas City README

Why a city is a better metaphor than a script

The city metaphor does real work here. A script suggests a single path and a clean exit. A city suggests persistent actors, shared services, local rules, and a state that survives beyond one command invocation.

That framing matches the project’s shape. The CLI exposes commands like gc init and gc start, which implies a workspace that is initialized once, then managed over time. The system is not just executing tasks. It is maintaining a lived-in environment.

Persistent agents instead of one-off jobs.
Shared infrastructure instead of ad hoc shell glue.
State that outlives a single run.
A control plane that can reconcile reality against intent.

Dolt is the tell

The unusual dependency in this stack is dolt. That is a strong signal that Gas City is not only launching work, it is storing structured history in a versioned database. In other words, the project cares about what changed, when it changed, and how to get back to a known point.

Logs can tell you that something happened. Versioned state can tell you what the system believed before and after it happened. That is a much better fit for multi-agent orchestration, where the hard part is rarely execution alone. The hard part is recovering the story.

Gas City behaves like a controller loop, not a simple launcher. Desired state, runtime providers, and versioned history all feed each other.

How the orchestration stack fits together

Gas City looks less like a single app and more like an opinionated control surface over Unix tools. Each dependency does a job that would be painful to reimplement badly.

Core coordination stack
- tmux: long-lived terminal sessions for agent work
- flock: file locking for concurrency control
- jq: structured JSON plumbing in shell workflows
- git: repository state and source history
- dolt: versioned, queryable work history
- beads: work tracking and task primitives

That stack matters because orchestration problems are usually coordination problems. Terminal sessions need to stay alive. Shared files need locking. Structured state needs to stay readable. And the work itself needs a history that is more useful than a pile of logs.

A close-up cross section of a versioned ledger with branches splitting into recorded states while a task enters one side and a reconciler stamps the result back into history. It explains how Gas City preserves work as queryable state instead of ephemeral output. — The system’s center of gravity is not launch. It is reconciliation and durable history.

From city.toml to running agents

The declarative layer is where the design becomes operational. A city.toml file expresses desired state. The controller reads that intent, picks a runtime provider, and keeps reconciling until the live system matches the configuration as closely as it can.

That is familiar if you have spent time around Kubernetes or any other reconciler-based system. The difference is scope. Gas City appears to bring that idea down to the level of local developer workflows, where the runtime might be a tmux session today and a different provider tomorrow.

That flexibility is the point. The tool is not married to one execution model. It is trying to standardize the contract between intent, runtime, and history.

What Gas City does better than a generic agent framework

Model	State handling	Concurrency	Reproducibility	Operator visibility	Best for
Shell-script orchestration	Usually implicit and scattered across files and sessions	Possible, but fragile	Low, unless heavily hand-managed	Manual, through terminals and logs	Quick experiments and one-off automation
Generic agent framework	Often hidden behind abstractions	Usually easier to start, harder to audit	Medium, depending on framework design	Better UX, but state may stay opaque	Fast prototyping and simple task loops
Gas City	Versioned, queryable, and tied to a durable store	Explicit through locks, sessions, and reconciliation	High, because history is part of the system	Designed for inspection and recovery	Long-lived multi-agent workflows that need control

The trade-off is easy to see. Gas City asks for more infrastructure up front. In return, it offers the one thing agent stacks usually lack when they get serious: a state model you can reason about after the fact.

Why the Homebrew tap matters

The tap is not the story, but it matters. Homebrew turns Gas City into something installable, repeatable, and easy to distribute across the machines people actually use.

That is a signal of discipline. It says the project expects real operators, not just curious tinkerers. And it quietly reinforces the larger thesis: if your orchestration layer is meant to manage state, then installation and upgrades should also feel like part of a controlled system.