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

Crab-D is an eager personal assistant: ready to help write code, manage email and organize a life. But in Stephen Chin’s opening example, a new day brings a new OpenClaw memory file, and the assistant no longer recalls yesterday’s work. The user has to supply the continuity that the assistant was supposed to provide.

The problem extends beyond remembering facts. Crab-D has tools but reaches for the wrong utensils to eat a bowl of soup. It encounters someone familiar and treats them as a stranger. These cartoons describe recognizable agent failures: having access to a capability without selecting it correctly, and storing experience without bringing it back when needed. The result is repeated instruction for tasks the assistant has already encountered.

An agent’s working loop is familiar: receive a prompt, consider a response, call tools and observe the results. Memory determines what information enters that loop. What should the agent recall, and how does that material get into context?

Chin illustrates the file-based approach with SOUL.md, tool files and daily memory files. Markdown makes this material easy for people to inspect, edit and compact. Files are kept small because the context window is limited, and relevant information must be positioned where the model can use it. In current OpenClaw documentation, SOUL.md primarily supplies personality guidance, while daily notes and MEMORY.md provide persistent memory. The opening amnesia example is Chin’s experience of failed recall, not a claim that OpenClaw necessarily deletes yesterday’s notes.

Chin reports that his agents load at least 100K tokens per round, including skills and other context. Much of that loading repeats material in the hope that some of it will prove useful. With a small knowledge base and a capable model, the approach can produce satisfactory answers. As the knowledge base grows, however, repeatedly loading the stack becomes a poor way to select evidence. Chin introduces his home-lab digital twin as a concrete test of that limitation.

Hermes Agent adds a useful feedback step: after completing a task, it reflects and records skills or knowledge it needs. That gives future tasks something to learn from. But those skills are still represented as Markdown, and their usefulness depends on loading the appropriate material at the appropriate moment.

Crab-D’s next mishaps separate three problems that a growing skill library must solve:

• Missing capability: without a clam-opening skill, the crab cannot reach its meal.
• Wrong selection: riding a jet ski on a beach applies an available capability in the wrong setting.
• Incomplete sequence: opening the clam is insufficient if the crab does not know how to eat it afterward.

The requirement is therefore a chain of suitable skills, not merely a collection of them. Chin points to an unnamed arXiv project by a Neo4j colleague that represents skills as a graph—a way to make their connections explicit.

Goose approaches automation through MCP. It belongs to the Agentic AI Foundation, alongside MCP; Chin describes Anthropic’s backing and Neo4j’s membership as part of that ecosystem. Intended for enterprise workflows as well as personal assistance, Goose makes integrations central to its design. Chin cites more than 70 MCP extensions for Goose at the time of the talk.

In the memory implementation Chin describes, memory is another MCP server. An agent can retrieve, remember or forget information through explicit operations over files on disk. That is a useful separation of interface from application: memory becomes something an agent can manipulate through tools. But a pluggable interface does not, by itself, change how the stored information is organized or how the relevant pieces are found.

The wrong tool occasionally produces something useful. Chin’s paddle example turns into the origin story of pickleball: a family combines equipment already at home, a badminton court and improvised rules to make a new game. For an assistant carrying operational knowledge, though, improvisation is not enough. Too many notes can encumber recall, and exposing a forget operation introduces the possibility that the agent removes memory it still needs. Better access to memory must be accompanied by better selection and control.

A vector database improves on loading every file. Store embeddings for the material, embed a query and retrieve similar content from a much larger repository. This makes memory selective: the model receives related information without having to reread everything. Chin names pgvector and LanceDB as options and says he will use both in the demonstration. His description of pgvector as built into OpenClaw differs from the current memory configuration reference, which describes SQLite indexing with sqlite-vec acceleration; the talk does not establish the historical configuration behind that difference.

Similarity in vector space is not the same as an actual relationship. A retrieved passage can concern the right kind of server without describing the particular server in question. Chin associates reliance on vector lookup alone with hallucinations and increasingly difficult failures in complex digital twins. Crab-D’s expensive mistaken lunch is the visual joke: something can look like the desired object without being an appropriate substitute.

The deeper difficulty is a multi-hop question. All the necessary facts may be stored, yet similarity retrieval may not assemble the chain that connects them. Chin also describes such chains as expensive in traditional relational databases. His final vector analogy makes the identity problem explicit: a shell can resemble yours and still belong to someone else. Retrieval needs to preserve which entity a fact belongs to, as well as which other entities it connects to.

A property graph represents entities as nodes, their connections as relationships, and descriptive information as properties. Identity and paths become explicit parts of the stored model. Embeddings can live alongside that structure, so introducing graph memory does not require abandoning vector search.

The hybrid retrieval procedure in CrabRAG has three stages:

1. Find seeds: use vector search to locate promising starting nodes.
2. Expand relationships: traverse from those seeds to connected neighbors.
3. Rank context: select relevant material from the expanded neighborhood for the model’s answer.

Vector search supplies an entry point; traversal supplies the connected evidence needed for a more specific question. Chin’s ocean journey illustrates the difference: recognizing something related to a desirable reef is less useful than finding the path that reaches it.

The returned subgraph also makes retrieval inspectable. A developer can examine the entities and relationships that entered context and trace an answer back to that evidence. If the answer is wrong, the graph offers concrete places to investigate: extraction may have missed a relationship, or duplicate nodes may have split facts about the same entity. Improving extraction and merging duplicates changes the evidence available to the next retrieval. The graph is both a memory structure and a debugging surface.

Chin recommends Claude as an aid for writing Cypher and building entity extractors. That lowers the barrier to implementing the queries, but it leaves an essential design responsibility with the developer: knowing the entities, relationships and properties the application needs to represent.

The intended workflow is to write an agent’s actions into the graph as it works, answer follow-up questions by traversal rather than rereading, and recover useful context in a fresh session. To explore that approach, Chin built a digital twin of his home lab over the preceding week or two. The comparison starts with the same original Markdown files: environment A uses a vector store, while environment B uses graph memory built with Cognee.

The graph environment uses a Neo4j backend. The underlying lab consists of Proxmox servers running on computers around Chin’s desk. For the demonstration, a separate VLAN isolates the agents from the real network represented in their memory. They cannot inspect live hosts or obtain updated network information. Their answers must come from what was previously stored. That isolation makes retrieval, rather than live discovery, the central task.

The CrabRAG cockpit presents five queued questions with home-lab schematics; Chin demonstrates two of them. These are concrete comparisons of displayed answers from the two environments. Model settings, retrieval budgets and policy configurations are not specified, so the results show what happened in this setup rather than establishing a controlled accuracy or cost benchmark.

The first question asks whether any software exposed to the WAN—the public internet—is past end of life. Chin identifies a concrete target: his daughter’s Minecraft server is running Debian Jessie. The useful answer must connect a particular guest, its operating system and its exposure to the internet. A general warning about old software would not identify what needs attention.

The vector response does not provide those specifics. It mentions details excluded by policy and asks for information to be sourced separately. On the graph side, the cockpit shows Cypher queries and a visualization of the retrieval process:

• Blue nodes: seeds selected through vector lookup and ranking.
• Gray nodes: neighbors reached through one-hop traversal.
• Green nodes: selected nodes that enter the final context.

The colors expose the boundary between finding a plausible starting point and retrieving the connected facts used in the answer.

Chin reports that the graph answer identifies the guest he expected and flags its obsolete operating system. He emphasizes that both stores started from the same source data: the practical difference is whether the agent can retrieve the connected information needed to produce an actionable finding.

The second question concerns management ports listening on 0.0.0.0 and whether they are exposed to the internet. Listening on all IPv4 interfaces is only part of that question: reachability also depends on the network around the service. Chin’s setup names Matrix and HAProxy as internet-exposed, while the Cognee demo and OpenClaw instance remain accessible only inside the LAN. The answer therefore needs to distinguish a listening address from an actual path from the WAN.

The vector response recommends checking service configuration and a pfSense rule, effectively returning the investigation to the user. Chin reports that the graph response instead identifies HAProxy and OpenVPN as WAN-exposed. Those names differ from the setup’s Matrix and HAProxy, so the narration does not establish an exact match between the expected and returned service lists.

The traversal explains how the graph approaches the question. It finds the pfSense router node and follows its relationships to the relevant results. The graph’s shape differs from the obsolete-software example because this query has a useful shared connection point: the router.

A compact Cypher model makes that operation concrete. Suppose a Router connects through FORWARDS_TO relationships to Service nodes, and the relationship records the source network. With those illustrative labels and properties, the router-centered lookup is:

MATCH path = (router:Router {name: 'pfSense'})
             -[forward:FORWARDS_TO]->(service:Service)
WHERE forward.sourceNetwork = 'WAN'
RETURN service.name AS service,
       service.port AS port,
       path;

Returning path preserves the connection behind each result. The important modeling choice is to represent exposure as a relationship the query can follow, rather than infer it from text that merely mentions a router and a service.

Crab-D’s clam metaphor returns with the sequence complete: open the shell, eat and proceed to the next task. In the home lab, the corresponding benefit is a specific security finding that someone can act on. Chin says he subsequently patched the holes uncovered through the demonstration. The displayed agent work identifies problems; the later remediation is Chin’s reported follow-through.

Chin contrasts his three- or four-node home lab with enterprise data centers and financial-services collections of companies and customer records. He invokes million-token context windows as an example of large but finite capacity, not a limit shared by every model. Once an application’s relevant knowledge exceeds the context it can practically load, the engineering problem becomes selecting connected evidence from persistent memory. A larger window cannot supply relationships that retrieval never found. Crab-D’s closing reunion with its crustacean crew brings that requirement back to the opening problem: remembering means recovering the right identities and connections when they matter.

Chin closes with GraphRAG: The Definitive Guide, coauthored with Michael Hunger and Jesús Barrasa. At the time of the talk, he describes the full book as available in early release, with publication expected after the remaining editorial work. Its scope extends from GraphRAG to memory, agents, industry use cases and the technologies needed to build an application end to end.

For practical training, he points to Neo4j GraphAcademy’s free courses on agent memory and context graphs. These continue where the demonstration leaves off: learning to build the persistent, queryable structures that let an assistant recover a useful chain of evidence in a later session.