The three layers everyone collapses into one
Same graph. Same question. Two very different artifacts. Most enterprise AI programmes build the first one, ship it, and then wonder why the agent is confidently vague.
The confusion is understandable, because both things are "a graph" and both contain "your company's knowledge." But they answer different questions, live on different timescales, and fail in opposite directions. Pulling them apart is the whole trick.
Epic —blocked_by→ Issue),
and the constraints that hold. Governed by humans. Changes rarely. It is the grammar;
without it, traversal has no rules to follow.
Put differently: the knowledge graph tells you what is permanently true. The context graph tells you what is true for this decision, in this moment — which is the only thing the model is actually going to reason over.
Side by side
| Dimension | Knowledge graph | Context graph |
|---|---|---|
| Question it answers | What is permanently true? | What is true for this decision, right now? |
| Contents | Entities and relationships | Relevant facts plus the event traces behind them |
| Lifetime | Stable, versioned, long-lived | Ephemeral — built and discarded per question |
| Scope | Domain- or enterprise-wide | Decision-scoped |
| Built by | Data and platform teams, offline | The agent runtime, at request time |
| Access control | Governed at the store | Gated at assembly, before retrieval |
| Optimised for | Coverage and correctness | Precision and token budget |
| Typical size | 104–109 nodes | 101–102 nodes |
| Fails by being… | Incomplete | The wrong subgraph |
Notice the last row. Those are not the same bug, and they are not fixed by the same team. An incomplete knowledge graph is a data engineering problem — a missing connector, a broken sync. The wrong subgraph is a context engineering problem, and no amount of additional ingestion will fix it. Most organisations are staffed entirely for the first failure.
CTX-02Where the knowledge graph breaks at decision time
None of these show up in the demo. The demo has one user, one tenant, and a graph small enough that "retrieve everything" is a viable strategy. Production has none of those things.
The haystack problem
A complete graph gives the agent more to search, not more to know. Coverage and findability are different properties, and improving the first can degrade the second.
Precise structure, probabilistic retrieval
You modelled typed relations and constraints for eighteen months — then queried them with top-k cosine similarity, which knows nothing about any of it. The structure is right there and the retriever refuses to look at it.
Traversal blowup
The obvious fix is to walk the graph instead. But two hops from a hub node — a shared platform, a busy VP, a common policy — returns half the enterprise. Unbounded traversal is just a slower way to retrieve everything.
State without traces
Knowledge graphs store what is. Decisions need what happened. The graph knows the ticket is open and assigned; it has no idea it was reassigned twice this week and escalated on Tuesday — which is the actual answer to "what's the status?"
Retrieve-then-filter leakage
Fetch everything, redact afterwards. But by then the unauthorised node has already shaped ranking, summarisation and phrasing. Removing the citation does not unlearn the content. This is a compliance incident, not a bug ticket.
The stale boundary
The graph is built by nightly ETL. The decision is happening now. Anything that changed since 2am is invisible — and the agent will state yesterday's world with today's confidence, because nothing in the pipeline models freshness.
Token budget collapse
Every node you inject competes for the same attention budget and bills you on every call. Worse, models reliably underuse material buried in the middle of a long context — so the fact you paid to include may be the one it skims past.
No decision provenance
When the answer is wrong, you need to know which facts drove it. If the retrieved set was never captured as an artifact, the failure isn't reproducible — you're debugging a conversation you can't replay.
Assembling a context graph
The fix isn't a better embedding model. It's admitting that "retrieval" is actually four distinct jobs wearing one name — and that only one of them is a similarity search.
Here is the pipeline that runs on every question. The numbers below are from a real shape of workload: a ~2.4M-node graph across Jira, Confluence, Salesforce, SharePoint and Slack, answering the DataMesh question from the top of this article.
Anchor → 6 seed nodes
Resolve the question to specific entities. "Q3 DataMesh migration" is not a vector — it's an epic with an ID. This is entity resolution, and it should be the first thing that happens, not a fallback when similarity search disappoints. Get this wrong and every downstream stage is exploring the wrong neighbourhood.
Traverse → 1,840 in scope
Expand from the seeds along typed edges, with a relation whitelist per intent and
a hard hop limit. A status question follows blocked_by, owned_by
and documented_in — it does not follow mentioned_in into every
Slack thread that named the project. The ontology finally earns its keep here.
Permission gate → 610 permitted
Resolve the asking user's rights in each source system and drop everything else — before retrieval, not after. Never retrieved means never summarised, never cited, never implied. This is also the stage that makes the whole thing legally deployable, which is usually what decides whether it ships at all.
Rank & budget → 38 nodes
Now — and only now — score what survived: graph distance, keyword match (BM25), vector similarity, and recency, combined and reranked. Then prune to a token budget the model can actually attend to. Similarity is the last signal, not the first.
Serialise with structure intact
Don't flatten the subgraph into a pile of chunks — you just spent four stages computing
relationships. Emit them: DATAMESH-41 —blocked_by→ VPC peering —owned_by→ Infra
team. The edge is the information. Flattening is where most of the gain
leaks back out.
Trace, cache, invalidate
Persist the assembled subgraph as a first-class artifact — that's your citation set, your audit record, and your replay for the postmortem. Cache assembly per intent template, and invalidate on upstream change rather than on a timer.
The stage most teams skip
Notice where the permission gate sits. Not last — third, before a single document is fetched. Almost every enterprise AI stack we're asked to review has it bolted on at the end, as a filter over results, because that was the easiest place to add it.
This is the difference between a pilot and a production rollout. A retrieve-then-filter system cannot honestly tell a security reviewer what the model saw. A permission-first system can answer that question with a log line.
Past the basics
Once assembly works, this is where context graphs start to pull away from a plain retrieval-augmented generation (RAG) setup.
A · Two users, two context graphs, both correct
Ask the same question as a VP and as a contractor and you should get two different subgraphs — and therefore two different answers. This feels wrong the first time you see it, because we're trained to think of retrieval as objective. It isn't. Context is permission-shaped. The correct answer to "who owns the remaining blockers?" genuinely depends on who is asking, and a system that returns identical answers to both is not more truthful — it's leaking.
B · Bi-temporal edges
Track two timelines per fact: valid time (when it was true in the real world) and transaction time (when your system learned it). That distinction is what separates "what was true then" from "what do we know now," and it's what lets a context graph answer "what did we believe on July 30?" without rewriting history. We went deep on this in AI agent memory in production — the same modelling applies here, one layer up.
C · Intent-typed subgraph templates
Most enterprise questions fall into a handful of shapes: status, ownership, impact, history, approval. Each shape implies a traversal pattern. Rather than deriving the pattern from scratch every time, define the templates — a status query expands this way, an impact query expands that way — and let the agent select one. Think database views, but for decisions. Retrieval quality stops being a mystery and starts being a spec you can test.
D · Decision traces as first-class nodes
The best context graphs don't only read. When the agent decides something, write the decision back as a node with edges to the evidence it used. Today's context graph becomes a node in tomorrow's knowledge graph — which is how a system stops repeating the analysis it did last quarter, and how "why did we do it that way?" becomes an answerable question.
E · Where the common patterns actually sit
| Pattern | What it retrieves | Structure used | Best fit |
|---|---|---|---|
| Vector RAG | Top-k similar chunks | None | Prototypes, single-fact lookup, FAQ |
| Hybrid RAG | Keyword + vector, reranked | Metadata filters | Document QA where terminology is precise |
| GraphRAG | Chunks + precomputed community summaries | Offline graph structure | Corpus-wide "what are the themes" questions |
| Context graph | A bounded, permission-checked subgraph | Live traversal + ontology | Decision support over governed enterprise data |
These aren't competitors so much as layers. GraphRAG's techniques can absolutely serve the ranking stage of context assembly. The distinction worth holding onto: GraphRAG is a retrieval technique; the context graph is the thing retrieval is supposed to produce.
F · How to evaluate a context graph
Retrieval metrics inherited from search will mislead you here, because they score documents and you're assembling a subgraph. Measure instead:
- Subgraph precision / recall — of the nodes needed to answer correctly, how many made it in, and how much noise came with them? Build a golden set of question → required nodes. This is tedious and it is the single highest-leverage thing on the list.
- Hop efficiency — nodes traversed per node kept. Rising numbers mean your relation whitelist is too permissive.
- Leakage rate — unauthorised nodes that reached assembly. The only acceptable value is zero, and you should be testing it adversarially, not hoping.
- Answer attributability — what fraction of claims trace to a node that was actually in the subgraph? Anything else is the model filling gaps from its weights.
- Token efficiency — accuracy per thousand tokens injected. Plot it against subgraph size and you'll find your plateau. It's almost always lower than you expect.
If you remember nothing else
- The graph was never the deliverable. The subgraph is. Nobody reasons over 2.4 million nodes — not your agent, and not your best analyst.
- Coverage and relevance are different problems. Adding another connector makes the first better and the second worse.
- Similarity is the last signal, not the first. Anchor, traverse, gate, then rank. Reaching for embeddings first is how precise structure gets wasted.
- Permissions belong at assembly, not after retrieval. Never retrieved is the only guarantee that survives a security review.
- Store the subgraph. It is your citation set, your audit trail, and the only way to debug an answer you can't otherwise reproduce.
- Context is permission-shaped. Two people, one question, two correct answers. Design for that on purpose.
Where Kaizen fits
Meridian is our enterprise knowledge platform, and it is built around exactly this pipeline. It connects Jira, Confluence, Salesforce, SharePoint, Slack and the rest of your stack, checks the asker's permissions in every source system before retrieving anything, assembles the subgraph for that specific question, and returns a cited answer — down to the ticket and page. Nothing leaves your VPC.
If your pilot demos beautifully and then goes vague the moment it meets a real graph and a real permission model, that's the conversation we have most weeks. Talk to our team →
Frequently asked questions
What is the difference between a knowledge graph and a context graph?
A knowledge graph is durable enterprise memory: every entity that exists and how those entities relate, governed and versioned, often millions of nodes. A context graph is the small subgraph assembled at request time for one specific decision — typically dozens of nodes — containing the relevant facts plus the event traces behind them, scoped to what the asking user is permitted to see. The knowledge graph is a noun; the context graph is a verb.
Is a context graph the same as GraphRAG?
No. GraphRAG generally refers to using graph structure to improve retrieval quality, often by precomputing community summaries over a graph offline. A context graph is a runtime artifact: the specific, bounded, permission-checked subgraph assembled for one question and discarded afterwards. GraphRAG is a retrieval technique; the context graph is the thing retrieval is supposed to produce — and GraphRAG methods can serve the ranking stage of assembling one.
Do I need a knowledge graph before I can build a context graph?
You need something with resolvable entities and typed relationships. That doesn't have to be a dedicated graph database — a well-modelled relational schema with foreign keys, or a document store with consistent entity IDs, can anchor traversal. What you can't skip is entity resolution and an ontology. Without stable identities and typed edges there's nothing to traverse, and you fall back to similarity search over flat chunks.
How many nodes should a context graph contain?
Small enough to reason across rather than search through — in practice, tens of nodes, not thousands. The ceiling isn't the model's context window; it's the point past which extra nodes stop improving answers and start diluting attention. Measure it: plot answer accuracy against subgraph size for your own workload and you'll usually find a plateau well before the window fills.
Why not just use vector search, or a larger context window?
Vector search returns what's semantically similar, not what's causally relevant — and the document explaining why a project is blocked rarely resembles the question about the blocker. A bigger window doesn't fix that either: it raises the ceiling on how much wrong material you can include, while cost, latency and attention dilution all scale with it. Relevance is a structural property, and structure is what traversal exploits.
How do you stop an AI agent from leaking documents a user shouldn't see?
Enforce permissions at assembly, before retrieval, rather than filtering results afterwards. Once an unauthorised node has been retrieved it has already influenced ranking, summarisation and phrasing — redacting the citation doesn't unlearn its content. A permission-first architecture resolves the asking user's rights in each source system first, and only then traverses what remains. Content that's never retrieved can't be summarised, cited, or implied.