What is knowledge graph memory?
Knowledge graph memory stores what an AI knows as entities, relations and dated facts rather than only text chunks and vectors. What that makes possible, entity resolution, bitemporal facts, and how it combines with vector retrieval.
Knowledge graph memory is a way of storing what an AI system knows as things and the relations between them, with facts attached to the things, rather than as a pile of text passages indexed by meaning. A person is a node. The company they work for is a node. "Works at" is an edge between them. "Owns the billing migration, since March" is a fact attached to the person, with a date and a source.
The alternative most systems start with is a vector index: cut documents into chunks, embed each chunk, and at question time fetch the chunks whose embeddings sit nearest the question's. It works well for "find me the passage about X". It cannot, on its own, know that the Priya in the CRM, the priya.k in GitHub and the P. Kumar on an invoice are one person, or that the thing you asked about has twelve other facts attached to it in four systems. A graph can.
What a graph holds
Entities: people, companies, tickets, deals, repositories, documents, each with a canonical name, aliases and the identifiers other systems know it by.
Relations: works at, owns, reported, belongs to, promised, decided in. Relations are what make a question about one thing reach the things around it.
Facts attached to entities: statements with a type, a confidence, a source and, crucially, time.
Provenance on everything: which tool, which record, which URL, when. An answer assembled from the graph can show its working.
Time, twice
The facts in a company change, and a memory that overwrites loses the record of having believed something else. A bitemporal graph keeps two clocks on every fact: when it was true in the world (valid time) and when the memory believed it (record time). A renewal that moved from July to September in a June email is two facts: July, believed until June; September, valid from June. That makes "what did we believe in July?" answerable, and it makes corrections safe, because a newer fact supersedes an older one instead of fighting it at retrieval time.
Entity resolution
The hardest part of building a graph from real systems is deciding when two records are the same thing. The same person arrives as an email address, a login, a full name and a profile, and the graph is only useful if they become one node. The risk runs the other way too: records that resemble each other and are not the same, invoice 0185 and invoice 0182, Sam Clark and Nick Clark, and a merge cannot be undone. Deterministic matching on identifiers, cautious matching on names, and a nightly pass that rationalises what has accumulated is the usual answer.
Graph and vectors together
The two are not rivals. A semantic index finds the facts and passages that resemble the question; the graph then widens the result to the entities the question mentions and the facts attached to them, one hop out. The knowledge graph vs RAG post goes through where each one wins. The short version: vectors answer "what is this like?", graphs answer "what is this, and what is connected to it?", and a company's questions are mostly the second kind.
Where Memtro fits
Memtro's memory is a knowledge graph with a semantic index beside it. Connector results are anchored into entities deterministically, without a model call; facts carry type, confidence, provenance and both clocks; corrections supersede; near-duplicates are consolidated nightly; and any request can read the graph as of a date. The memory documentation describes it in full.