Knowledge graph memory for connected context.
Graph memory helps an agent retrieve not only text that sounds similar, but also the records connected to that text: entities, owners, citations, policies, events, and decisions.
What this guide covers
The practical decision points.
Graph memory adds relationships
The answer often depends on what a record is connected to, not only what text is nearest in embedding space.
Ontology keeps it queryable
A live schema tells agents and applications which labels, fields, values, and relationship paths actually exist.
RushDB stores graph and search together
Records, relationships, typed properties, and semantic retrieval stay in one backend.
Architecture sketch
Connected retrieval shape
A knowledge graph memory keeps source text attached to the domain records around it. Retrieval can start with semantic search, then continue through the graph to sources, owners, citations, and decisions.
Implementation example
Store a document graph and retrieve connected context
This example writes a document with nested chunks and entities, indexes chunk text, then retrieves semantically relevant chunks inside one workspace. The graph remains available for follow-up traversal or UI drill-downs.
Graph memory vs flat retrieval
Flat semantic retrieval ranks text by meaning. That is useful, but it can miss the connected domain objects that make an answer useful or auditable. Graph memory keeps the text attached to the surrounding structure.
A policy chunk can stay connected to the policy, account, product, and approval workflow.
A research note can stay connected to authors, trials, citations, cohorts, and hypotheses.
A support incident can stay connected to services, deploys, owners, events, and decisions.
Where ontology matters
Agents should not guess field names or relationship paths from stale prompt text. RushDB can expose a live ontology so an agent sees the available labels, properties, values, ranges, relationships, and vector-index status before it queries.
When to use knowledge graph memory
Use graph memory when answers need provenance, permissions, hierarchy, or multi-hop context. If the workflow only needs one-off text similarity, a flat vector index may be enough. If the workflow needs structured recall, filters, and relationships, graph memory becomes the safer default.
Decision table
Flat RAG vs graph memory
Nearest-neighbor retrieval is useful, but many product answers require structured context around the matched text. Graph memory keeps that structure queryable instead of reconstructing it after retrieval.
Mostly chunks or documents ranked by embedding similarity.
Chunks plus connected Records such as sources, entities, owners, citations, accounts, and decisions.
Usually depends on metadata copied into the vector store.
Uses typed properties on Records and can inspect available values through ontology or property APIs.
Often stored as metadata on the chunk and rejoined in application code.
Citations, source documents, and domain objects can be first-class connected Records.
Simple document Q&A where the nearest chunk is usually enough.
GraphRAG, research, support, legal, analytics, or agent workflows that need connected evidence.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.