The Jellyfish Assistant Get updates

Architecture

Read the system before you run it.

The Jellyfish Assistant is a set of separate parts with written rules between them. Each boundary has a contract that says what it owns, what it allows, and what it deliberately doesn't do — and because the contracts are public, anyone can build on them.

How a request moves

One door in, a watched way out.

How a request moves through the Jellyfish Assistant Clients connect through a reverse proxy to the front door, which handles sign-in, second factor and roles. The front door passes requests to the agent host, which handles routing, semaphores and confirmations. The agent host reaches model providers, tool servers and the Memory Core. Model providers and tool servers reach the internet only through the egress layer, which uses an allowlist by default and logs every request. Memory modules may not open a socket. Clients Browser, voice, or a client you build Reverse proxy TLS; the only way to the front door Front door Sign-in, second factor, roles Agent host Routing, semaphores, confirmations Model providers Local or frontier, chosen per task Tool servers Sandboxed, one per capability, off until enabled Memory Core Sandboxed modules; an encrypted file per person Egress layer Allowlist by default; every request logged The internet Modules may not open a socket

Model providers and tool servers reach the internet through the egress layer, which logs every request. Tool servers, memory modules and pages each run sandboxed.

Nine ideas

What holds it together.

08

One front door

Every client comes through one authenticated door, and its contract documents every message. Writing a client of your own means reading one document, not reverse-engineering one.

04 §2.4

The model chooses from a menu

Routing is three steps — server, tool, arguments — each constrained so the model can't name a tool that doesn't exist.

05

Your models, by your rules

Local and frontier models sit side by side behind one neutral interface; you pick the model for each task and what it may see.

04

Tools are sandboxed servers you turn on

Each capability is its own sandboxed process, off until enabled, holding only its own credentials.

02 · 03

Memory is a core with sandboxed modules

A small core holds the data; features plug in as modules; each person's memory is a separate encrypted file.

01 §2.14

One key, sealed to the machine

Everything stored is encrypted under keys derived from one master key that opens only on that machine; a printed recovery key brings it back.

06 §6

A watched way out

By default nothing reaches the internet except through a per-tool allowlist. Tools you trust with open-ended work, like web search, can reach new hosts as they go. Either way, every request is logged.

06 §7

Semaphores

A conversation carries flags about what it has touched, and rules act on them. Today they mark outside content and make outbound tools ask first; a builder for your own flags and rules is planned.

06 §4.8 · §5

Any act can be gated

Roles say who may do what; any act can require your confirmation, and a PIN if you choose; destructive acts are gated by default.

Build on it

The contracts are public.

So anyone can layer onto or modify their own system: a client, a tool server, a memory module, a page, a model provider — first-party, third-party, or their own. Each contract names exactly what an add-on must declare and what it may assume, and the sandbox holds it to that.

The contracts

All nine, in full.

The contracts

Published here on October 20.

The nine contracts — the standard, paths and credentials, the Memory Core and its modules, tool servers, providers, security, chat history and the front door — will be readable here, in full, with the release.

Honest limits

What it doesn't defend against.

Anyone with a shell on the machine, as the user the system runs as, can read what the running system can decrypt.

Prompt injection is reduced, not solved.

Every known gap, in contract 06 §8 →