This page documents a design that is published ahead of availability. The architecture, data model, and durability semantics below are settled. The client libraries are not yet released, and this page intentionally carries no dates and no pricing. It describes how the system is built, not something you can install today.
Why agents need this
An agent that loses its state between invocations cannot be held to a decision it made earlier. That much is obvious, and hosted memory products solve it. What they do not solve is the second problem. When memory is load-bearing, the agent’s owner eventually needs to answer a question about the past: what did this agent know, when did it know it, and can you show me that the record has not been altered since. A hosted store answers that with a service agreement. It cannot answer it with evidence, because the store is also the party being asked. Agent Memory separates those roles. The record is append-only and content-addressed, so alteration is detectable. Retention is funded by Everlight and evidenced by storage challenges, so continued possession is demonstrated by parties other than the one making the claim.System layers
Data model
Three objects, one invariant.
The invariant is that the log is append-only. Entries are never edited and never deleted. A correction is a new entry that supersedes an earlier one, which means the history of what the agent believed remains intact and auditable rather than being overwritten.
Sealing entries into segments is what makes the economics work. One chain action per entry would be unaffordable. One action per sealed segment, with the manifest providing individual addressability, gives per-entry granularity at per-segment cost.
The latest manifest CID is the portable root of the entire log.
Durability states
The design refuses to present a fast acknowledgement as durability. Every entry is in exactly one of three states, and the client always reports which.
The window between
accepted and anchored is the only centralized durability window in the system. It is handled by keeping it short and by never describing it as anything else. A write returns accepted, and an acknowledged write is not represented as funded permanence.
This distinction is the point of the design rather than a caveat attached to it.
Encryption
Encryption is on by default and is not a configuration option. The client generates a log key and encrypts each entry before any bytes leave the agent’s process. The gateway, the SuperNodes, and the chain see ciphertext only. Retention proofs operate on ciphertext and are unaffected, which produces the useful property that the network proves it is still holding data it cannot read. The consequence is stated plainly rather than buried. Losing the log key means losing the memory. There is no escrow and no recovery path in the design. Logs can optionally be created public, in plaintext, for cases where visible content is the purpose. Private is the default.Proving retention
This is the capability that does not exist in a hosted memory product. Because every segment is a Cascade action, an object CID resolves to an action, and that action resolves to on-chain evidence. That gives a direct answer to a question a service agreement can only assert: this object was last proven retrievable at block X. The chain of evidence behind that statement is verifiable independently. LEP-5 availability commitments prove possession at finalization, and ongoing storage challenges test retention afterward. Both are described in Cascade.Portability
A manifest CID plus the log key is the whole memory. Anyone holding both can reconstruct the log from Cascade without the gateway, without the client library, and without Lumera’s cooperation. Verification runs offline against the manifest chain. This is what distinguishes portable memory from exportable memory. An export is a copy a vendor chooses to give you. A manifest root is the object itself.The client surface
Described as capabilities rather than signatures, because the API is not yet published.- Append an entry, returning its CID, sequence number, and state
- Read recent entries, or entries since a point in the log
- Fetch and decrypt a specific entry by CID
- Force a seal, producing segment receipts
- Query the durability state of any entry
- Request a retention proof for an entry
- Export the manifest root
- Verify a manifest offline, with no gateway involved
What this does not do
Stated as design scope, not fine print.- No semantic recall. Recency and lookup only. Retrieval by meaning is not provided, and applications that need it build it above this layer.
- No hot mutable state. This is the durable tier. Mutable, low-latency state is a separate tier in the Durable Memory architecture.
- No multi-writer logs. One writer per log. Shared memory across agents requires delegation and the hot tier.
- No sharing or access control lists. Sharing a log means handing over the manifest CID and the key, which works but is manual.
- No key escrow or recovery.
- No durability claim for
acceptedbeyond the stated staging behavior.
How it settles
Anchoring a segment is an ordinary Cascade action and is priced as one, using the existing base plus per-kilobyte fee. No new billing rail is introduced, and no separate subscription exists in the design. Pricing for the hosted gateway is not yet published.Cascade
The storage service Agent Memory anchors to.
Durable Memory
Where this sits in the Protocol architecture.