Deep Memory

Most multi-agent graph pipelines accumulate drift — one agent writes ‘Person’, another writes ‘person’, a third invents a ‘Human’ node type, and the graph becomes unqueryable. deep-memory addresses this by coupling a GraphRAG retrieval layer with a Vocabulary system: a governed, shared schema that defines allowed node types, relationship kinds, and properties. Agents query the vocabulary before writing, so every node lands on a predictable schema rather than whatever the model inferred from context.

The Vocabulary system is the differentiating mechanism. Instead of stuffing example documents into every prompt to teach agents what the graph looks like, you define the vocabulary once and reference it at write-time. The docs describe this as replacing document examples with a compact schema, which cuts token usage on every agent call that would otherwise need that context repeated.

The monorepo covers multiple persistence backends — Neo4j, SQL Server, Azure Cosmos DB, and an in-memory store — each with its own Docker Compose quickstart file and dedicated quickstart guide. This means you can prototype against the in-memory backend and promote to Neo4j or Cosmos DB without rewriting agent logic. The library is open-source under a disclosed license, self-hosted only, and carries no API surface or hosted cloud option.

Integration follows a library-embed pattern: you pull the package, configure a backend via environment variables (an .env.example is provided), and wire your agents to call deep-memory’s vocabulary and memory interfaces. An MCP config example is included in the repo, and a Claude Desktop quickstart exists for teams evaluating the library with that client. There is no GUI for browsing the graph or managing vocabulary entries — all administration happens in code or directly against the backing database.