Why we’re building Cella.

Start with the workspace.

An agent needs a place to work: source code, build tools, and the dependencies required for a task. In Cella, that execution happens inside a Cell.

An Agent Cell gives the agent its working environment. It can inspect files, make changes, and run the tools permitted by policy. Host resources and credentials are separate concerns.

Isolation is part of the foundation. The larger question is how that environment interacts with everything around it.

Execution and authority are different things.

Being able to run a command does not have to mean possessing every credential that command might use. The environment that executes agent code and the components that hold privileged authority can have different responsibilities.

In Cella’s architecture, Wall contains Cell execution. The daemon coordinates work and policy decisions. Gateway performs permitted external actions using credentials kept outside the agent environment.

For example, an agent may request a Git push. That can become a narrowly scoped operation for one repository and an allowed branch, while the credential stays with the trusted component that performs the push.

Permissions should describe the action.

“Can this agent access the network?” is one useful question. “Can this agent push this change to this repository and branch?” is another. File access, tool use, credentials, and external effects each need their own scope.

The intended policy layer connects these decisions to the work being done. A permitted test run should not silently become permission to read a host SSH key or deploy to an unrelated system.

{
  "action": "git.push",
  "repository": "acme/backend",
  "branch": "feature/health-check",
  "decision": "allow"
}

An illustrative decision, not Cella’s configuration syntax.

This is the distinction we care about: a capability can authorize a specific operation without putting a reusable secret in the agent’s hands.

The work can outlast the session.

A coding session is only one part of a development workflow. A workspace may be reused. An application may need to keep running. A later task may require a separate environment with tighter permissions.

Cella’s Agent Cells and Service Cells address different parts of that work. An agent operates on a private candidate; a Service Cell runs an approved application revision with its own lifecycle and scoped runtime access.

Channels describe authorized connections, and Relay carries that traffic. The intention is to make those relationships explicit as work moves between agents, applications, and external services.

Make the decisions inspectable.

A boundary is easier to understand when you can inspect what crossed it. The useful record includes the agent, action, resource, policy decision, result, and time.

That evidence can help explain why a push was permitted, why an operation was refused, or where a task stopped. It supports debugging and review alongside security.

We want someone returning to a piece of work to understand what happened and which authority was used, without reconstructing the entire session from a terminal transcript.

Build it, use it, learn from it.

We’re building Cella for work we want to do ourselves, and making the project open source so others can inspect it, try it, and challenge the decisions.

The test is practical: do the boundaries help people do real work? Are permissions understandable? Does the evidence explain what happened? Can the workflow stay useful as the work becomes more involved?

Those are the questions we want to keep answering through the software.