Durable memory and an audit trail solve different jobs. Beads preserves decisions, status, dependencies, and next work. Gas City materializes a graph-workflow run as root and step beads, then projects its local execution view from retained bead lifecycle events with live and linked detail. Beads Team Server, available in preview through design partnerships, captures and stores the governed Run record for team operations.
Calling all three “history” creates bad architecture and worse expectations. The right question is what you need to recover or reconstruct.
Three records with different jobs
| Surface | Product | What it contains | The question it answers |
|---|---|---|---|
| Durable work memory | Beads | Beads, relationships, comments, status, assignments, and Dolt history | ”What work exists, and what should happen next?” |
| Local execution view | Gas City | An addressable formula run projected from retained bead lifecycle events, with live session and linked formula or transcript detail | ”What did this local factory do?” |
| Retained operational record | Beads Team Server preview; included in the coming Gasworks product | Related work and the agent sessions, usage records, artifacts, and outcomes captured around its execution | ”Who or what executed this work, what did it produce, and what did it cost?” |
These surfaces can be connected while remaining distinct.
Beads remembers the work
A context window remembers tokens. Beads remembers the job.
A bead can hold the current status, an assignee, notes, and relationships to other work. Parent-child relationships place a small task inside a larger one. Blocking dependencies determine whether the task belongs on the ready frontier. A discovered-from relationship records where follow-up work came from without falsely blocking it.
With the default bd provider, the graph is stored in Dolt, a version-controlled SQL database. Embedded mode gives a solo developer a single-writer database inside the bd process. Server mode supports concurrent writers. Dolt history and remotes support recovery and synchronization, while the Beads record remains structured and queryable.
If an agent crashes halfway through a task, the process is gone. The bead is not. Another agent can read the open work and continue. The durable memory guide explains why this is more useful than preserving another transcript. The crash recovery guide covers the operational handoff.
For maintained behavior, see issues as durable agent memory, dependencies, and the Beads recovery guide.
Gas City shows local execution
Gas City operates coding-agent workflows on Beads. A graph-workflow run is materialized as a root bead and child step beads, so it has an addressable identity independent of the formula file and the session that launched it.
The dashboard and API project that run by folding retained bead lifecycle events from .gc/events.jsonl. Request-time views can enrich the projection with live session and census state plus linked compiled-formula or coding-agent transcript detail. The event surface supports listing events, following the stream, and resuming retained history from a cursor.
That is useful observability. It is not a retained enterprise audit record.
Gas City’s local run is therefore both addressable and projected: root and step identity lives in beads, while the execution view folds the retained local event log and adds current or linked detail. The default event configuration keeps rotated archives, but an operator can set an archive retention age. This operational history is not the durable work graph or a separately governed organizational Run.
This boundary is deliberate. Gas City is an open, self-managed factory for an individual professional developer. The events reference explains the current event interface. The reference architecture guide shows where it sits beside the durable Beads work graph.
The Beads Team Server preview retains the team record
Once agent work crosses people and machines, work state alone may not answer the questions a team has.
Beads Team Server preview is available through design partnerships as managed SaaS or self-hosted inside the customer’s VPC. It adds governed shared beads and a private operational record. A capitalized Run is that record: related work plus the agent sessions used to execute it, the artifacts and outcomes captured around the execution, and any provider-reported model, token, and spend values available for those sessions. Beads Team Server stores the Run in the organization’s shared location for the retention period the organization chooses.
Run data belongs to the customer’s organization. It is not shared across customers and it is not a billing unit. Teams can use it to connect spend to outcomes, inspect provenance, and compare executions when they change a prompt, workflow, or model choice.
Beads Team Server is executor-neutral. Customers keep their agents, scripts, or factory platform. Gasworks is coming soon, includes Beads Team Server, and adds the multi-operator factory.
The enterprise orchestration guide explains when that additional record becomes necessary.
Do you need memory, visibility, or evidence?
Use Beads when one developer and their agents need work that survives sessions. That is the starting point for durable memory, dependency-aware next work, and crash recovery.
Use Gas City when the developer also needs repeatable workflows, automations, and a local view of agents executing against that work.
Use the Beads Team Server preview when a team needs governed shared beads and retained execution history. Choose the coming Gasworks product when multiple operators also need to run and improve one shared factory.
Inventory one current workflow. Name the durable work record, the local observation sources, and any retained organizational record separately. For each, write down its owner, location, and retention behavior. If one row has to answer all three jobs, the architecture is hiding an important boundary.
Related articles
- Durable memory for coding agents: Learn which work state belongs outside a model’s context window.
- Recover agent work after a crash: Follow the replacement-worker sequence against that durable state.
- Enterprise multi-agent orchestration: Decide when governed shared work and a retained Run become team requirements.
- Software factory reference architecture: Place all three record surfaces in the wider component map.