Cells and generations

What is a Cell?

A Cell is a Cella-managed, isolated execution environment. It has an identity, a role, admitted inputs, explicit permissions, resource limits, and a lifecycle. Wall creates and contains the environment; cellad coordinates its use.

A Cell is the place where a workload runs. Agent Cell, Service Cell, and Analysis Job Cell describe different roles for that environment.

For example, an Agent Cell can contain a coding agent, a private copy of source code, and build tools. A separate Service Cell can run the application that the agent needs to test. The agent does not gain access to the application's secrets simply because it can send an approved request to that application.

A Cell Record preserves the logical Cell's identity and history. A Cell Generation identifies one admitted execution boundary with fixed inputs and permissions. Changing those admitted properties requires a new generation. Its Generation Manifest records the admitted properties; Observed Status reports changing facts such as whether it is running, stopped, or quarantined.

Further reading: Cell identity and properties.

Long-running agents and everyday development

The primary use case is a remote or dedicated machine where an agent can keep working between operator visits. The operator defines the workspace, tools, service access, external actions, and budgets. The intended workflow lets the agent work within that authority, pause for a required decision, and leave inspectable state and evidence for the operator's return.

Everyday development uses the same boundaries. A developer can explicitly select an existing project Cell for another task or create a separate Cell with narrower permissions. A Cell can be useful across many development sessions; its purpose is not limited to one disposable agent invocation.

What reusing a Cell means

Reuse means selecting the same logical Cell deliberately. It does not mean matching a host directory and silently restoring an old session. Each Run is an attributable execution attempt. A compatible generation may be reused when its admitted inputs remain valid; a security-relevant change to policy, source, declared runtime/tool profile, adapter, or secret bindings requires a new generation.

The retained Agent Cell keeps its workspace, scripts, permitted workspace-local tools and dependencies, conversation/context state, and task state across Runs. The agent can create scripts and execute them there. Finishing a Run or leaving the Cell does not by itself erase that state. Ordinary workspace edits and script execution are workload state; they do not rewrite the admitted manifest. A retained Cell may stop or suspend its runtime without losing permitted state.

Workspace retention and authorized continuation are explicit decisions. Checkpoints and the Work Journal preserve declared files, task state, and lineage. They do not transfer hidden model reasoning. Replacement generations receive fresh grants rather than inheriting expired Channels or approvals.

General and focused Cells

“General” and “focused” describe the scope of a Cell's work, not new Cell roles. A project Agent Cell might edit source and run local tests. A narrower Agent Cell might review a selected repository input without delivery authority. A Service Cell can run an approved test backend; an Analysis Job Cell can process an explicitly granted snapshot.

Think of an Agent Cell as a reusable work environment, similar to choosing a Python venv for a project. Cella also defines isolation, permissions, resource limits, and governed external operations. Create an environment, work in it, leave, and return later; create another when a task needs different context, dependencies, inputs, or permissions.

Project
  general      -> ongoing agent context, workspace, tools, and scripts
  fix-parser   -> selected inputs and focused task context
  review       -> read-only input, no delivery permission
  experiment   -> separate permitted dependencies and scripts

These names illustrate user choices, not built-in presets. Narrow scope does not imply short lifetime: a focused Cell can be reused, and a general Cell can be explicitly ephemeral. A new Cell receives only selected admitted inputs and context, with its own authority; it does not inherit another Cell's workspace, context, or permissions automatically.

A separate Service Cell is recommended for a long-running service needing its own lifecycle, restart behavior, availability, or resource budget. Ordinary scripts and local task execution remain Agent Cell work; application secrets still require an eligible non-agent runtime and an exact authorized binding.

The Cell lifecycle contract owns these rules. Checkpoints provide recovery and handoff; the repository memory index supplies selected governed knowledge rather than replacing the Cell's working context.

Cells cooperate through declared interfaces. For example, the project agent can call a test backend's named HTTP endpoint through an authorized Channel carried by Relay. This grants the exact request and bounded response, not the backend's credentials, filesystem, or other permissions.

Current Channels are defined around named Service endpoints. Arbitrary agent-to-agent messaging, remote cross-Installation routing, or shared mutable workspaces are not implied by connecting Cells. A future interface for those cases needs its own identity, protocol, policy, lifetime, and evidence contract.

These are intended product workflows. The complete long-running agent, checkpoint/resume, and daily development paths are still in development. See the feature milestones and canonical command flow for their exact boundaries.

The three Cell roles

Agent Cell

An Agent Cell runs the untrusted coding agent. The agent can edit its private workspace and use the tools and connections admitted for that task.

The intended repository workflow imports a reviewed source snapshot into Cella storage. It does not mount the live host working tree into the Cell. The agent produces a Candidate: a result that can be checked, reviewed, and deliberately selected for delivery.

Example: Codex modifies src/server.go and runs tests in its private workspace. Those edits do not silently overwrite the developer's checkout. Access to a service or a credentialed external operation requires separate authorization.

Service Cell

A Service Cell runs an approved task or application independently from the agent. Its code comes from a sealed revision or pinned artifact, and its launch behavior comes from an approved Run Target.

Example: a backend runs in a Service Cell while an Agent Cell tests its HTTP endpoint. The backend can use an authorized database secret without revealing that secret to the agent. A secret-bearing Service Cell has no agent, interactive shell, or debugger attached while its secret lease is active.

The service can continue after the agent disconnects. Updating its code or admitted settings creates a new service generation rather than letting the agent rewrite a running secret-bearing environment.

A Cella Service is the named service identity and endpoint contract. A Service Cell is a runtime that can implement that service. A Connected Service is an explicitly enrolled service outside a managed Cell; enrollment does not make its external execution Cella-contained.

Further reading: Service runtime and data.

Analysis Job Cell

An Analysis Job Cell runs a bounded task against explicitly granted data. It separates data analysis from the coding agent's workspace and from a live service's storage.

Example: an approved job reads a selected database snapshot and produces a classified report. The agent receives an authorized report artifact rather than automatic access to the raw database or the service's writable volume.