Gas City and 8090 are both software factories, but they begin at opposite ends of the production line.
8090 begins with business intent. Its collaborative workspace connects requirements, technical blueprints, work orders, tests, feedback, and code in a knowledge graph. Gas City begins with executable engineering work. Its open-source engine materializes workflows into a durable Beads graph and routes ready steps to configured CLI coding agents.
The products have different centers of gravity. Gas City centers executable engineering work, an open engine, interchangeable CLI coding agents, and portable factory configuration. 8090 centers collaborative requirements, technical blueprints, work orders, tests, feedback, and lifecycle traceability in a hosted workspace. The relevant choice depends on which record the organization needs at the center of its factory.
Gas City, Inc. publishes this comparison and is the company behind Gas City. The page was reviewed against official 8090 and Gas City sources on August 1, 2026.
Same category, different center of gravity
8090 calls Software Factory an AI-native software development control plane. Its five modules carry the work from Requirements through Blueprints, Work Orders, Tests, and Feedback. The knowledge graph connects those artifacts so product intent, architecture, implementation, and validation stay traceable.
Gas City is an open software-factory platform and CLI. It gives operators an orchestration engine, a durable Beads work model, configurable agents and workflows, automations, repository isolation, and packs for distributing a factory’s operating knowledge.
The products overlap in orchestration, work state, agent integration, and lifecycle coverage. The useful comparison is what each treats as the factory’s backbone.
Compare the factory backbones
| Factory criterion | Gas City | 8090 |
|---|---|---|
| Primary record | Executable Beads work graph with status, readiness, dependencies, provenance, and history | Knowledge graph connecting requirements, blueprints, work orders, tests, feedback, and code |
| Engine | Open-source CLI and orchestration engine the team can inspect and extend | Cohesive hosted product and organizational workspace |
| Coding-agent model | Configurable Claude Code, Codex, Gemini CLI, OpenCode, and custom harnesses | External coding agents retrieve and update work through MCP; 8090 remains the authoritative workspace |
| Workflow | Formulas materialize as executable dependencies and advance a ready frontier | Work moves through linked lifecycle modules with traceability to intent and design |
| Factory method | Packs carry agents, workflows, automations, prompts, skills, and supporting files | Requirements, blueprints, work orders, tests, feedback, and organizational configuration live in the product |
| Team surface | Local Gas City operation, Beads Team Server preview for shared records, and Gasworks as the team product | Multiplayer workspace for product, design, engineering, QA, business, and governance stakeholders |
| Distribution | Teams can inspect, fork, publish, and install factory methods through a public registry | Vendor-delivered workspace, integrations, documentation, and enterprise support |
8090 makes context the production line
8090’s documentation frames fragmented requirements and tribal knowledge as the central failure. Requirements capture what and why. Blueprints capture how. Work Orders turn that context into traceable implementation tasks. Tests connect validation back to the intended behavior, while Feedback carries production signals back into planning.
That design serves organizations where the expensive mistake is not simply a failed agent run. It is code that no longer matches policy, architecture, or approved intent. A product manager, architect, developer, and auditor can work from the same connected record.
Work Orders bundle status, assignment, purpose, acceptance criteria, out-of-scope notes, implementation guidance, history, and links to upstream requirements or blueprints. External coding agents can retrieve ready work and update its status through MCP. The web platform stays the authoritative source of truth.
8090 is therefore more than a planning product and more than an agent wrapper. It operates a continuing SDLC control plane.
Gas City centers executable work
Gas City’s backbone is the work being executed. A workflow becomes beads with explicit blocking relationships. The orchestrator computes what is ready, assigns configured workers, observes outcomes, retries or reroutes according to the workflow, and advances the graph.
The workers remain CLI coding agents. One factory can use Claude Code, Codex, Gemini CLI, OpenCode, or custom harnesses without redefining the entire operating model around a single agent vendor. Agent configuration separates the harness, model, transport, upstream, and runtime choices.
The team’s method lives in packs. That can include a feature workflow, multi-model review, security checks, release preparation, repo-specific prompts, and automations that start work from events or schedules. The Registry gives public packs a place to accumulate and travel.
That design addresses the question, “How do we run this engineering method repeatedly, with different agents and repositories, without burying the control flow in one agent session?”
The work graphs record different truths
8090’s knowledge graph connects product intent, technical design, work orders, tests, feedback, and code. Its value comes from semantic traceability across the lifecycle: why a feature exists, which blueprint defines it, which work implements it, and whether the implementation drifted.
Beads records operational work: identity, status, assignment, parent/child structure, blocking dependencies, provenance, and history. Gas City uses those facts to decide what can run next and which configured worker should receive it.
The graphs can complement one another. An 8090 Work Order can be the approved unit of organizational intent while a linked Beads graph carries the finer execution plan discovered by several coding agents. The seam should be explicit: 8090 remains authoritative for the requirement and work order; Beads remains authoritative for the execution subgraph.
Openness changes where factory knowledge accrues
8090 offers a cohesive hosted product. The organization collaborates in its workspace, configures its projects, and uses its agents and integrations. That is valuable when a shared product surface and supported operating model matter more than engine ownership.
Gas City’s engine is open source. The factory method lives in files and packs the customer can inspect, version, publish, fork, and run. That changes where the team’s accumulated factory engineering lives, not only where the software is deployed.
With Gas City, improvements to a review formula or agent role remain portable configuration. Community packs can supply a starting point without becoming an opaque dependency on someone else’s factory account.
Team operation follows different paths
8090 is multiplayer by design. Its workspace is already the collaboration layer for product, engineering, and business stakeholders.
Gas City is locally operated today. A graph-workflow run is materialized as root and step beads; its local dashboard and API view folds retained bead lifecycle events and adds live execution detail. The Beads Team Server preview captures shared work and retained Runs for an organization. Gasworks is the team version of Gas City, adding multi-operator factory operation around the same customer-owned configuration.
That makes product maturity part of the buying decision. Evaluate 8090’s current team surface against the Gas City OSS experience and the available BTS preview, not against an imagined future dashboard.
8090 centers requirements and traceability
8090 gives business intent, architecture, implementation work, tests, and feedback a first-class shared interface. Its Requirements, Blueprints, Work Orders, Tests, and Feedback modules preserve lifecycle traceability. Gas City can execute work derived from those artifacts, but it does not currently supply an equivalent collaborative requirements-and-blueprint environment.
Product managers, designers, engineers, QA, and business stakeholders can work in 8090’s hosted workspace with comments, version history, attribution, connected documents, and organizational views. Gas City is a complete local factory for an individual operator; Beads Team Server is in preview, and Gasworks is the team product.
8090 is built around full-lifecycle traceability, living documentation, and auditability, and it has public enterprise work with organizations such as EY and CMS.
Match the product to the governing requirement
Gas City’s observable strengths are its free open-source engine, interchangeable CLI-agent workers, executable Beads graph, portable packs, and public registry. Its current OSS experience is locally operated; shared organizational retention is available through the Beads Team Server preview, and Gasworks provides the team product.
8090’s observable strengths are its shared requirements and blueprint environment, connected lifecycle artifacts, cross-functional collaboration, living documentation, and enterprise traceability. Its execution model keeps 8090’s hosted workspace at the center and connects external coding agents through MCP.
The products can also meet at a deliberate boundary: 8090 can remain authoritative for approved intent and work orders while Gas City and Beads carry a linked execution subgraph. Whether to use either product alone or compose them depends on which records must be authoritative, who must collaborate in the system, and how much of the execution engine the organization wants to own.
Related articles
- Build an AI software factory: See the full production loop and the elements a factory must join.
- Gas City vs Factory.ai: Compare Gas City with another execution-centered software-factory platform.
- Software Factory reference architecture: Place work, workflows, workers, repositories, events, and team records in one architecture.
- Enterprise multi-agent orchestration: Evaluate control, retention, governance, and human attention at team scale.