Open-source agent orchestration should leave the factory in your hands: readable workflow configuration, inspectable state, and coding-agent choices you can change without rewriting the platform. Gas City is an MIT-licensed open software factory platform built around that ownership model.
You run it on your infrastructure. The agents, workflows, automations, prompts, skills, packs, and local settings make up a factory you own. Gas City runs that configuration on Beads, where the durable work survives agent sessions.
Use an ownership test, not a feature count
An open repository answers one question: can you inspect the platform code? A useful orchestration system has several other things worth inspecting.
Can you read the workflow before it creates work? Can you see which agent definition will receive a step? Can you move the work state without losing its relationships? Can you replace one coding-agent CLI with another through configuration? Can you diagnose the command boundary when a pack runs a script?
Those questions expose the control model faster than a long feature matrix.
Gas City’s answer has three parts. Factory definitions stay as files the customer can inspect and version. With the default bd work-store provider, work lives in a Beads graph backed by Dolt. Execution uses coding-agent CLIs installed and authenticated by the operator.
The factory is configured, not coded into an SDK
Agent libraries are useful when you are building an agent application. They give your code primitives for prompts, tools, state, and control flow.
Gas City starts from a different job. A professional developer already has coding agents and real repositories. They need a repeatable method for turning work into implementation, tests, and review.
A pack is the portable unit of that method. It can declare agents, workflow definitions, automations, prompts, and supporting files. The local city is a root pack that can import other packs. Gas City hardcodes no roles. The factory’s agent roles and formula workflows are defined by packs you import.
The public gascity base pack is the same pack the team uses to maintain a 23-repository public fleet in the gastownhall GitHub organization, including Beads and Gas City.
The method is larger than one first-party pack. The public Gas City Registry catalog listed 17 pack entries on August 7, 2026. Its catalog included alternative build methods based on BMAD, Compound Engineering, gstack, and Superpowers, along with contribution workflows, service adapters, and a runtime extension. Each entry points to source a developer can inspect and pin.
That makes change ordinary. Swap the CLI harness in an agent definition. Edit a review prompt. Add a blocking step to a workflow. Import a pack, inspect its files, and pin its source. The packs guide documents how those definitions and imports compose.
The AI software factory guide covers the broader category. The key open-source choice is whether your working method remains legible after the demo.
Beads owns the durable work
Agent sessions are processes. They start, compact, crash, and end. Treating a transcript as the work record couples recovery to whichever tool produced the conversation.
Beads gives the factory a vendor-neutral work graph. A bead records one unit of work, while typed relationships describe hierarchy, blockers, provenance, and other connections. Gas City materializes workflow steps as beads and drives the dependency graph forward.
The distinction matters for portability. Gas City may route the work, but it does not redefine the work around one model vendor. An agent can exit while its bead, decisions, status, and blocking relationships remain available to the next session.
For architecture choices beyond Gas City, see orchestrating multiple AI agents and software factories versus agent frameworks. The category boundary matters: a framework may implement one worker while a factory owns the continuing production system around it.
Self-managed means you own the operating boundary
Gas City runs locally by default. A city holds portable factory definition, deployment choices, and machine-local runtime material at distinct layers. Registered projects remain real working directories, and configured coding agents run through harnesses the operator selects.
That control comes with responsibility.
Packs and city configuration are trusted operator code. Provider commands, setup hooks, workflow scripts, and automation checks can start processes. Gas City strips inherited secret-looking environment variables on several command paths, but it is not a sandbox for hostile configuration. Read a third-party pack before importing it and include the model endpoints and agent CLIs in the security review.
The maintained trust-boundary reference describes the executable inputs. The installation guide covers supported local installation paths.
The open product is a complete local factory
Gas City provides orchestration, automation, local observation, and a customer-owned factory for an individual professional developer. A graph-workflow run is materialized as a root bead and step beads. The dashboard and API project its local execution view by folding retained bead lifecycle events, then enrich it with live session and linked formula or transcript detail. That view stays anchored to data the developer controls.
Shared governance and retained operational history belong to the Beads Team Server preview. The shared multi-operator factory belongs to the coming Gasworks product. The OSS orchestrator, pack model, and local operating path are complete at their layer; the commercial path begins when the work crosses people and machines.
This boundary is worth checking in any open-source evaluation. A project can publish orchestrator code while keeping the work model, useful workflows, or ordinary operation behind a service. Gas City’s orchestrator is part of the complete OSS product, and the public factory artifacts remain inspectable.
Inspect before you install
Start with the public gascity pack. Look at the agent definitions, prompts, and workflow support. Decide whether you can explain what the imported configuration will do.
Then read How Gas City works and install it locally. Register one disposable repo and run a small workflow. Change one agent definition or review rule in the imported configuration, rerun it, and confirm that the working method remains legible in the diff.
For a source-linked account of that method under real repository load, read an AI software factory in practice.
Use the agent orchestration evaluation rubric to record the result. Open source earns its keep when a failure sends you to readable state and configuration instead of a support ticket.
Related articles
- Build an AI software factory: Start with the category and the smallest useful factory.
- Orchestrating multiple AI agents: Examine the ownership, dependency, recovery, and gate properties an orchestration system needs.
- Agent orchestration evaluation rubric: Test control and recoverability under fixed conditions.
- Software factories vs agent frameworks: Put frameworks, coding agents, work managers, and factories at their correct layers.