Gas City’s portfolio gives developers one Beads-native path: Beads for durable work, Gas City for a local customer-owned factory, Beads Team Server for governed shared work, and Gasworks for a multi-operator factory.
It is one product path, not one binary that claims to do everything. The boundary between the four products is the useful part.
Four products, four jobs
| Product | Who it is for | What it does | Availability |
|---|---|---|---|
| Beads | A developer and their coding agents | Stores durable agent work in a vendor-neutral work graph | Open source |
| Gas City | A professional developer running a factory locally | Runs customer-owned workflows and automations on Beads | Open source |
| Beads Team Server | A team sharing agent work | Adds governed shared beads and captures shared organizational Runs with organization-chosen retention | Preview through design partnerships |
| Gasworks | Multiple operators running one factory | Adds shared workflows, automation, and live factory operation; includes Beads Team Server | Coming soon |
Beads works without Gas City. It gives coding agents durable work that survives their sessions. The Beads Guide covers its memory model, adoption, and agent recognition in depth.
Gas City begins where durable work meets execution. It reads a workflow, materializes the work as beads, and routes ready steps to the coding agents you configure. Your factory is the agents, workflows, automations, prompts, skills, packs, and related settings you own.
The two commercial products solve the problems that appear when this work crosses people and machines. Beads Team Server shares and governs the work while keeping the team’s agents and workflows in place. Gasworks adds the factory layer for multiple operators.
Two sensible starting points
Start with Beads when the immediate problem is memory.
Perhaps a coding agent loses its plan after compaction. Maybe work discovered in one session never reaches the next. Or several agents are leaving Markdown plans around the repo with no reliable account of what is blocked. Beads gives them a durable graph for decisions, status, dependencies, and next work. The Beads Quickstart is the shortest path in.
Start with Gas City when the immediate problem is orchestration.
You already have work and coding agents. What you lack is a repeatable way to split that work, route it, apply review gates, and run recurring jobs. Gas City supplies the open factory platform and runs it on Beads. The Gas City Quickstart starts with one project and one routed task before moving into workflows.
Neither route forces an early team purchase. The open-source products are complete products for individual operation.
What changes when a team wants in
Sharing a database is the easy-looking answer. It is rarely the whole answer.
A team needs to know who may act, which work belongs to which project, and what happened during execution. It may also need model and token records tied to the work and outcome that produced them. Those concerns belong in the team layer; Gas City remains a complete open-source product for individual operation.
Beads Team Server is the first commercial step, available in preview through design partnerships as managed SaaS or self-hosted inside the customer’s VPC. In that preview, a team keeps its current agents, scripts, and factory platform while adding governed shared beads. Beads Team Server captures organizational Runs in the organization’s shared location and stores them for the retention period the organization chooses.
Gasworks is for the next problem: multiple operators using the same workflows, seeing them run, and improving one factory for everyone. It includes Beads Team Server. Gasworks is coming soon in the same two planned placements and has a separate waitlist.
The enterprise orchestration guide explains that choice without attributing commercial governance to Gas City.
One factory configuration
Gas City and Gasworks run the same customer-owned factory configuration without conversion. That is the connection between the open and commercial factory products.
The configuration remains readable. Imported packs define the factory’s agent roles and formula workflows, and its workflows and automations can be inspected before they run.
Gasworks names the team, multi-operator version of the factory path: shared workflows, live visibility, several operators, and the Beads Team Server record underneath. Managed SaaS and customer-VPC deployment are placement choices.
For the products and the public resources around them, see the Gas City product and community map. The distinction here is the product path: durable work, individual orchestration, governed team work, and then shared factory operation.
Pick the problem you have now
If an agent keeps forgetting the work, install Beads.
If you are manually driving several coding agents through the same process, run Gas City and inspect one prebuilt workflow on a real repo.
When work needs to be shared and governed across a team, request a Beads Team Server design partnership. When several operators need to run and improve one factory, join the separate Gasworks waitlist.
That is the all-in-one story: one connected path, with a product boundary you can still see.
Related articles
- Beads: Start with durable work and the full memory-upgrade story.
- Build an AI software factory: Start with individual orchestration and a customer-owned factory.
- Enterprise multi-agent orchestration: Evaluate governance, placement, operational records, and shared operation.
- Gas City product and community map: Find the products, Registry, documentation, GitHub projects, and Discord community.