Architecture

The AI employee and the workspace are the mental model. This page is their mechanism: how a cell is isolated, how an employee is summoned per event and made continuous, how it acts on your behalf without ever holding your tokens, how it fans work out to specialists, and how the three repos connect from the marketing site down to your cell.

The cell: an isolated container and data store#

A cell is one customer's workspace: a folder of standard Claude Code files plus a Brain/ memory vault, running in its own container. The container is the isolation boundary; the folders inside it are the data. Each customer's data lives in its own cell, and the employee runs inside it, reached through whatever gateway you use.

Inside a cell, /workspace holds CLAUDE.md (a thin manual that imports the house rules), a .claude/ tree (agents, workflows, rules, skills), and Brain/ (the vault: STRATEGY.md, PLAN.md, MEMORY.md, and wiki/ topic folders). The Brain/ is two things at once: the durable memory, and the coordination bus. Employees hand work to each other by writing files that other employees read.

The container is the persistent thing, configured to restart on its own; the employee process is not. Each cell also gets its own database, isolated from every other tenant, and a fresh cell starts from a clean scaffold so no tenant data can bleed into it.

The employee: spawn-per-event, made continuous by durable resume#

The employee is not a daemon. It is a claude process spawned per event or per session, and made continuous by resuming a durable transcript. A deterministic session id, computed from the workspace and the task, lets a fresh process pick up exactly where the last one stopped. This is what makes a follow-up feel like a coworker who remembers yesterday, without anything running in the background between events.

One inbound event maps to one run. Adding an assignee to a task triggers a fresh run; a new comment on that task resumes the same session. The run never forks the session (forking would mint a new id and break continuity) and never discards it.

# First run on a task pins a durable, deterministic session id
claude -p "<prompt>" --session-id <id> \
  --setting-sources project,local --agents @agents.json

# A later event on the same task resumes that exact transcript
claude -p "<prompt>" --resume <id> \
  --setting-sources project,local --agents @agents.json

The employee is vanilla Claude Code. Jetsyn lays files in the conventional locations and the stock CLI assembles the prompt at launch from the cell's own files, loading project and local settings and the validated per-run sub-agent definitions. Nothing in an employee definition is Jetsyn-proprietary; the platform adds only the sandbox, the gateway, and the UI.

The runtime seam

A single dispatcher, run_task(), is the one public entry for a headless run, so every caller stays runtime-agnostic. It selects a runtime from JETSYN_AGENT_RUNTIME, and any unrecognized value falls back to the proven path, so a typo never strands a run on an unbuilt one.

Credential isolation: the employee never holds your tokens#

The rule that the employee never holds your tokens is enforced in code, not by policy. It works on two layers.

The model credential. The employee's only provider credential is a per-workspace gateway token, injected as ANTHROPIC_API_KEY by a routing overlay that points ANTHROPIC_BASE_URL at the relay. Before the process launches, its environment is scrubbed of every secret, then self-checked: if any denylisted secret survived, or the injected key is anything other than the gateway token, the launch is refused. The employee reaches the model through the gateway, never through a raw provider key.

Tool tokens. The employee holds no ClickUp, CRM, or Sheets token. To act in a tool it writes an intent, a small JSON file into runs/<task>/intents/, through a credential-free tool server. A privileged parent process drains that queue and performs the side effect. The queue is cleared at the start of every turn, so a resumed run can never re-execute a prior turn's actions.

Sub-agent fan-out#

An employee spawns specialists rather than doing everything in one context. There are two paths, and in both a sub-agent never carries the Task tool, so there is no recursive fan-out.

In the headless workflow path, an orchestrator runs a workflow that calls named sub-agent steps in order, with a hard completion gate between each: a step does not start until the previous one emits its completion signal, so a run stops rather than advancing out of order. The per-run sub-agent definitions are validated before the process starts.

In the interactive path, the terminal employee dispatches two generic, composable sub-agents through its Task tool:

Every callable sub-agent is a standard .claude/agents/*.md file. To give an employee one more specialist, drop a definition in that folder; to author a full multi-step employee, see Build an AI employee.

The three repos and how they connect#

Jetsyn is a polyrepo of three decoupled repos. The marketing site, the login and app surface, and the backend spine each ship independently.

They connect in one direction, from the marketing site down to your cell:

jetsyn.ai            marketing site + public docs (this site)
   |  sign-in and the magic-link email point at the app
   v
app.jetsyn.ai        login / onboarding / billing + the /agent and /pro surfaces
   |  a thin relay: forwards your session to the backend, holds almost no logic
   v
admin.jetsyn.app     the spine: the one authority on auth and entitlement
   |  resolves your ONE cell, signs a short-lived handoff, dispatches the run
   v
<slug>.jetsyn.app    your cell: a per-tenant container with its own
                     database and /workspace volume

Two facts a builder relies on. First, app.jetsyn.ai and admin.jetsyn.app are different origins, so the app cannot read the backend session cookie directly; nearly every meaningful app route is a thin relay that forwards your session to the backend at JETSYN_API_BASE (default https://admin.jetsyn.app). Second, a user maps to exactly one cell, resolved identically whether you arrive from the web or the CLI, so every surface reaches the same folders.

What survives a process death#

The employee process is ephemeral by design. Everything durable lives on the cell's persistent volume, not in the process.

The split is the architecture: the cell persists, and the employee is summoned.

Where to go next#