Cells

A cell is a tiny connector you deploy into your own cloud account that gives your agents tools over your real infrastructure — list what's running, search logs, scale a service. The Console's Cells page (Connect → Cells) is where you browse the catalog and register your deployments; the cell itself runs in your cloud under its own role, so your cloud credentials never leave your cloud account.

How a cell works

• A cell is a small, pure-source function (you can read every line) that speaks a simple HTTP protocol: GET /manifest (describes its tools), POST /call (invokes one), plus GET /healthz and GET /tools.
• You deploy it in your cloud — AWS Lambda, Google Cloud Run, Azure Container Apps — where it uses the function's own IAM role / service account for cloud access. No cloud credentials are ever uploaded to OpenEng.
• You put your cloud's API-key gateway in front of it (AWS API Gateway / GCP API Gateway / Azure API Management); the cell does no authentication of its own. The cell deploy guides set that gateway up to validate an x-api-key header.
• OpenEng connects to the cell from your machine: the engine calls it with the credential you registered, sent as an Authorization: Bearer token, so the gateway has to accept that header for your agents to use the cell's tools.

The catalog holds 550 cells as of 2026-09-25, one cloud service each: 260 for AWS, 150 for Azure and 140 for Google Cloud; 435 are read cells and 115 are write cells.

Read vs write

Every cell has a type, and it's enforced:

The Cells page: two tabs

Catalog — the shipped default cells (cell_def_…), browsable read-only as cards: read/write badge, version, a short description, the tools the cell exposes, and a Register deployment button that pre-fills the registration. The catalog comes from the content CDN; if the CDN can't be reached, the page shows the last loaded copy with a "may be stale" notice. Cell packages (source, deploy.sh, per-cloud quick paths) are downloaded from cells.openeng.app, linked at the top of the page.

My deployments — every deployment you've registered, as a table: name, id, type, number of tools, the config it's attached to (or unassigned when no config uses it yet) and when it was last updated.

Registering a deployment, step by step

The register flow (Register deployment, or ⌘K → Register cell deployment) walks four sections:

1. Cell — pick a catalog cell (seeding the name, type, and tool list verbatim) or start a Custom cell for your own code. If a catalog entry carries envVars or staticParams, the editor says so and drops them: the engine doesn't read them from a config.
2. Deployment URL — the gateway URL in front of your function. Required — the engine drops a cell entry without one.
3. Credential — one or more ${ENV_VAR} rows (Add variable); a raw value is refused outright. The first row is the credential the engine sends with each call, as a bearer token (Authorization: Bearer …); extra rows publish as numbered siblings for cells whose handlers need additional variables. Each row is resolved on each machine from its environment or from the value stored for the config on the Web Console's Placeholder values screen; the environment wins. A missing variable disables the cell there, with a message naming it.
4. Read/write confirmation — confirm the type; write cells show the consequence copy before the editor lets you Save.

Like every console editor, registration writes only when you press Save (disabled with the reason while a required field is missing); your in-progress entries mirror to a local browser draft until then. Deployment rows in My deployments carry trailing Edit / Delete actions, with delete behind a confirmation; a deleted deployment disappears from machines on their next config pull.

Under the Credential section, the editor previews the line a machine reports while the variable is missing:

cell "prod-aws" disabled — set PROD_CELL_KEY to enable it

There is deliberately no test/ping button: the Console never contacts your infrastructure. Discovery and verification happen from your machine when the engine first connects.

Using cells

A config uses the deployments you pick in the config builder's Cells step (Configs); only registered deployments with a URL can be picked, so register a catalog cell before you select it. When the engine serves the config, it loads the config's cells (its log says cells registry — N from config), and your agents can call their tools — just ask. Read cells answer in any run; write cells only in execution runs. A Human-in-the-Loop rule can require approval before any call to a given cell, or to every cell.

Writing your own cell

Take a BYOC starter (AWS / GCP / Azure) from cells.openeng.app, edit one file: set the id, the type (read or write), declare the tools with their parameters, and implement each handler with your cloud's SDK. Deploy like any other cell. Keep read cells genuinely read-only — put actions in a separate write cell so the read/write gating protects you.

Plan & tier notes

The Cells page — catalog and registration — is open on every plan with no count limit. Running cells needs the openeng engine, which registers only with an active Pro plan; Pro launches in Q4 2026 and can't be purchased yet (Plans & billing).

Troubleshooting

cell "<name>" disabled — set <VAR> to enable it on a machine. The cell's ${ENV_VAR} has no value where the engine runs. Export it in the shell that starts the engine (export PROD_CELL_KEY=…) and restart the engine, or give it a value on the Web Console's Placeholder values screen — OpenEng never sends an empty secret.

The cell answers HTTP 401/403. The gateway rejected the credential. Check that the variable holds the key your gateway issued and that the gateway has a usage plan or key attached. Also check which header the gateway reads: the engine sends the credential as Authorization: Bearer …, while the cell packages' deploy guides set the gateway up to read x-api-key.

The engine skips the cell entirely. Three causes, all by design: no URL/name saved (the editor prevents this), the https law (credential over plain http to a remote host), or disabled: true on the entry.

A write cell doesn't appear in the toolbox. Write cells are only available in execution runs. That's the safety model, not a bug.

Unreachable when the engine first connects. The Console never tested the URL (by design). curl the gateway URL from the same machine — wrong URL, undeployed function, or network policy are the usual suspects.