Knowledge-Graph Memory
Memories stored as entities and typed relations rather than documents: recall traverses structure (who owns what, what depends on what) instead of matching text.
When to use
Question shapes flat stores cannot answer: relationships, dependencies, and multi-hop connections across memories.
Specification
| Memory type | semantic |
|---|---|
| Storage | graph database or graph layer over extracted entities |
| Retrieval | graph traversal and structured query, often combined with embeddings |
| Update method | pipeline-extracted from content; human or agent curation of the schema |
| Decay / staleness handling | Edges can carry validity intervals (see zep's temporal model), which is the strongest freshness story in any memory architecture when actually implemented. |
| Risk level / maturity | medium / emerging |
Privacy and safety
Graphs make inference easy by design; linked innocuous facts can compose into sensitive ones. Access control must consider paths, not just nodes.
Failure modes
- Extraction errors become structural errors
- Schema rigidity fighting a changing domain
- Build cost dwarfing the query shapes actually used
Assessment
The high-ceiling architecture: qualitatively better recall when extraction lands, structural errors when it misses. Adopt for the question shapes, not the aesthetics; most projects' questions are flatter than they think.
Evaluation method: Multi-hop question accuracy against a labeled set; extraction precision audit.