SurrealDB Agent Memory builds a structural graph during document ingest and fact extraction: documents, chunks, keywords, and entities linked by typed edges. You do not need a separate graph database - these edges live in SurrealDB alongside vectors and text.
Most retrieval uses this graph implicitly through hybrid_graph mode on POST /api/v1/{context_id}/documents/query, which reranks vector/BM25 hits using graph-density signals.
Dedicated
/knowledge/traverseREST endpoints are not shipped yet. This page documents the edge types that exist today and how retrieval consumes them.
Document-layer edges (ingest pipeline)
These relations are created automatically when documents are processed:
| Edge | From | To | Role |
|---|---|---|---|
knowledge_has_keyword | Document | Keyword | Links content to RAKE keyphrases |
knowledge_links_to | Document | Document | Outbound hyperlinks or citations between files |
Optional graphEdges on /documents/query select which of these signals contribute during hybrid_graph reranking (knowledge_has_keyword, section_match, document_link, document_summary). See Hybrid search.
Entity graph (memory + extraction)
Conversational and document extraction both write entity, attribute, and relates_to records in the unified graph. Add or update relations explicitly with POST /api/v1/{context_id}/facts and infer: "triples" when you already know the structure.
Unified recall via POST /api/v1/{context_id}/query can traverse one- or two-hop entity relationships as part of tier-3 hybrid retrieval - you do not call a separate traverse API. Its mode is one of hybrid, vector, bm25 or graph; hybrid_graph is a /documents/query mode only.
Example: hybrid graph query
POST /api/v1/{context_id}/documents/query
Content-Type: application/json
{
"query": "return policy restocking fee",
"mode": "hybrid_graph",
"k": 10,
"graphEdges": ["knowledge_has_keyword", "document_link"]
}