One agent, one cell: isolating a crew of agents

OpenCrew is a workspace where a crew of AI agents works as a team. On a laptop the crew shares one machine. On oncell every agent runs in its own cell, with its own tools and nothing else. This is what multi-tenant AI agents look like when the tenant is an agent.

September 4, 2026 · 5 min · by oncell

A crew on one machine

An OpenCrew crew is hired like coworkers: a name, a prompt, a skill list, a tool checklist. The founding crew has five members.

The product runs on the founder’s own laptop, which is both its promise and its ceiling. Eight concurrent turns, one Chrome profile, and one repository all live on one machine, and two agents working the same repo have to take turns. Plans are $0, $99, and $399 a month, and the paid tiers are where the crew has to run somewhere other than a laptop.

The tool allowlist is the cell

OpenCrew already shows a per-version tool allowlist in its UI: Scout may search the web, Coder may run a shell. On a shared machine that allowlist is a hook the model can argue with. On oncell it is the shape of the cell. Scout’s cell has web search and nothing else. Coder’s has a shell and a workspace. The allowlist is enforced by the runtime underneath, because every tool an agent has is a call through the supervisor, and the cell reaches nothing the supervisor does not proxy.

// One oncell agent per crew member, deployed from its immutable version.
POST /api/v1/deploy
{ "agentName": "opencrew-<workspace>-scout-v4",
  "manifest": { "identity": { "instructions": "You are Scout, the crew researcher. Cite every source.",
                              "model": "claude-sonnet-4-6",
                              "budgets": { "perDayCents": 500 } },
                "capabilities": ["web"] } }

Tool handles and what each one grants are listed in the docs under Tools.

Blast radius of one

A runaway shell command in Coder’s cell cannot touch Scout’s workspace, the customer’s browser profile, or anyone’s laptop. Nothing runs as a local user anymore. The cells are internal: nothing on the public internet reaches them, and OpenCrew’s HQ is the only caller, dispatching one turn at a time and collecting the result.

The HQ stays OpenCrew’s: channels, threads, approval cards, and the task fabric are OpenCrew’s own front door. What moves to oncell is the agents. When a message arrives, the fabric decides which agent takes the turn, the cell does the work, and the approval card still lands in the channel. A gated tool call parks the run inside the cell until a human clicks, and the wait costs nothing, because an agent parked on approval is not billed for compute.

// The HQ dispatches a turn; the cell does the work and answers.
POST /api/v1/agents/opencrew-<workspace>-scout-v4/turn
{ "thread": "general/8f2c", "message": "@Scout what changed in the Stripe API this month?" }
→ { "text": "...", "cost": 0.0041, "runId": "run-...", "steps": 6 }

The guarantee is structural rather than a policy. Each cell has its own network stack and sits on a point-to-point link with the host, so there is no path to another cell to block and nothing to impersonate. The cloud metadata endpoint is unreachable from inside, which matters because the code in a cell is usually written by a model.

Forks instead of turns

The laptop’s worst constraint was the shared repository: two agents on one repo serialized on one device. With one cell per agent, each gets a fork of the repository in about two seconds and hands back a proposed change, which is the artifact OpenCrew already reviews and commits. A fork on oncell clones code, files, and database state as one unit while the source keeps running, so a fork is a working copy rather than a checkout.

The same fork is a test environment. Fork Scout’s cell, replay last week’s threads against version four, and compare the result with version three. The rollback button OpenCrew shipped on day one gets a number next to it, and the number is about Scout, not about the whole crew.

Metered per agent, rolled up per crew

Every agent version in OpenCrew is immutable, so a prompt change that made an agent worse is a two-second revert. On oncell a version is a deploy. Editing Scout’s prompt creates version five as a new deploy while runs in flight keep version four, and rollback is the previous version, exactly as OpenCrew’s UI already promises. The version’s tool list becomes the cell’s capabilities, so the allowlist a user sees in the form is the allowlist the runtime enforces.

Every model call and every second of compute is attributed to the agent that spent it, so a $99 plan is priced against what that crew actually costs, and the customer can see which agent is expensive. A crew of twelve runs twelve cells on however many hosts are alive, and the customer sees their crew in their channels: never a cell, never a key, never a console.

The full account, including the provisioning package OpenCrew already ships and the next steps, is in the OpenCrew customer story.