How do you design memory systems for long-running AI agents?

@Pimpcat-AU’s framing is the right one: the runtime owns memory, the model only gets a working view each turn, and the application — not the LLM — decides what becomes durable. I’d add one requirement that tends to get deferred until it’s painful. The moment you persist “full history, user preferences, decisions” outside the model, that store becomes a privacy and retention surface, not just a performance one. Two things worth designing in from the start: 1. Erasure — when a user asks to be forgotten, or policy requires it, can you delete that one subject’s memories and prove it? That gets hard once their data is spread across embeddings, caches, snapshots and logs; it’s much easier if each memory is keyed to a subject and individually destroyable (e.g. per-record keys you can drop) rather than living in an append-only blob. 2. Audit — the same authority layer that decides what becomes durable should also record who or what wrote or erased each memory, and when. For reference, this is the exact problem SAIHM (an open-source, Apache-2.0, AI-agent-agnostic memory layer) is built around — per-record erase-with-audit as a first-class operation rather than a bolt-on — so it may be a useful comparison point. @Suhebmultani, what’s the use case you’re building for? Retention looks very different for a personal assistant versus something holding other people’s data.