Memory and State Management
Semantic Memory — Stack
Semantic memory › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing how standing claims are represented, validated, replaced, and looked up by subject.
- Subject addressability. Whether "everything currently asserted about this entity" is a key lookup or a similarity search. Only the first is reliable enough to hedge or correct with.
- Replacement semantics. Whether the representation makes superseding a claim a defined operation or a best-effort attempt to find and remove the old one.
- Validation at write. Whether the shape can reject a malformed or out-of-vocabulary claim before it is stored, rather than discovering it at retrieval.
- Entity resolution. Whether the mechanism can tell that two differently-worded subjects are the same entity, since without it the store holds parallel belief sets for one person.
- Contradiction visibility. Whether two incompatible claims about one subject can be detected by the store, or only by whoever reads them.
- Scope enforcement in the lookup. Whether the ownership key is a constraint on the query rather than a filter applied to what comes back.
- Cost of schema change. How much work it is to add a predicate once the store has millions of items, because the vocabulary will grow.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Typed columns on a profile row (PostgreSQL, MySQL) | Small, stable, well-understood belief vocabularies such as preferences and contact details | Every new predicate is a migration; anything outside the schema has nowhere to go and is silently dropped |
| Subject-predicate-value triples in a relational table | Open vocabularies that still need mechanical replacement and exact subject lookup | Querying becomes self-joins; without a controlled predicate vocabulary the same idea is stored three ways |
| Graph store with typed edges (Neo4j, FalkorDB, Memgraph, RDF stores with SPARQL) | Beliefs whose value is relational — who reports to whom, which account owns which project | Operating a graph under automated writes is a specialist skill; consistency repair is manual |
| Free-text notes with embeddings (pgvector, Qdrant, Weaviate, Pinecone) | Capturing anything a user says without designing a vocabulary first | Replacement and contradiction detection are both similarity guesses; the store will hold paraphrases of the same claim |
| Hybrid: typed slots for a known core, free text for the rest | Most production systems, once the core vocabulary has been observed rather than guessed | Two retrieval paths to keep consistent, and a standing argument about which side a new predicate belongs on |
| Managed memory service with built-in fact extraction (Zep, Mem0, Letta, platform memory APIs) | Shipping belief extraction and supersession without building either | The extraction prompt, the confidence model, and the supersession rule are the vendor's and change under you |
| Rules or ontology layer over the store (SHACL, JSON Schema validation, a hand-written validator) | Domains where a wrong belief is expensive and the vocabulary is worth constraining | Constraints reject real-world messiness; an over-tight ontology pushes writers to store things in the wrong field |