Memory and conversations

An Isolation agent remembers between sessions because everything it would need to remember lives in the workspace tree, not on the server. An agent view is one conversation with one agent, and that conversation, the agent's memory note and its whole HOME sit under /workspace/.isolation, which rides workspace persistence to R2 with the rest of your files. Wipe the server, launch the workspace somewhere else, and the agent picks up where it left off.

One view, one conversation

Open an agent view and you get a real harness session in the browser, driven over ACP: replies stream as they are written, every tool call is shown, file changes appear as diffs, the harness asks for permission when its mode requires it, and the harness's own slash commands and modes work as they do in a terminal. Claude Code, Codex and goose all speak ACP, so the view is identical whichever harness the agent's credential selects.

The view is the thread. Its stable key is the view's workspace-level id, so the same window in the next session is the same chat. The transcript is written to /workspace/.isolation/threads/<key>.json after every turn, together with the harness's own session id, which is what lets the harness reload its context instead of starting cold. Nothing chat-shaped is kept on the server. A thread is reachable only while a session of its workspace is running; agents run inside sessions, by design.

Memory: one note per agent per workspace

Separate from the conversation, each agent keeps one short markdown note per workspace at /workspace/.isolation/agents/<agentId>/memory.md. It is read at the start of every turn, and the agent maintains it with two of the in-sandbox tools, memory_read and memory_write (with an append option). The agent's instructions tell it what the note is for: facts about the project, decisions taken, what it was doing. Keeping it short is part of the contract, because the whole note is loaded every time.

The note is a file like any other. You can open it in the code view, edit it, or delete it to give the agent a clean slate for that workspace.

A HOME that follows the workspace

Each agent has its own HOME inside the sandbox, at /workspace/.isolation/agents/<agentId>/home. That is where the harness keeps its session store, its instructions file (.claude/CLAUDE.md for Claude Code, .codex/AGENTS.md for Codex) and its configuration. Because the HOME is under the workspace tree, it is committed to the session branch and bundled, encrypted, to R2 at every save. A Connected Server today and a Cloud Server tomorrow see the same HOME, the same conversation and the same memory. This is the same rule that keeps your code safe, described on nothing lives in the sandbox.

Credential material is the exception. Paths where a harness might write a login file are listed by the harness and turned into a .gitignore inside the HOME before they can exist, so a secret never rides a bundle or a branch.

/workspace/.isolation/
  threads/<viewKey>.json            the conversation, plus the harness session id
  agents/<agentId>/memory.md        the agent's note for this workspace
  agents/<agentId>/home/            the harness's HOME: session store, instructions, config

The same conversation from anywhere

The agent view runs behind an in-sandbox bridge that fans out to any number of clients, so one conversation can be joined from several places at once:

• The browser, through the doorman, as the agent view.
• A terminal: ssh -s <route>@ssh.isolation.cc acp renders the same conversation in your shell, with nothing to install. /ssh in a chat or "Open externally" on the view gives you the exact line. See work from your IDE.
• A chat app. A mention in a Slack, Teams or Buzz channel that is connected to the session reaches the agent in a thread keyed to that chat, so it keeps the context of that channel across turns and across sessions, and you can open that thread in the browser too.
• An MCP client or a chat command: /ask Isla fix the login bug is one turn through the same route and returns the reply as text.

Inside the sandbox the agent sees all of this through one MCP server, with tools for its memory, for messaging another agent's thread, and for the chat it was mentioned in. The full list is on inside the sandbox.