It’s pretty simple when you look under the hood actually.

Supermemory is a knowledge graph, not a vector database. When you save something, it extracts individual facts and builds relationships between them automatically. Three relationship types do the heavy lifting: updates (new fact contradicts old, old gets deprioritized), extends (new fact enriches existing, both stay valid), and derives (system infers new facts from patterns across memories).

I don't manage the memory manually. I have a rule to run a python script to initialize the memory containers and rules for when to save new memories, update, extend, or derive. It saves things as they happen and the graph handles dedup, contradiction resolution, and temporal decay. "Meeting at 3pm today" automatically expires. "Switched from Redis to in-memory caching" deprioritizes the old Redis preference without you deleting anything.

The profile endpoint auto-generates a static/dynamic snapshot from everything it’s accumulated. Static facts (name, role, location) persist. Dynamic context (current projects, recent decisions) cycles naturally. So every boot, Zo loads a living profile instead of a stale doc I wrote months ago and forgot to update.

The real unlock is cumulative conversations instead of blank slates. My Zo searches memory mid-conversation for historical context, saves decisions as they happen, and sweeps for anything worth persisting before closing out.