Gas City lets a professional developer run a customer-owned software factory over Beads on their own machine. The factory can coordinate several coding agents, operate repeatable workflows across real repositories, start recurring work, recover after session failures, and grow through reusable packs.
These scenarios are available in the open-source product today.
Run the same repository method more than once
A useful factory begins with work that already has a recognizable shape: plan a feature, split the implementation, run tests, review the result, and prepare a pull request for a human decision.
Gas City records that method as a formula and materializes its steps as beads. Dependencies decide what is ready. Configured agents claim bounded work in project scope. Review and repair can loop without turning the operator into a human message bus.
The source-linked AI software factory in practice follows the public gascity pack that the team uses to maintain Beads, Gas City, and its public repository fleet. The coordination guide narrows the lens to one feature moving through parallel work, tests, and review.
Mix coding agents without moving the work
One factory can route implementation, review, research, or testing steps through different CLI coding-agent harnesses. The agent definition selects the harness, model, prompt, skills, scope, and permissions for the job. Beads keeps the work contract independent of that selection.
This makes provider choice reversible. A developer can compare two agents on the same repository task while keeping the bead IDs, dependencies, acceptance criteria, and result format stable. Gas City had 17 built-in coding-agent integrations when checked on August 7, 2026, and its custom provider boundary can accommodate other commands.
The mixed-agent guide explains the harness boundary and a two-agent routing test.
Automate the work that benefits from repetition
An order can start a workflow or command on a schedule, event, condition, or manual request. That makes Gas City useful for recurring repository work such as issue triage, dependency review, documentation checks, pull-request review, or a project-specific health pass.
The workflow can fan deterministic checks out alongside agent work, record findings as beads, and converge at an explicit gate. Scripts remain a good fit for mechanical checks; agents belong where the task needs judgment. The maintained orders tutorial documents current trigger behavior.
Recover when an agent session disappears
Coding-agent sessions are disposable processes. Beads stores the job outside them: status, notes, decisions, hierarchy, blockers, and history. When one session exits after recording its progress, another can read the same work graph and continue from the ready frontier.
Gas City’s local dashboard projects graph-workflow runs by folding retained bead lifecycle events and enriching them with live session and linked formula or transcript detail. It gives the developer one place to inspect agents, sessions, workflow activity, work, mail, and health. The dashboard docs cover current operation, while the durable memory guide separates work state from execution visibility.
Import a factory method instead of starting empty
Packs collect workflows, configured agents, automations, prompts, skills, and supporting files. A city can import a public pack, pin its source, and override the parts that differ locally.
The Gas City Registry makes those methods discoverable. Its catalog includes the first-party factory, alternative build methods, review and contribution workflows, chat and GitHub adapters, and runtime extensions. The result is more than a template gallery: each pack is source a developer can inspect, run, fork, and improve.
The product and community map connects the Registry to the documentation, GitHub projects, and public Discord where practitioners exchange working patterns.
Grow from one repository to a local fleet
A city can register several projects and keep their working directories, agent scopes, and commands distinct. Shared packs carry the common operating method; project configuration keeps repository-specific details local. Worktrees isolate parallel coding sessions within a project.
A useful progression is operational: make one workflow dependable, apply it to a second kind of work, then carry the method to another repository. The public Gas City factory follows that pattern across a 23-repository fleet; the factory-in-practice article provides the current public measurements and source trail.
When the scenario becomes a team operation
Gas City is the open local factory. When beads need to be governed and shared across people and machines, the Beads Team Server preview adds the team work layer and retained organizational Run. When several operators need to use and improve one shared factory, the coming Gasworks product adds that multi-operator surface.
Those adjacent products extend the path as work crosses team boundaries. The enterprise orchestration guide covers placement, governance, retention, and availability. The OSS path starts with Gas City, one real repository, and one method worth repeating.
Pick the scenario with the clearest feedback loop
Start with the scenario where success is easiest to inspect. A repository workflow with tests, review artifacts, and a human gate gives the factory a concrete result and gives you useful feedback about its configuration.
Run the Gas City Quickstart, import the closest public pack, and change one part after the first run. That is enough to begin factory engineering.
Related articles
- An AI software factory in practice: Inspect the public pack, workflow mechanics, and dated fleet results behind a running factory.
- Use Claude Code, Codex, and Gemini together: Route several coding-agent harnesses through one durable work graph.
- Gas City product and community map: Find the Registry, docs, repositories, Discord, and adjacent team products.