# 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.

- **Category**: Agentic AI
- **Subcategory**: Memory
- **Canonical URL**: https://designpattern.fyi/patterns/knowledge_graph_memory/

---

## 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.



## Use Cases
- 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.






## Trade-offs


### Advantages

- Structured relational queries that vector search can't answer become possible.

- Knowledge is inspectable, editable, and debuggable — not a black-box embedding.




### Considerations & Drawbacks

- Extraction quality bounds graph quality — bad entity extraction propagates everywhere.

- Schema rigidity vs flexibility is an ongoing tension; graphs need schema governance.







---
**Reference**: [Original Source](https://www.agentpatternscatalog.org/patterns/knowledge-graph-memory/)