Folders & memory

In Jetsyn, customer data is not rows in a database. It is folders on the cell. A single folder is a topic of data, a permission boundary, and a UI tile at once, and every surface reaches it through the same four operations. Capture, sharing, and display all collapse onto one primitive.

A folder is three things at once#

The folder is the unit of data. One filesystem directory carries three facets at the same time, so you never store data in one place, set permissions in a second, and design a screen in a third.

Why a folder and not a database row. A row needs a schema, a migration, and a renderer written in code before it can exist or show up on screen. A folder needs none of that. An employee, a person, or an automation can create one at any time, drop files in it, and it is immediately real data that any surface can render. The filesystem is the schema. This is what lets your employee extend the workspace at runtime, with no deploy.

The cell tree#

All customer data lives as folders on a per-tenant cell volume. Inside a cell, config.workspace_root(slug) resolves to /workspace, the employee's working directory. Postgres holds operational rows only, such as accounts, memberships, and billing. It never holds knowledge bytes: those are always files on the volume.

/workspace/                       # the employee's working directory
  workspace.json                  # the company record shared by web and CLI
  CLAUDE.md                       # the cell manual
  .claude/
    agents/<role>.md              # the roster: assistant, sdr, coach, ...
    workflows/<name>.workflow.js  # multi-agent workflows
    rules/*.md                    # house rules
    tasks/                        # the task board
  Brain/                          # the company memory vault
    STRATEGY.md                   # the config every agent reads
    PLAN.md                       # the ranked plan + the roster
    MEMORY.md  index.md  log.md
    wiki/{entities,concepts,projects,daily,logs,tasks,decisions}/
  runs/<task>/                    # one folder per run: progress + artifacts
  seats/<id>/                     # per-seat memory (the company brain)

Two files in Brain/ are the company config. Brain/STRATEGY.md holds the identity, ICP, offer, positioning, and the metric that matters now; it is the file every other agent reads its configuration from. Brain/PLAN.md holds the ranked path to the goal plus the roster, meaning which agents are on the team. Change either file and every agent picks up its new slice on its next run, because the config is just files in the shared folder.

workspace.json, the shared company record#

The company record lives as workspace.json at the cell /workspace root. It is the one store that the web workspace and the CLI both read and write, so there is no second database to reconcile. It carries the company metadata under a fixed whitelist, name, idea, slug, status, and plan, capped at 20KB.

Writes are cell-canonical: the cell file is the source of truth, and the control plane keeps a mirror so a brief cell outage never loses data. The backend resolves the cell from your session, so a caller never passes a slug.

The four folder operations#

Every surface, the web app, the Pro console, and the CLI, touches a folder through exactly four operations and nothing else. This one transport is the mechanism behind one store, many surfaces: there is exactly one way to reach a folder, so no surface can diverge from the files.

Every op is confined by a path resolver that rejects .., absolute paths, and symlinks that escape the cell, so a read or a write can never leave /workspace. All three surfaces funnel through one proxy that dispatches these four ops.

from jetsyn.cells import router

# Read a file from the shared store
router.dispatch_console_op(slug, "read", {"slug": slug, "path": "Brain/STRATEGY.md"})

# Write the employee's output back to the same store
router.dispatch_console_op(
    slug,
    "write",
    {"slug": slug, "path": "runs/demo/progress.md", "text": "done"},
)

The company brain#

The permission facet of the folder is what makes team sharing work without a second system. A company is an org chart of seats, and each seat owns a scope, a folder under Brain/company/ with a classification that sets its default visibility.

• all: every seat reads it, the company handbook. Default allow.
• role-set: only cleared seats. Default deny.
• author-only: only the owning seat, plus explicit grants. Default deny.

Access resolves in a fixed order: an explicit grant or deny wins first, then all-classified scopes are readable by everyone, then a seat may read down its own branch of the org chart. A manager reads a report's scope; a report never reads up by default. Writes are strictly tighter, since a seat writes only its own scope. Rather than filter at read time, the engine rebuilds a per-seat, read-only copy of only the cleared scopes, so forbidden bytes are never present on that seat's filesystem. Every write is versioned and audited.

Publish-up is how personal work reaches the company store. When the employee writes a company-topic note, it saves to your brain and, per the folder permission, proposes the copy to the company folder. Private memory is structurally excluded from that walk, so it cannot be published by construction, not by a filter that could fail open.

From folder to tile#

This is how custom data becomes visible. A folder becomes a tile with no code change: drop a file into a folder on /workspace and it is real data the moment it exists. There is no backend type registry to update and no schema to migrate.

The Pro console renders the cell's real tree directly, so a file the employee just wrote, or one you created by hand, appears in the tree automatically. The file is canonical and the tile is a projection that re-reads it, so a raw edit from the CLI shows up in the web app immediately, never as a second copy of the truth.

Where to go next#