Enterprise orchestration needs governed shared work and a private operational record before it needs more agents. Beads Team Server is in preview through design partnerships; it captures organizational Runs in the organization’s shared location and stores them for the retention period the organization chooses. Gasworks is coming soon and will add the shared multi-operator factory.
Open-source Gas City remains the factory platform for an individual operator. It supplies orchestration and automation on a machine the developer controls. Identity governance and retained team records begin with the commercial products.
The boundary changes when the work becomes shared
One developer can make local trust decisions. They choose the packs, agent commands, model credentials, repos, and workflows on the machine. Gas City treats that developer as a trusted operator.
An organization has more questions:
- Which people and service identities may read or change work?
- How is execution connected to the initiating work and its outcome?
- Where does the operational record live?
- Which workflow steps require approval?
- Does the service run as managed SaaS or inside the customer’s VPC?
Those questions separate local orchestration from governed team operation.
Choose the team product by what needs to be shared
Choose Beads Team Server when the team wants to keep its current agents and workflows while sharing and governing beads. The preview is executor-neutral: agent scripts, an internal orchestrator, or Gas City can execute the work. Enterprise bd preserves the familiar Beads interaction while connecting work to the team service.
Choose Gasworks when multiple operators need the factory itself to be shared. Gasworks is the coming-soon team version of the Gas City factory path. It includes Beads Team Server and adds shared workflows, automation, and live factory operation so operators can improve one factory together.
The portfolio map shows both paths in one view.
Placement is a separate decision
Beads Team Server preview is available through design partnerships in two placements: managed SaaS or self-hosted inside the customer’s VPC.
Gasworks is coming soon with the same two placements planned.
Managed SaaS and VPC deployment place the same product in different operating boundaries. A VPC deployment puts code, prompts, work state, and retained operational data inside the customer’s boundary. Managed SaaS is operated by Gas City, Inc. and requires its own privacy, retention, and access commitments.
Air-gapped operation is a separate claim. Coding agents and model providers may still make outbound calls according to the customer’s configuration, so the deployment review must include those dependencies alongside the factory platform.
Governance starts with explicit work
Governance is hard to add to a transcript because the work is implicit. A team needs a stable object to govern.
Beads supplies that object. The work graph records units of work, ownership, parent-child structure, and blocking relationships. Agents can claim ready work atomically. The multi-agent coordination docs cover the open-source assignment and claim mechanisms.
In the Beads Team Server preview, team controls and provenance surround governed shared beads. The product captures Runs in the organization’s shared location and stores them for the retention period the organization chooses. Each Run connects related work to the agent sessions, artifacts, outcomes, and available provider-reported usage data produced during execution.
The distinction matters during an incident. The bead answers what the job was and where it stood. The Run answers how the team executed it. The memory and audit-trail guide draws that line in detail.
Human gates belong in the workflow
Enterprise orchestration should make approval points visible before work starts.
Gas City workflows can express dependency and review steps. A formula gate creates a blocking bead that a person can close manually or customer-supplied automation can close after an external condition. Although the accepted gate-type vocabulary includes human approval, CI, pull requests, timers, and mail, Gas City ships no type-specific watchers for those labels today. The organization decides who may approve, which evidence is required, and what happens after a failed gate.
Gasworks is designed for governed execution when it becomes available. For a code-delivery workflow, the default outcome is a reviewed pull request ready for human review. A customer may relax or add gates workflow by workflow as its evidence and risk tolerance change. An enterprise label does not turn automatic merge into a safe default.
Start the security review at the command boundary
Gas City packs and city configuration are trusted operator code. Agent commands, setup hooks, workflow scripts, order checks, and exec orders can run processes. Inherited secret-looking environment variables are stripped from several orchestrator-side command paths, but an operator can still pass credentials deliberately through configuration.
That boundary is useful because it is inspectable and assumes reviewed, trusted configuration. Hostile code needs a separate sandbox boundary.
The maintained Gas City trust-boundary reference identifies which inputs execute, who is expected to author them, and how secrets move. The packs guide explains the configuration unit. Treat both as inputs to an enterprise review, not as a certification claim.
A practical evaluation sequence
Start with the work and the trust model.
If one developer needs durable work and local orchestration, evaluate Beads and Gas City as open-source foundations. Inspect the factory configuration and run a real workflow against a disposable repo.
If the work must cross people or machines, request a Beads Team Server design partnership and evaluate governance, placement, provenance, retention, and API fit against the team’s current agents.
If multiple operators also need to run and improve one shared factory, join the separate Gasworks waitlist. Its availability is different, and the evaluation should say so.
More agents can wait. First make the work governable and the record trustworthy.
Related articles
- Durable agent memory and audit trails: Distinguish the work graph, local execution view, and retained organizational Run.
- All-in-one AI software factory: See the two open-source starting points and their paths to the team products.
- Software factory reference architecture: Review the OSS foundation before assessing commercial placement and governance.
- Software factory FAQ: Get direct answers to deployment, security, availability, and product-boundary questions.