Durable context

Durable context is the knowledge an agent needs beyond the session that produced it: the decisions made, the findings of an investigation, the instructions it follows, the state of work in progress. slivingdoc keeps it as a shared notebook of plain text files in durable storage, so it survives the end of a session, a lost machine, and a change of agent. For fleets of AI agents working together, this is agentic durable context: one record that every agent reads from and writes to.

Where context gets lost

An agent’s working context is short-lived by default:

• The context window is gone when the session ends or is compacted.
• A local file lives on one disk. CI jobs, sandboxes and scheduled agents lose theirs after every run, and a laptop’s notes never reach the agent running in production.
• One agent’s memory is not another’s. Claude Code, Codex and any other MCP host each keep their own, and a fleet of agents cannot read what its siblings learned.

Context that has to be rediscovered costs tokens, time and mistakes.

What makes context durable

slivingdoc treats context as data with three properties:

• It outlives the session and the machine. The notebook lives in hosted storage on slivingdoc.dev or in your own S3-compatible bucket. Once committed, everything slivingdoc keeps on a local disk can be thrown away and rebuilt from it. See Storage model.
• It is shared. Every agent and every person pulls the same notebook and commits changes back. Concurrent, non-conflicting edits are merged with Git semantics; overlapping edits return a conflict instead of silently overwriting accepted work. See How it works.
• It stays plain text. Notes are ordinary UTF-8 files that agents read and edit with the file tools they already have, and people edit with any editor. There is no schema to agree on, and agents and people need no protocol between them.

slivingdoc keeps the current state durable; it does not promise historical recovery and is not a backup product. See Guarantees and limits.

Durable context in practice

• One context for every coding agent. A decision written in one session is there in the next, whichever MCP host runs it. See Connect an MCP host.
• Memory for short-lived runners. The next CI run or scheduled agent starts where the last one stopped. See From scripts and cron.
• Instructions you change at runtime. Keep shared instructions under read-only paths, edit them from the command line, and every agent reads the new version on its next pull. See Read-only paths.
• Context shared with people. Colleagues pull and commit the same notebook from the command line. See Share a directory.

To start, follow the Quickstart.