You may have heard from Steve Yegge, the creator of Beads and Gas Town, that we’ve released Gas City 1.0! As the CEO of the newly minted Gas City, Inc., I thought I’d provide some additional details on Steve’s excellent blog post.
It’s hard to look back on the release of ChatGPT as anything but the firing of a starter pistol. In that time, we’ve completely changed how software engineers do their jobs, moving from handwriting their code to using CLI coding agents like codex or claude to do the coding for them. Unfortunately the cost of the increased efficiency in producing the code is reduced quality in the output. It’s not uncommon for professional software engineers to declare the agent output to be “slop.”
In an attempt to drive up the quality of agent output, the typical agentic engineering experience has turned into a babysitting job. You cycle between your terminals, reminding each coding agent what they’re supposed to be building, injecting quality guardrails periodically as those details fall out of their context, manually asking for sub-agents to do research deep dives or reviews. All of that is if you can track where each agent is on their quality path and what the right magic phrases are, based on a year of cave drawings and campfire stories. In fact, I even know of one prolific agentic engineer who has built themselves a custom keyboard so that all of their favorite prompts are available at the touch of a button.
If you’d rather move back to engineering, I recommend Gas City.
agents + orchestration = joy
Gas City is for agentic engineers to build their own software factories.
A software factory is a system for building, validating, deploying, operating, and maintaining production software.
To enable all of this, the core of Gas City is an agentic orchestration engine. Its job is to let you harness swarms of agents to color inside the lines that you define. As an example, here’s a simple Gas City formula that iterates over code incorporating reviews from other agents:
# formulas/code-review-loop.toml
formula = "code-review-loop"
version = 2
contract = "graph.v2"
[[steps]]
title = "Code Review Loop"
id = "code-review-loop"
[steps.check]
title = "Code + Review (loop up to 3 times)"
max_attempts = 3
[steps.check.check]
mode = "exec"
title = "Check Review Results"
path = "checks/review-gate.sh" # reads reviews to decide whether to loop or not
[[steps.children]]
id = "code"
title = "Write code + tests"
description = "Write code and tests based on user input and agent feedback"
metadata = { "gc.run_target" = "coder" }
[[steps.children]]
id = "review-codex"
title = "Code Review (Codex)"
description = "Review the implementation for architectural best practices."
needs = ["code"]
metadata = { "gc.run_target" = "reviewer-codex" }
[[steps.children]]
id = "review-claude"
title = "Code Review (Claude)"
description = "Review the implementation for architectural best practices."
needs = ["code"]
metadata = { "gc.run_target" = "reviewer-claude" }
[[steps.children]]
id = "review-gemini"
title = "Code Review (Gemini)"
description = "Review the implementation for architectural best practices."
needs = ["code"]
metadata = { "gc.run_target" = "reviewer-gemini" }
[[steps.children]]
id = "synthesize-reviews"
title = "Synthesize review results"
description = """
Read all three review outputs, produce one concise synthesis, and decide whether
the implementation is approved.
Write the synthesis to docs/reviews/latest.md.
Close this bead with:
- review.verdict=approved if no blocking or major findings remain
- review.verdict=iterate if another coding pass is required
- gc.outcome=pass
"""
needs = ["review-codex", "review-claude", "review-gemini"]
metadata = { "gc.run_target" = "synthesizer" }Five agents are involved, one coder, three reviewers and one review synthesizer.
The reason to pull in multiple agents from multiple vendors is that each one has been trained differently and has a different point of view. It’s the combination of those points of view, as well as multiple iterations, that drives up the quality of your agentic output.
The agent definitions are separate for reuse amongst formulas, but they each look like this:
# agents/coder/agent.toml
scope = "rig"
wake_mode = "fresh"
provider = "codex"
option_defaults = { model = "gpt-5.5" }
default_sling_formula = "code-review-loop"Each agent also has a prompt template file:
{{/* agents/coder/prompt.template.md */}}
# Coder
## Role
You implement code changes. Read the request, any prior review feedback,
and the project context, then write the implementation with tests and commit it.
## Inputs
- The current routed formula step.
- Project context: AGENTS.md, specs/ and docs/
- Prior review feedback in docs/reviews/ (if retrying after a failed review cycle).
## Graph Work Process
1. Run `gc prime`.
2. Read the routed step and project files.
3. If docs/reviews/ contains prior feedback, read it and address findings.
4. Implement the change with tests.
5. Commit to a feature branch.
6. Close the current step.
## Output Format
A git commit on a feature branch with passing tests.
## Close Behavior
Close the current step when the commit is made and tests pass.Notice that the definition only has to mention “codex” and not set up a path or CLI args or output formats. That’s because Gas City has a built-in “factory worker” protocol to standardize access to your favorite CLI coding agents, including codex, claude, and gemini, of course, but also amp, opencode, pi, etc. That means that you can change your coder agent to be another OpenAI model or another CLI coding agent altogether, all with a simple set of declarative settings and without changing your formulas. And the settings also support MCP servers, skills, overlays, and the full set of capabilities that you need for your agents, all in an agent-neutral way.
Formulas — step-by-step workflows for as many agents from as many providers as you like — are the key to moving from babysitting your agents to harnessing them. To be able to handle our record peak of 74 PRs in a single day, Gas City runs on Gas City. For a more in-depth look at the power of agentic orchestration, I recommend Orchestration Is All You Need.
get involved!
Harnessing agents with formulas is the core of Gas City, but there’s more, including beads (the way work is defined), orders (trigger-based automations), packs (shareable sets of agents, formulas and orders), a rich event stream, and the list goes on!
To help you get up to speed on all of this tech, I recommend the Gas City docs, made explicitly friendly for you AND your agents. Also, there’s a vibrant and growing community of people experimenting with Gas City and working together to invent the future of software engineering, with 2600+ members in the Gas Town Hall Discord server. From this community, the core projects — Beads, Gas Town, and Gas City in the Gas Town Hall organization on GitHub — have gathered more than 35K stars, with more than 5,000 PRs and 2,500 issues from 500+ contributors.
But that’s not all, the popularity of Gas City has grown enough that Actual AI has started a set of hands-on workshops called The Software Factory Intensive, with five cities already planned. In fact, last week was the first one and we had more than 70 engineers building their own software factories with Gas City.
Things are moving fast: from Steve’s initial commit on Beads in October to hands-on workshops across multiple cities running right now.
Interested in joining us? Come on over to Gas City Hall — we’re happy to have you!
where are we?
You can build your own custom agent keyboard if you want to.
If you’d like to take the leap to agentic engineering instead, I recommend Gas City.