CrabRAG: Why Automated Assistants Need Graph Memory, Not More Tokens

Stephen Chin, Neo4j20:42 · Jul 2026 · 20K views
Thumbnail for CrabRAG: Why Automated Assistants Need Graph Memory, Not More Tokens Watch on YouTube
TL;DR
  1. 1

    Markdown memory makes agents reload large amounts of information because they do not know which files will matter.

  2. 2

    Vector similarity can retrieve related facts, but it cannot reliably follow the relationships needed for multi-hop questions.

  3. 3

    Graph memory combines vector search with graph traversal to produce precise answers that developers can inspect and audit.

Summary

Stephen Chin argues that agent memory needs explicit relationships, especially when an assistant works with a large and connected body of information. He shows how OpenClaw, Goose, and similar systems rely heavily on markdown files, which can make an agent load at least 100,000 tokens per round. Vector databases improve retrieval, but similarity is not the same as a relationship, so they struggle with multi-hop questions. Chin presents a home-lab digital twin built from the same source data in two ways: one environment uses a vector store, and the other uses a graph store. The graph system starts with vector search, then traverses connected nodes and ranks the results. In the demo, it finds an internet-exposed Minecraft server running Debian 8 Jessie and identifies management ports exposed through HAProxy and OpenVPN. Chin also explains that developers can use Claude to write Cypher and points viewers to the GraphRAG book and Neo4j GraphAcademy.

Key ideas
02:25

Markdown memory makes agents reload too much context

Chin says most agent memory systems contain a collection of markdown files, including memory files, tool files, and daily files. Markdown is easy for people to read and compact, but the agent often loads everything in case something becomes useful. His average agents load at least 100,000 tokens for each round because they repeatedly add skills and other information to the context. This approach works at small scale with a strong model, but Chin says it does not work at large scale.

04:43

Skills have the same retrieval problem as memory

Chin describes skills as markdown files that teach an agent how to perform tasks. The agent must load the right skill, and sometimes the right chain of skills, before it can complete the job. If the relevant skill is not retrieved, the assistant may choose the wrong action or stop before finishing. He mentions a project from a Neo4j colleague that models skills as a graph, which can help determine which skills belong together and which sequence an agent should use.

05:49

Goose exposes memory through MCP without changing its storage model

Goose, a project in the Agentic AI Foundation, treats memory as another MCP server. Its commands can retrieve, save, or forget memories, and its memory is stored as plain files on disk. Chin sees the MCP interface as useful because memory becomes pluggable and manipulable, but the underlying issue remains. The agent still has markdown files, too many notes, and a forget command that could wipe its own memory.

07:44

Vector similarity does not encode real relationships

Vector databases let an agent store embeddings and retrieve information that is similar to a query. Chin notes that OpenClaw includes PGVector, and he also uses LanceDB in his demo. The problem is that similarity in vector space is not the same as an actual relationship between entities. This can return facts that are related in some way but are not the facts needed for the question. Chin says large multi-hop reasoning chains can become impossible to answer accurately with similarity search alone.

09:54

Graph memory follows connected paths after vector search finds a starting point

In Chin's architecture, vector search finds seed nodes, then graph search traverses nearby nodes and ranks them by their relationships. A graph stores entities as nodes, relationships as edges, and additional information as properties. Embeddings can also be stored in the graph. This combination lets the system answer complex, domain-specific questions by following the connections between facts instead of repeatedly retrieving isolated similar passages.

10:48

Graph results are easier to inspect and audit

Chin says graph-based answers are precise because the system can follow the relevant paths. They are explainable because developers can inspect the returned graph, and auditable because the system can show which part of the graph produced the answer. If the answer is wrong, a developer can inspect the extraction process, reduce duplicate nodes, and change the graph construction. Chin says this makes it easier to understand where an answer came from and converge on a better result.

11:31

Claude can write the Cypher needed to get started

Chin says a developer does not need to be a graph expert to begin. Claude can write Cypher, build entity extractors, and handle much of the setup once the developer understands the model of the system they want to build. In his demo, Claude writes each action into the graph as the agent works. A later session traverses the stored graph rather than rereading the full history, then returns the result.

12:04

The graph agent found network risks that the vector agent could not identify

Chin builds two environments from the same markdown files about his home lab. One stores the information in a vector database, and the other stores it in a graph backed by Neo4j through Cognee. For a question about internet-exposed end-of-life software, the vector agent says it cannot find specific details. The graph agent follows the relevant nodes and identifies Tinksterlin, his daughter's Minecraft server, running Debian 8 Jessie. For exposed management ports, the graph agent finds HAProxy and OpenVPN exposed to the WAN, while the vector agent tells him to inspect the configuration himself. Chin patched the security holes after the demo.

16:49

Large connected environments need more than markdown files

Chin says a small home lab already shows the difference between isolated retrieval and relationship-aware memory. The same problem becomes harder in a large data center or in financial services systems with many companies and customer records. When the information does not fit into the context window of current models, loading markdown files becomes a poor memory strategy. He recommends graph-based memory for cases where the assistant must follow long chains of connected facts.

"And graphs are they're accurate. So, they give you very precise information. Explainable because you can look at the graph which got returned. And auditable because now you can actually say these are the this is the context."10:48
Who should watch
  • You are building an agent that repeatedly loads markdown files, skills, or conversation history and is running into context or token costs.
  • Your assistant needs to answer questions that involve several connected entities, such as hosts, services, users, permissions, or dependencies.
  • You want retrieval results that show their supporting path through the data and can be checked when an answer is wrong.