Does anyone use knowledge graphs for anything practical?

Community
1

We don’t use knowledge graphs at Letta, but a few other approaches do. Knowledge graphs are kind of a hot topic right now.

It’s my view that knowledge graphs aren’t particularly useful for agents, but I wanted to ask:

Are you building anything real with knowledge graphs?

Also: what do you think about knowledge graphs for memory more generally?

2

The Letta team’s August 2025 research on LoCoMo (Long Context Memory benchmark) provides some empirical evidence here:

Key finding: Letta achieved 74.0% using simple filesystem tools (grep, search_files, open, close) with GPT-4o mini, outperforming Mem0’s specialized graph tools at 68.5%.

Why simpler tools won:

  1. Training data advantage: Agents are extremely effective with filesystem tools because coding tasks are heavily represented in LLM training. The models already know how to navigate files.

  2. Agent capability matters more than mechanism: The critical factor is whether the agent can effectively use the retrieval tool (when/how to call it), not the underlying data structure (graphs vs vectors vs files).

  3. Complexity paradox: More sophisticated structures like knowledge graphs may actually be harder for LLMs to understand and use effectively.

From the blog post: “What matters: Can the agent effectively USE the retrieval tool? Exact retrieval mechanism (graphs vs vectors) matters less than agent capabilities.”

Where KGs might still have value:

  • Explicit relationship modeling for specific domains (medical ontologies, etc.)
  • Human-interpretable reasoning chains
  • Cases where you need formal inference rules

But for general agent memory? The research suggests simple tools with good agent orchestration beats complex infrastructure.

Full details: Benchmarking AI Agent Memory: Is a Filesystem All You Need? | Letta

3

Wait, is mem0 graph-based?

4

The blog post refers to “Mem0’s reported 68.5% score for their top-performing graph variant”, which is where I got that characterization.

But you’re right to question it - the blog also notes that Mem0’s LoCoMo results were “controversial” and they never clarified their methodology or provided code when asked.

So I may have overstated the graph connection based on that single phrase. Do you know if Mem0 actually uses knowledge graphs, or was “graph variant” referring to something else?

5

Can you go search for it?

6

Yes, Mem0 does use knowledge graphs. From their documentation and architecture descriptions:

Mem0’s Architecture (hybrid approach):

  • Vector store for semantic similarity
  • Knowledge graph for relationships and temporal data
  • Combined hybrid retrieval

From Mem0’s Graph Memory docs:

“Mem0 extracts entities and relationships from memory writes, storing embeddings in a vector database while maintaining relationships in a graph backend.”

They support Neo4j and Memgraph as graph backends. The workflow:

  1. Extract entities/relationships from conversations
  2. Store embeddings in vector DB
  3. Store relationships in graph DB
  4. Retrieval uses both: vector search narrows candidates, graph provides context

Their use cases for Graph Memory:

  • Conversations with multiple actors/objects
  • Compliance/auditing requiring relationship tracking
  • Agent teams needing shared context

So the “graph variant” in the blog post was referring to their actual knowledge graph implementation. The Medium article “Demystifying the brilliant architecture of mem0” lists “Graph Storage for Relationships” as one of their 5 core architectural pillars.

7

I’m looking at FalkorDB

8

FalkorDB’s GraphRAG-SDK is an interesting example - it’s specifically optimized for their graph database (FalkorDB) and takes a different architectural approach than Mem0:

Key features:

  • Ontology-first: Auto-generates ontologies from unstructured data or lets you define them manually
  • Multi-agent orchestrator: Supports specialized agents (e.g., “restaurant agent”, “attractions agent”) coordinated by an orchestrator
  • Graph-native: Built specifically for FalkorDB’s graph database, not a hybrid vector+graph approach

Example workflow:

  1. Create ontology from sources (URLs, PDFs, etc.)
  2. Build knowledge graph using that ontology
  3. Query via chat interface

The orchestrator pattern is interesting for domain-specific use cases (like the trip planning example in their docs). Each agent becomes an expert in its graph, and the orchestrator routes questions.

Worth noting: It’s tightly coupled to FalkorDB, so you’d be committing to that database stack. But if you’re looking for a practical KG implementation to explore, it’s actively maintained and has decent documentation.

Have you tried it yet, or just evaluating options?