Don't Fool Yourself: Context Graphs

February 17, 2026

Don't Fool Yourself: Context Graphs hero image

The most expensive problem in an engineering organization isn’t bugs or speed. It is amnesia. And today almost every modern company is engineering-driven in one way or another :)

By amnesia I mean this: you seem to ship features/products fast, but you keep ending up in archaeology mode, and you have to dig to remember “who even remembers this…”, “where did we discuss it”, “why did we do it this way”.

Knowledge about our systems gets spread randomly across Slack, Jira, Git, AI notes from calls, and finally (worst of all) inside personal heads.

And now we have context graphs. The pitch often sounds like this: “let’s collect decision traces from different places, connect them, and get institutional memory! It will help with audits, onboarding, and finding past decisions…”.

A context graph is a graph built from events/decisions (decision traces), then used for context-based search (often also as a base layer for an AI agent).

Nothing fundamentally new: under different names, this “contextuality” idea has existed in IT and engineering for a long time: audit trail, process mining, data lineage, knowledge graph, ADR/decision log, event sourcing. What’s new is that it’s cheaper now, and people add LLM agents on top.

Great thing, but dont fool yourself: this is not a silver bullet, and there are critical pitfalls here.

Here they are.

1) System entity identification.

“Alex”, “Alexander”, “@alex”, “alex@corp”, “mr.crablex” in Discord - one person or five different people? Until you resolve this formally, your graph will likely already be lying.

2) Age and versions.

Policies change, org structure changes, every decision has an “expiration date”. Does your graph model that? It had better. Otherwise you will apply a precedent from the previous CFO’s era as if it were “eternal truth”.

3) Access and retention.

If you just put “why we rejected candidate/client X” into one layer, and also “forever”, you just created a security and compliance problem. At some point, someone with access (doesn’t matter who) will leak a database dump to places you won’t like.

4) Ethics and incentives.

The moment people understand/think that “big brother writes personal notes on everyone”, they move real discussion into Slack DMs or non-corporate messengers. Graph completeness? Questionable.

5) Mixing facts and explanations.

LLMs love writing beautiful “why” text. If this enters the same layer as real facts, you permanently lose auditability.

It is also important not to confuse “memory” with a real model of how the org works. Decision traces in the format people propose are not “why”. They are just evidence. And until their attributes, identities, and links to other data are verified, they are, strictly speaking, unverified traces.

Evidence is great for “what happened and who clicked the button”, but it does not have to answer “what was going on in people’s heads and in that situation? what led to this click? who decided to click, and based on what, and why exactly then?”. That whole part is about “why”.

So if a graph (or an AI agent on top of it) cannot honestly say “I don’t know”, it will lie confidently, without meaning to.

Many context-graph supporters already admit this key point: “why” is often not verifiable, and in reality we mostly capture “how” - sequence of actions, policies, approvals - and only maybe from that we get closer to “why”.

This is already honest. Let’s spread this honesty in the community: everything above the “how” level should have hypothesis status, not truth status.

Wait, you mean we must model statuses too?! YES.

My point is simple: without explicit context boundaries, a clear term dictionary, system/subsystem invariants, and also preferably versioning for everything that should be versioned, such a graph quickly becomes a pretty dump: more and more data, less and less reproducibility - until reproducibility becomes almost impossible.

In context-graph discussions, lines like “schema isn’t the starting point, it’s the output” sound cool (and in a very narrow research sense can even be true), but as an engineering principle this is a ticking bomb.

Sure, trace collection can start “without schema”.

But rational use of these traces will still require a model, ontology, and contracts! Otherwise you don’t have a “living graph”, you have a living argument about what words in graph outputs even mean.

“Schema at the output” without clarification is a plain lie. The clarifications are these: I believe only a real, persistent AGI could restore a good organizational model from an unstructured, badly modeled graph (a dump), so we could finally do all the things context-graph marketing promises. And this AGI would still need to go talk to directors and employees to clarify and validate many things :)

In the end you get the same model you could build from day one even without any graphs - and then build graphs and all the nice extras around that model.

Here is a free fast test for any “context graph” solution:

Only after that should you automate memory.

If this was useful, please subscribe to my Substack for free and share this post with one friend. It really helps me keep writing! Thank you :)