memory graph

The contrast that defines it is with the vector store. Structured memory graph workers puts both sides plainly: most agent memory today embeds facts, searches by cosine similarity, tunes a threshold and hopes the right thing comes back, which is how Mem0 and Zep work, and for many use cases that is the right call. Recallatron bets the other way, on an entity graph, episodic timelines, procedural notes and structured query, where the graph and timelines are the primary structure and retrieval works by exact lookup by name or graph traversal rather than vector similarity or a similarity threshold; any embeddings sit underneath as a derived, optional index, never the path exact lookup depends on. Ask it what it knows about a person and it returns the node, not the five nearest neighbours in vector space.

A memory graph is one memory layer, not a whole memory system. It is the shape you reach for when a layer has to answer what is true about the world. A layer answering what happened is better off as a log or a digest table.

Exact lookup, and the bill that comes with it

Exactness cuts both ways. If "Robin" and "Robin Goodwin" become two separate Person nodes, a query for one misses the other, and the memory is now wrong in a way you can measure. A vector store never forces that reckoning, because you never look at the duplicates directly; similarity degrades gracefully and covers for them. A structured graph has no such cover.

That is why entity resolution and dedup are standing maintenance, not optional cleanup. Recallatron runs four workers in a fixed order at 02:00 UTC: resolution, dedup, autoconfirm, profile. The graph is the destination structure. Those workers are the workflow that keeps it accurate over time.

How it is stored

Give the model the tools, not the context gives the record shape. Layer 3 is the entity graph, an append-only JSONL file holding entity records plus confirm and supersede patch records written into the same file, never rewritten in place. Each entity carries where it came from, a confidence score, a valid-from and valid-until, and an optional pointer to whatever superseded it. Relations live inside an entity's properties, sparsely. There's no separate edge table. You look entities up by name with a substring search, or by walking from one to its neighbours.

One process, one file explains the append-only part. ontology/graph.jsonl is never rewritten: supersede or confirm an entity and you append a patch line, and loadGraph folds every patch over the records at read time to compute current state. Because the file is never rewritten in place, a half-finished write cannot corrupt an existing record.