Knowledge Graph Memory
Persist agent memory as entities and typed relations in a structured graph — so symbolic queries (path, neighbor, type) become possible alongside semantic search.
Intent & Description
🎯 Intent
Persist agent memory as entities and relations in a structured graph so symbolic queries (path, neighbor, type) become possible.
📋 Context
Some agent tasks involve questions about structured relationships, not semantic similarity — “who reports to whom in this org chart?”, “what code depends on this function?”, “which products are compatible with this one?” The answers are not “documents that look similar” — they’re “nodes connected by specific edge types in a graph.”
💡 Solution
Extract entities and relations from observations into a graph store (Neo4j, RDF, or simple JSON). Queries traverse the graph (Cypher/SPARQL or programmatic). Combine with vector memory for hybrid retrieval — vector finds entry points, graph traverses from there.
Real-world Use Case
- The agent must answer relational queries (path, neighbor, type) over remembered entities.
- Observations cleanly yield entities and relations worth persisting symbolically.
- Hybrid retrieval (vector entry point + graph traversal) is feasible and useful.
Source
📌 TL;DR
Store entities and typed relations in a graph — combine vector search for entry points and graph traversal for relational answers that embedding similarity alone can never provide.
Advantages
- Structured relational queries that vector search can’t answer become possible.
- Knowledge is inspectable, editable, and debuggable — not a black-box embedding.
Disadvantages
- Extraction quality bounds graph quality — bad entity extraction propagates everywhere.
- Schema rigidity vs flexibility is an ongoing tension; graphs need schema governance.