Why Context Graphs Without User Models Are Just Fancy RAG

TL;DR

• Context graphs add structure to retrieval (entity resolution, relationship traversal, temporal context) but without per-user models they produce the same response for every user, architecturally equivalent to RAG with more engineering overhead
• Graph-augmented retrieval improves factual accuracy (~18% in controlled tests) while user-augmented retrieval improves satisfaction (~41%), users care about understanding, not retrieval sophistication
• The difference between a context graph and context intelligence is user understanding: the graph models the world, the intelligence layer models the person navigating it

Context graphs without user models are architecturally equivalent to RAG with a more expensive retrieval layer, because they still serve every user the same synthesized response regardless of expertise or intent. Teams spend 12 to 18 months building sophisticated graph infrastructure only to discover that two users asking the same question get identical outputs. This post compares graph-augmented retrieval with user-augmented retrieval and explains how to add the missing user layer to your existing graph.

The Architecture Comparison Nobody Wants to Have

RAG retrieves documents based on query similarity and injects them into the LLM prompt. The output depends on the query. It does not depend on the user.

A context graph replaces (or augments) the vector store with structured relationships. Instead of semantic similarity alone, retrieval follows entity relationships, traverses multi-hop paths, and respects temporal context. The output depends on the query and the graph structure. It still does not depend on the user.

This is the part that makes context graph teams uncomfortable. The graph changes what is retrieved. It does not change how the retrieved information is presented. A junior developer and a VP of Engineering asking “How does our SSO integration work?” get the same graph traversal, the same retrieved context, the same synthesized response. The graph does not know the junior developer needs implementation details and the VP needs an architecture overview.

The graph added structure to retrieval. It did not add understanding to synthesis. That is the definition of fancy RAG.

What the Graph Gets Right (and Where It Stops)

Context graphs genuinely solve real problems that RAG alone cannot.

Entity resolution. The graph connects Account X in Salesforce to Account X in the product database to Account X in the support system. RAG with a single vector store cannot do this. The graph provides unified, cross-system context about entities.

Relationship traversal. The graph can answer “which accounts in the financial services vertical that use Feature Y also had support escalations about Feature Z?” RAG cannot follow these structured relationship paths. The graph enables compositional reasoning about connected entities.

Temporal context. The graph tracks how entities and relationships change over time. Account X adopted Feature Y six months ago. Their support ticket volume dropped 30% after. RAG operates on a flat document store without this temporal dimension.

These are valuable capabilities. But they are all about the world, entities, relationships, changes in the domain. None of them tell the AI anything about the person asking the question.

The Three Layers of Context

It helps to think about context as three distinct layers, each solving a different problem.

Layer 1: Document context (RAG). What information exists? Solve this with vector stores, embeddings, and semantic retrieval. The output is relevant documents.

Layer 2: Structured context (Graph). How is information related? Solve this with entity resolution, relationship mapping, and graph traversal. The output is structured, connected knowledge.

Layer 3: User context (Self-model). Who is asking and what do they need? Solve this with per-user belief models, expertise tracking, and goal inference. The output is personalized synthesis.

Most teams invest heavily in Layer 1, then spend a year building Layer 2, and never build Layer 3. They end up with extraordinarily sophisticated retrieval infrastructure that serves everyone identically.

The irony is that Layer 3 delivers the most user-visible improvement. In the controlled test we ran, moving from Layer 1 to Layer 2 improved factual accuracy by 18%, meaningful but not transformative. Moving from Layer 2 to Layer 3 improved user satisfaction by 41%. Users notice understanding far more than they notice accuracy.

The Architectural Fix

The fix is not to abandon your context graph. It is to add the missing user layer. The graph and the self-model are complementary, the graph provides structured world context, the self-model provides user context, and the synthesis layer uses both.

1// Layer 2: Graph-augmented retrieval← Structured world context
2const graphContext = await knowledgeGraph.traverse({
3  query: userQuery,
4  startEntity: accountId,
5  maxHops: 3,
6  includeTemporalContext: true
7});
8
9// Layer 3: User-model augmentation← Who is asking?
10const userModel = await clarity.getSelfModel(userId);
11const userContext = {
12  expertise: userModel.getBeliefs({ context: 'expertise' }),
13  currentGoal: userModel.getActiveGoals(),
14  knowledgeGaps: userModel.getBeliefs({ context: 'knowledge_gaps' })
15};
16
17// Synthesis: world context + user context← Personalized output
18const response = await llm.generate({
19  query: userQuery,
20  worldContext: graphContext,   // What is true about the domain
21  userContext: userContext,     // Who is asking and what they need
22});

The self-model does not replace the graph. It makes the graph useful to each individual user. The graph retrieves structured, relationship-aware context about the domain. The self-model tells the synthesis layer how to present that context: what to emphasize, what to explain, what to skip, what level of detail to use.

Without the self-model, the graph is a better library. With the self-model, the graph becomes an advisor who knows both the subject matter and the person they are advising.

Trade-offs

Adding a user model layer introduces real costs.

Integration complexity. Bridging a context graph with a self-model service means coordinating two different data systems with different update cadences. The graph updates when the domain changes. The self-model updates with every user interaction.

Cold start. New users have no self-model, so the system falls back to graph-only retrieval until sufficient interactions accumulate. This is not a failure, it is graceful degradation. The experience starts at fancy-RAG quality and improves to personalized quality.

Prompt budget. Adding user context to the synthesis prompt competes for tokens with graph-retrieved context. More user understanding means less room for domain context per request. Finding the right balance depends on your use case.

What to Do Next

1. Run the two-user test. Pick your most common query. Generate responses for two users with meaningfully different expertise levels. If the responses are identical, your graph is not personalizing, it is retrieving.

2. Measure your context layers. Count the engineering investment in each layer: document retrieval (RAG), structured retrieval (graph), user understanding (self-model). Most teams find the ratio is 40/55/5 or worse. That ratio should shift toward user understanding.

3. Add the user layer. You do not need to rebuild your graph. You need to add the missing layer that makes it personal. Explore how Clarity’s self-model API integrates with any existing graph or RAG infrastructure.

Your context graph knows everything about the world. It knows nothing about the user. That is fancy RAG. Add the missing layer.

References

1. 2016 survey of 2,000 Americans by Reelgood and Learndipity Data Insights
2. Scientific American explains
3. cold start problem
4. Progress Software describes this core tension well
5. New America analysis of AI agents and memory

Related

• Context Layer Problems Nobody Talks About
• Context Graphs Miss the Epistemic Layer
• Context Engineering Needs a User Layer