What is a context graph?
A context graph is a graph of an organisation's entities and relationships, assembled so a model can be given the connected evidence for a question. The term is vendor vocabulary rather than a standard, so here is what it usually means and where it overlaps with a knowledge graph.
A context graph is a graph of an organisation's entities — people, customers, deals, tickets, repositories, documents — and the relationships between them, assembled so that a model can be handed the connected evidence for a question rather than a set of passages that resemble it.
It is worth saying immediately that this is vendor vocabulary. No standards body owns the term, and the companies using it mean slightly different things by it: a knowledge graph sold to a buyer who cares about AI rather than analytics; a graph plus the retrieval layer that serves it; or, at the loosest, whatever a product assembles out of a customer's SaaS accounts. So the useful thing is not a definition to recite but a set of questions to ask of any particular one.
What the emphasis is
Three things usually distinguish a context graph from a graph built for other purposes.
The consumer is a model, not an analyst. A graph serving dashboards is shaped for joins and aggregates. A graph serving a prompt is shaped for reading: a short description of each entity that carries what ten separate facts would, because the scarce resource at the far end is attention and tokens rather than query time.
It is kept current from live systems. A graph built once from an export is a snapshot, and company context goes stale at the speed of the business — a renewal moves, an owner changes, somebody leaves. Continuous syncing is less a feature of the graph than the condition for it being worth consulting at all.
It is read on somebody's behalf. The same question asked by two people should be able to return different evidence, because they are allowed to see different things. A graph that cannot do that is an export of everything the company knows, which is a liability rather than a product.
Many implementations add a fourth: time. Recording when each fact was believed, and keeping the superseded version rather than overwriting it, is what makes what did we think in July answerable.
It is not a vector index
A vector index answers what resembles this question. A graph answers what is this, and what is attached to it. Both are retrieval, and they are good at different questions; most working systems run both, with similarity finding the entry points and the graph deciding what is connected to them. The knowledge graph versus RAG argument goes through where each one wins.
Where it overlaps with the neighbouring terms
Candidly: substantially, and anybody drawing a hard boundary is selling something.
A knowledge graph is the structure — entities, relations, dated facts. GraphRAG is the retrieval method that walks one to answer a question. "Context graph" is mostly a statement about purpose: the same structure, built and maintained specifically to supply a model's context, with the three emphases above. You can build all three and own one system.
Where the term does earn its keep is in putting the stress on context — what is assembled for a particular question, at a particular moment, on behalf of a particular person — rather than on the store, which is the part teams tend to over-think.
Where this stops
A context graph is only as good as its identity layer. Entity resolution decides whether the mailbox address, the ticket name and the CRM contact are one node or three, and when it is wrong in the merging direction, every figure downstream is confidently wrong in a way that passes inspection. A graph does not make that problem easier; it makes it load-bearing.
The schema is a commitment too. Deciding what counts as an entity and which relations matter is a modelling decision you live with, and it is awkward to revise once a year of facts hangs off it.
And it does nothing for document-shaped questions. If what you need is the paragraph in the policy, a graph is overhead: you wanted search.
So when the phrase turns up on a slide, the questions worth asking are what the nodes are, where they came from, how often they are refreshed, whether a fact can be traced to the record that asserted it, and who is allowed to read each one.
Where Memtro fits
Memtro's memory is a knowledge graph with a semantic index beside it, filled from connected systems rather than by hand: connector results are anchored to entities deterministically on external ids and email, each fact keeps its source and both of its clocks, writes are scoped personal, team or shared, and a nightly pass gives each busy entity a short card describing what it is from the facts actually held. The memory documentation sets it out in full.