An AI software factory is a customer-owned configuration of agents, workflows, automations, prompts, skills, and packs that repeatedly turns engineering intent into reviewed work. Gas City is the MIT-licensed open platform that runs that factory on Beads.
The word “factory” matters. A handful of terminals and a good prompt can produce a feature. A factory records how the work should proceed, gives each agent a durable unit of work, applies the same review rules next week, and leaves the process available for inspection and improvement.
A factory is the configuration you own
Gas City is the platform. Your factory is the configuration it runs.
That configuration names the coding agents you use and the work they may touch. It includes the workflows that split a job into steps, the automations that start recurring work, the prompts and skills that shape each agent, and the packs that collect those pieces into something reusable.
Keeping configuration separate from the engine has practical consequences. You can inspect a workflow before running it, change the reviewer prompt without changing the platform, and move the same factory configuration from Gas City to Gasworks without converting it.
If you have built agent applications from framework primitives, Gas City asks you to start one level higher. Its default path is prebuilt and inspectable first. You can edit the workflow once you have seen it run. The open-source orchestration guide goes deeper on that configured-not-coded distinction.
The work lives outside the agent session
A coding-agent session is a worker process with temporary context. It may compact its transcript, crash, or finish and disappear. None of those events should erase the job.
Gas City runs on Beads, the open protocol for durable agent work. A bead records a unit of work in a vendor-neutral work graph. Parent-child relationships describe the shape of a larger job. Blocking dependencies determine which work is ready. Agents update that graph as they make decisions, discover follow-up work, and finish steps.
That changes the recovery question from “Can we reconstruct the chat?” to “What does the work graph say now?” A new session can read the same bead, see what remains blocked, and continue from a shared record.
Workflows turn judgment into a repeatable process
Suppose a feature normally passes through technical planning, two implementation slices, tests, and review. Running five chat sessions by hand makes you the scheduler. You decide when each agent may start, carry decisions between terminals, and notice when a dependency has not actually finished.
A Gas City workflow writes those relationships down. The technical name is a formula: a readable TOML definition that materializes its steps as beads. The orchestrator fans ready work out to configured agents, holds blocked steps, retries failures according to the workflow, and brings the results back to the review gate.
For code-delivery workflows, a sensible default outcome is a reviewed pull request ready for human review. The customer decides where approval, review, and policy gates belong. “Factory” does not mean removing people from every decision.
This is also how the Gas City team maintains its own open-source projects. When checked on August 7, 2026, that public fleet spanned 23 repositories. You can watch Maintainer City, the software factory behind them, operate through a read-only public dashboard. The page shows current sessions, queued and running work, formula progress, model-usage estimates, and supporting-system status.
That live operational view serves a different purpose from the public Gas City project dashboard, which publishes repository-level delivery and community measurements together with their collection windows and methods. The first shows the factory in motion; the second records public activity in the Gas City repository. Neither is a productivity claim for the whole project fleet. An AI software factory in practice connects both views to the public pack, workflow, and work graph behind them.
The software factory reference architecture covers the components in detail. The coordination guide follows one coding job through the graph.
Start with one real workflow
The first useful factory is small.
Pick a repo and a process you already trust. A bug fix that goes through implementation, tests, and review is better than an ambitious diagram of everything your engineering organization might do someday. Run the prebuilt workflow. Watch where it needs your judgment. Then edit the configuration.
Gas City’s Quickstart creates a city, registers a project, and routes the first bead. How Gas City works explains the runtime model, while Understanding formulas is the maintained reference for workflow behavior.
The important test is whether the method is worth running again. Look at the reviewed result, identify where the workflow needed judgment, and change the configuration before the next job. Failure injection belongs to the multi-agent orchestration test; the first factory run should establish a repeatable baseline.
That is factory engineering: improving the system that produces the work.
When the factory grows
One professional developer can run Gas City locally and keep the factory configuration under their control. As the number of workflows grows, packs make working patterns portable between projects. The factory-in-practice guide shows how a public pack carries one working method across a real repository fleet.
Team operation introduces a different problem. The portfolio guide maps the move from individual durable work and orchestration to governed shared work and a multi-operator factory without folding those jobs into Gas City.
Run the Quickstart against a repo you care about. One inspectable workflow, one durable work graph, and one real review will tell you more than another week of factory diagrams.
Related articles
- Open-source agent orchestration: Decide how much of the factory, work state, and operating boundary you need to control.
- Coordinate multiple AI coding agents: Follow one feature through parallel implementation, testing, and review.
- Software factory reference architecture: Place configuration, work, execution, repositories, and events in the system map.
- An AI software factory in practice: Inspect the public pack, workflow mechanics, and dated fleet results behind a running factory.