Camillo
VMEM
An open format for user-owned agent memory.
An agent’s value compounds with what it knows about its user, and that accumulation is the most sensitive data the user produces. Today it is either held by the vendor that runs the agent, where the user cannot read or export it, or kept on a single device, where it is one failure from gone. VMEM defines a third arrangement: a vault in the user’s possession, encrypted wherever it is stored, which any agent can use with a grant and none can read without one.
Read the white paper
Two patterns, both failing
Vendor memory
The agent’s operator keeps your history and its derivatives on its own infrastructure, behind its own API. Durable and effortless, but the vendor can read it, an export is a dead artifact, and switching agents means abandoning the accumulated relationship. Memory becomes the deepest lock-in in the stack.
Local-only memory
The history stays on your device, readable by no one else. Also one stolen laptop from unrecoverable, unavailable to your other devices, and usable by one agent at a time. The user is asked to choose between privacy and durability.
VMEM
A vault you hold: encrypted everywhere it is stored, carried by any sync service you already have, shared by many agents under scoped grants, auditable, revocable, and erasable. The guarantee is a format, not a service.
What a vault holds
The vault holds the complete record of one user’s relationship with their agents: not a store of distilled facts with the conversations discarded, but the full substance. Raw history is canonical, and everything else cites what it was derived from.
- Messages, grouped into conversations: the raw history, from the user, agents, and tools.
- Facts: assertions about the user or the world, keyed by subject and attribute so that memory can be merged.
- Preferences and instructions: how the user wants agents to behave.
- Events and decisions: what happened, what was chosen, and when.
- Supersessions, tombstones, and confirmations: changes to other records.
- Keyring and grant records: who can read and write what.
- Attachments: bulky material such as tool output and files.
How it works
- Append-only and causally ordered
- Agents add records; nothing is modified in place. Every batch names the latest records its writer had seen, so history is a hash-linked graph and ordering never depends on device clocks. Merging copies is a deterministic union of records: concurrent edits to the same key are reported as a conflict, and a deletion wins over a concurrent edit.
- A folder that packs into a file
- A live vault is a directory of immutable segments, each named by the hash of its contents and written exactly once, so sync services have nothing to conflict over. The same records pack into a single .vmem file for export, transfer, and archiving.
- Self-unlocking
- The vault carries its own keys, and every credential is a public key the vault keys are encrypted to: a device keypair, a passphrase through a memory-hard derivation, or a BIP39 recovery phrase. Content is encrypted under compartment keys that change in epochs, so revoking a credential begins a new epoch and a revoked device cannot read anything written after its removal.
- Scoped access
- Compartments such as personal, work, and health hold their own keys. An agent holds one of three levels per compartment: owner, reader (read and append), or appender (append only, unable to decrypt what is already there).
- Attributable
- Every writer signs every record, so which agent wrote a record is a verifiable fact, and every change is an ordered, attributable event. Each record also carries an authority class — user, observed, inferred, or external — and only the user class can bind as an instruction, which keeps injected content from becoming a standing command.
- Erasable
- Deletion is cryptographic. A tombstone hides a record from agents; to erase it, the epoch’s surviving records are re-encrypted under fresh keys and the old keys are destroyed, which makes every remaining copy, including in a sync service’s version history, unreadable.
- Bounded by design
- Records are padded to size tiers; compaction moves superseded records to an archive rather than discarding them, because they are provenance; completed periods roll into archive packs; bulky attachments are stored separately. Embeddings never enter the vault at all.
Cryptographic choices
The format invents no cryptography. Every primitive is standard and widely implemented.
| Content encryption | XChaCha20-Poly1305 |
|---|
| Encrypting keys to recipients | Hybrid X25519 + ML-KEM-768 |
|---|
| Passphrase to keypair | Argon2id, parameters stored in cleartext |
|---|
| Recovery phrase | BIP39, at least 128 bits of entropy |
|---|
| Signatures | Ed25519, tagged with algorithm identifiers |
|---|
| Content addresses and record IDs | SHA-256 |
|---|
Out of scope
VMEM governs memory at rest and between copies. It does not govern what happens to memory while an agent uses it: memory has to be decrypted to be useful, and the plaintext then passes through a model. Where that model runs, and under what protections, is a choice for the agent harness and the user. Computing embeddings for search is inference in this sense and sits on the same side of the line.
Governance
A format controlled by one company is that company’s silo with extra steps. Camillo commits to:
- The specification is published under an open license, with a royalty-free patent commitment.
- The reference implementation is released under Apache-2.0.
- The specification is versioned, with a public conformance suite and test vectors so independent implementations can prove compatibility byte for byte.
- Stewardship of the specification moves to a neutral body once independent implementations exist.