Memory OS of AI Agent: Audit Every Tier Transition

A memory OS for an AI agent is healthy only when the operator can follow one memory version through storage, updating, retrieval, and generation under the same user and assistant scope. A coherent answer is useful output, but it is not evidence that every earlier transition committed. The practical default is therefore simple: attach a content free lineage receipt to each boundary. Keep the memory content on the host. Record only stable identifiers, scope, source version, destination tier, timestamps, transition status, and the version used for generation. If a boundary is missing or contradictory, report waiting , at risk , stale , or uncertain instead of green. That rule matters for the specific architecture behind the search query memory os of ai agent . The MemoryOS paper defines three storage tiers and four functional modules. Its implementation also exposes a narrow failure window that an answer quality benchmark cannot identify. What MemoryOS establishes The MemoryOS paper describes four modules: 1. Storage organizes short term memory (STM), mid term memory (MTM), and long term personal memory (LPM). 2. Updating moves dialogue pages from STM to MTM, then derives longer lived profile or knowledge material from MTM. 3. Retrieval selects relevant material from the tiers. 4. Generation builds a response from current and retrieved context. The paper is unusually concrete about movement between tiers. STM to MTM updating uses a dialogue chain FIFO process. MTM to LPM updating uses segmented pages with heat based selection. That is enough structure to define observable transition boundaries instead of treating “memory” as one opaque database. The authors report average improvements of 49.11% in F1 and 46.18% in BLEU 1 over their baselines on LoCoMo with GPT 4o mini. Those are the authors’ benchmark results; I did not rerun LoCoMo for this audit. More importantly, response correctness and coherence answer a different question from operational integrity. A high score does not prove that: an STM record was durably present before eviction; an MTM destination committed before the source disappeared; the same user and assistant scope survived every transition; retrieval returned the newest expected version; the final generation actually depended on that version. The paper’s architecture supplies the boundaries. The operator still needs receipts for them. The risky interval appears before the destination commit I inspected the project at pinned commit 587ed7755c7aed179965792830ff1b5ad9a6fa92 . Pinning matters: the repository is active, and an operational conclusion without a source version will become ambiguous after the next change. The current add memory path checks whether the short term deque is full and runs promotion before appending another item. The source explicitly labels this as a fix to prevent silent deque auto eviction ( memoryos.py , lines 226–244). That is a useful safeguard, but it does not make promotion transactional. The promotion sequence matters: 1. process short term to mid term calls pop oldest while STM is full ( updater.py , lines 100–105). 2. pop oldest removes the record and immediately saves the shorter STM deque ( short term.py , lines 33–37). 3. The updater then calls LLM backed continuity and summary functions. 4. MTM insertion and its final save occur later ( updater.py , lines 130–207). This control flow creates a source at risk interval. If the process exits or an uncaught downstream operation fails after the STM save but before the MTM commit, the operator has no completed promotion proof. This is a source derived failure window, not a claim that every MemoryOS deployment loses data. The correct health state is simply non green until the destination receipt exists or the source is shown to remain recoverable. There is a second, narrower continuity boundary. last evicted page for continuity starts as an in memory None value, is carried into the next batch, and is updated after processing ( updater.py , lines 35 and 115–158). A process restart resets that particular carryover hint. Other MTM similarity logic may still reconnect material, so this is not proof of total continuity loss. It is a reason to record the previous page or source version in the transition receipt instead of assuming the process remembered it. Use one content free receipt across all tiers The receipt does not need prompts, responses, summaries, embeddings, or personal facts. A minimal event can look like this: Carry six fields through every stage: runId joins one storage to generation attempt without revealing content. userScope and assistantScope catch cross tenant or shared assistant mistakes. version identifies the expected memory state. sourceVersion pins the implementation or adapter contract. status separates started , waiting , committed , verified , and failed work. atUtc lets the verifier expire stale evidence. MemoryOS already creates user specific short , mid , and long term files and a separate assistant specific long term file ( memoryos.py , lines 71–78). The receipt should preserve both dimensions because “correct user, wrong shared assistant” is still a scope conflict. For generation, add dependsOnVersion and an outcomeReceipt . dependsOnVersion says which retrieved memory version entered the final prompt. outcomeReceipt should identify a deterministic result check where possible: a file hash, row identifier, test result, destination lookup, or other proof that the intended work exists. It must not be a hash of sensitive conversation content merely to make the record look rigorous. Replay inconvenient states before trusting green I built and executed a content free eight case fixture. The classifier returned all eight expected states: Case Evidence State Complete lineage Scope, version, freshness, tier commits, retrieval, and generation receipt agree healthy Capacity threshold not reached STM is durable and the declared wait window is open waiting STM removed, MTM not committed Source disappeared before destination proof source at risk STM retained, no promotion event Expected MTM transition never appeared promotion missing User changes during promotion One event belongs to a different scope scope conflict Retrieval returns v21 , expected v22 A real memory exists, but it is stale stale retrieval Fluent response, no dependency receipt Generation completed without verified lineage generation unverified No implementation version The evidence cannot be interpreted safely uncertain The important distinction is between waiting and missing . An STM record that remains durable while a documented capacity threshold has not been reached is not stuck. A removed source with no destination commit is not waiting; it is at risk. The timestamp and source presence fields make that difference inspectable. Use explicit precedence so a later success cannot hide an earlier conflict: This order is deliberately conservative. Scope conflict outranks a successful response. Source risk outranks later activity. A stale retrieval is not redeemed by fluent generation. Missing evidence stays uncertain rather than being converted to healthy. Turn the receipt into an operating gate Start with one canary memory that contains no personal or production content. Give it a random identifier and expected version, then exercise the real storage, promotion, retrieval, and generation path. Before adoption or after a memory system upgrade: 1. Pin the implementation. Record the package version or repository commit and the configuration that changes capacity, heat, similarity, or retrieval limits. 2. Prove scope isolation. Run two user scopes and, if applicable, two assistant scopes. Cross each query deliberately and require no wrong lane retrieval. 3. Force capacity transitions. Fill STM to the configured boundary. Verify that every source removal has a matching MTM commit. 4. Exercise the fallback. The updater has a general summary fallback when multi summary output is unavailable. Label that path degraded and verify retrieval separately instead of treating fallback completion as normal quality. 5. Restart between batches. Check continuity after process restart because in memory carryover is not durable evidence. 6. Expire receipts. A promotion that was healthy yesterday does not establish that the current process, index, or files are healthy now. 7. Verify the outcome. Retrieval success says a memory was returned. It does not say the agent used the correct version or completed the intended task. Do not automatically retry a source at risk promotion if the update may already have partially committed. First reconcile source and destination by runId and version. Blind replay can turn uncertainty into duplicated pages or conflicting long term facts. The limitation is equally important: this receipt proves transition lineage, scope, freshness, and deterministic outcome checks. It does not prove that an LLM authored summary is semantically correct. That requires a separate evaluation, a human review for high impact personal facts, or a task specific deterministic comparison. The health boundary for Sidewisp This audit fits Sidewisp’s memory and context health model: missing reads or writes, failed persistence, stale synchronization, unexpected resets, and lost decisions should be visible rather than inferred from a green process. Sidewisp is currently in private preview. Its public site and article system are live, while production agent health collection, runtime adapters, and recovery execution are not generally shipped. The receipt above is an operator pattern you can implement now; it is not a claim that Sidewisp currently monitors MemoryOS. The resolved rule is strict but usable: trust the memory system only when the same scoped version is durably stored, promoted, retrieved, used, and verified. A fluent answer can be encouraging. It cannot substitute for the missing receipt.