Skip to content

Knowledge Graph

Every memory is a node in the knowledge graph:

FieldDescription
idUnique identifier (UUID)
contentThe knowledge, as natural language text
layerSemantic layer: "domain", "concept", "fact", "episode", or "summary"
importanceHow important this memory is (0.0 to 1.0)
sourceOrigin identifier (e.g., "conversation", "import")
namespaceIsolation namespace for the memory
parent-idLink to the parent memory in the hierarchy

Memories are connected by typed edges:

FieldDescription
source-idOrigin memory
target-idTarget memory
typeRelationship kind (e.g., "related-to", "elaborates", "contradicts")
descriptionHuman-readable description of the connection

Relationship types are not prescribed — the LLM infers appropriate types during retain. Common types include related-to, elaborates, contradicts, supports, and refines.

The parent-id field creates a tree mirroring the semantic layers:

Domain
└── Concept
└── Fact
└── Episode

Orphaned memories (no parent-id) are candidates for organization by reflect.

Semantic search finds entry points. Graph traversal discovers related memories that wouldn’t match the query directly:

  • Parent: A broader concept providing context
  • Siblings: Related facts under the same parent
  • Relationships: Explicitly linked memories
  • Children: More specific details

A query for “technical skills” might match “experienced with Clojure”. Graph traversal then discovers the parent concept “Backend Engineering”, siblings like “has used PostgreSQL”, and children like “built the memlayer API at work”.

Use expand-graph: true on recall to include graph context:

Terminal window
curl -X POST http://localhost:8080/api/v1/recall \
-H "Content-Type: application/json" \
-d '{"query": "technical skills", "expand-graph": true}'

Each agent has a completely isolated namespace — its own knowledge graph, relationships, and hierarchy. One agent’s operations have no effect on another’s data.