Jern Cloud docs

Repository memory.

The agent can keep notes to itself about a repository: how it builds, how it tests, what it learned. Jern Cloud keeps one memory per repository between sessions, encrypted, and shows it to you in the open.

• Getting started
• Sessions
• Policy
• Triggers
• Schedules
• Skills
• Environments
• Browser
• Memory
• Knowledge
• Receipts
• Spend
• Provider keys
• Settings
• MCP server
• Recipes
• FAQ and limits

The rules

• One per repository, never across. The memory is keyed by the repository; a session on another repository never sees it.
• Encrypted at rest like snapshots and caches, under the evidence keys, with a subject bound to the repository. Only its size and digest are readable without the key.
• Gated by the baseline. The runtime consults the memory only when the policy's memory key allows it. A cloud session has nobody to ask, so an absent key means denied; a baseline that wants it says "memory": "allow".
• Never committed. The runner keeps .jern/memory.json out of git and removes it before the workspace is published. A repository that tracks the file itself keeps its own copy and gets no restore.
• Visible and editable. The Knowledge section of the repository page shows the memory decrypted, and anyone who can start sessions on the repository can edit or delete it.
• On the record. Every read and write inside an attempt is on the trace and the receipt; each write back, and each edit or deletion in the dashboard, is a workspace audit event. The attempt card says whether the memory was restored or updated.

How it flows

1. After checkout, the runner asks Jern Cloud for the repository's memory under its lease and writes it to .jern/memory.json, writable by the agent alone among the non-publishable paths. With nothing stored, an empty file stands in so the runtime can create one.
2. The agent works; the runtime reads and writes the file as the policy allows, through its memory_read and memory_write tools.
3. Afterwards, if the file changed and still holds a memory document, an object of strings of at most 256 KiB, the runner sends it back; Jern Cloud canonicalises, encrypts, and stores it, and records the attempt as its author. The file is then removed from the workspace.

Why it is in the open

The memory is text the agent wrote to itself, and the one place an instruction injected during a session could survive into the next. That is why it is shown decrypted on the repository page, why anyone who can start sessions can delete it, and why it is under the same policy as everything else the agent touches. If a note looks wrong, delete it; the next attempt starts from nothing.

Memory, knowledge, conventions, and skills

Four things tell the agent about a repository. CONVENTIONS.md is what you write for every change. Skills are what you write for particular tasks. Memory is what the agent writes for itself. Knowledge is what people hold to be true about the repository, with the evidence for it, and only a person holds a claim. Only the first two are code your reviewers see in pull requests; memory and knowledge are visible on the repository page instead.