The Graph You're Missing

Three different things are sold under the word graph, and teams keep buying the wrong one. An agent hits a wall, someone proposes a graph, six months of ontology work follows, and the wall is still there. The purchase was not wrong in general. It was wrong for that wall.

The three separate cleanly once you ask what question each one answers. A knowledge graph answers what is true, and who said so: entities as nodes, relationships as edges, ideally with a source and a timestamp on every edge. A cognitive graph answers how did I get here, recording the agent's own reasoning as it happens. A causal graph answers what would happen if I acted differently, encoding which variables actually move which other variables.

One caution about vocabulary before going further. Two of those three terms are settled. Knowledge graph has been standard usage since Google adopted it in 2012. Causal graph has a formal definition and a calculus behind it. Cognitive graph has neither, and gets attached to at least four unrelated structures depending on who is selling. In this article it means one specific thing: a persistent, queryable record of the agent's own reasoning.

To keep this concrete, one system runs through the whole article. A security operations agent doing alert triage. It is 04:12, and alert 40,113 of the week has just arrived.

The graphs do not compete. They answer different questions, and an agent has a different hole in it depending on which question it cannot answer.

That reframing turns an architecture debate into a diagnosis. You do not pick a graph from a catalog. You read the way your agent fails and the failure names the layer.

Symptom: confidently wrong

The alert says lateral movement on SRV-4471. The model reads the hostname, recognizes the naming convention, infers a domain controller, and escalates to P1. A human analyst is woken up. SRV-4471 is a decommissioned print server that nobody removed from the scanner's scope.

Nothing failed in the reasoning. Given what the model believed, escalation was correct. The belief was wrong, and no part of the pipeline could contradict it, because there was no representation of the estate for the model to consult. Document retrieval makes this worse rather than better: a wiki page from 2023 does describe SRV-4471 as a domain controller, retrieval will surface it, and the model becomes more confident while staying wrong.

A knowledge graph fixes the class of failure by making the entity the unit of storage instead of the document. SRV-4471 becomes a node with an owner, a subnet, a lifecycle state, and a last-seen timestamp. Microsoft Research demonstrated the general form of this advantage with GraphRAG: building an entity graph before any query arrives beats flat retrieval on questions that need more than one hop, which describes almost every real triage question.

The other two dimensions come along with it. On efficiency, one traversal replaces the five tool calls the agent would otherwise make to learn who owns a host. On governance, provenance becomes a property of the edge rather than an afterthought in a log file, so the question of where a fact came from has an answer built into the data structure.

The cost is staleness. A knowledge graph is a photograph of infrastructure that changes hourly, and a stale node is worse than a missing one because a wrong fact arrives dressed in the authority of a retrieved one. Bi-temporal designs address part of this. Graphiti, the engine behind Zep, stamps every edge with both when the fact was true and when the system learned it, so a later contradiction updates the record instead of corrupting it. The second cost is schedule. Ontology work pays back late, and teams that spend a year modeling before the first query often never ship at all.

Symptom: it learns nothing overnight

Three weeks later the same agent has a correct estate model. A similar alert family now arrives every night around the same hour. Every night the agent runs the same investigation, makes the same eleven tool calls, and reaches the same conclusion. No individual run is wrong. The waste is that run twenty-one has no access to runs one through twenty.

Deduplication at the signature level does not help, because the alerts are not identical. What repeats is the conclusion, not the input. Two alerts with different hashes, different source addresses, and different timestamps can still be the same judgment call, and only something that stored the judgment can see that.

A cognitive graph stores the reasoning itself. Nodes are observations, hypotheses, and conclusions. Edges are the inferences that connect them. The agent can then ask a question it currently has no way to ask: have I concluded something about this before, and on what evidence? Accuracy improves because the agent stops re-deriving conclusions it already found to be wrong. Efficiency improves most of all, since deduplicating at the conclusion is the difference between eleven tool calls and one lookup.

Governance is where this stopped being optional. Article 12 of the EU AI Act requires high-risk systems to automatically record events across their lifetime, with traceability appropriate to the system's purpose, and it became enforceable on 2 August 2026. An agent whose reasoning existed only inside a context window that has since been discarded cannot satisfy that on application logs alone. Application logs record what the agent called. They do not record what it believed.

The cognitive graph is a liability before it is an asset

Here is the part the vendors skip. A cognitive graph is a durable, queryable store of an agent's private reasoning, and every property that makes it useful also makes it dangerous.

It is poisonable. Write one false conclusion into the trace and every later run inherits it. A knowledge graph has an external referent, so a wrong node can be checked against the asset database. A wrong conclusion has no referent, because the source is the agent itself. OWASP ranked this as ASI06, memory and context poisoning, in its December 2025 Top 10 for Agentic Applications, and described the effect precisely: poisoned memory reshapes behavior long after the interaction that planted it.

It leaks. Reasoning traces capture whatever the agent was looking at, which in a security operations center means raw alert payloads, credentials that happened to appear in a log line, internal hostnames, and the names of the analysts who touched the case. That store now needs a data classification, a retention period, and an access model. Very few teams write a retention policy for an agent's thoughts before they write the agent.

It reinforces itself. An agent that remembers concluding "benign" is more likely to conclude "benign" again. When the first conclusion was right, that is exactly the behavior we wanted. When it was wrong, it is confirmation bias with a database behind it, and the wrong case is the one that matters, because it is the case an attacker will arrange deliberately.

None of this argues for skipping the layer. It argues for sequencing it correctly, which is the point the scorecard below is built around.

Symptom: it broke when nothing broke

The third failure survives both previous fixes. The agent now has a correct estate model and a full memory of its own reasoning, and its false positive rate jumps by an order of magnitude in a single week. No system changed. IT enabled remote desktop access for a hybrid work program, and traffic on port 3389 went from rare to ordinary.

The agent had learned that activity on 3389 predicts compromise. The correlation was real in the training data and it was never the mechanism. When the world moved, the correlation inverted, and the model had no way to notice, because a correlation carries no information about why it holds. This is Judea Pearl's distinction between seeing and doing: observing that escalated tickets correlate with resolved incidents tells you nothing about whether escalating causes resolution.

A causal graph encodes the mechanism rather than the pattern. On accuracy, it survives the shift that breaks the correlation. On efficiency, it prunes the hypothesis space, so the agent tests the few nodes that could actually produce the observation instead of enumerating every explanation consistent with it. On governance, it supports the counterfactual that every post-incident review eventually asks: if the agent had escalated at 04:12, would the outcome have been different? A correlational model cannot answer that question. It can only report what happened next to what else happened.

The cost is that causal graphs are the most expensive of the three to build and the worst of the three to get wrong. A wrong knowledge graph is wrong about a fact, which is embarrassing and fixable. A wrong causal graph is wrong about the shape of the world, and it defends its errors fluently, because everything downstream of a bad structural assumption stays internally consistent. I have written about the upside of causal modeling in The Causal Advantage. The discipline it demands is the reason most teams should not start here.

The honest scorecard

A grid in which every cell is a win is a sales deck. Each of these three layers makes at least one thing worse, and the cost row is the row to read first, because it is the one that determines build order.

Reading the cost column gives an order that surprises most teams. Build the knowledge graph first, because it is the only layer with an external referent and everything above it needs something to be checked against. Add causal structure second, but only around the decisions that have to be defended. Build the cognitive graph last.

That last instruction is the counterintuitive one, since the cognitive graph has the largest and fastest efficiency payoff. Build it first and you get exactly the store OWASP describes: an unaudited, poisonable record of the agent's private conclusions, with nothing to validate those conclusions against. The same layer built third sits on top of a grounded estate model and a causal model that can flag when a remembered conclusion no longer follows. The layer does not change. What changes is whether anything can catch it when it goes wrong.

What leaders should do

1. Sort your last twenty agent failures using Figure 2 before approving any graph spend. The two most expensive mistakes in this area are commissioning an ontology to fix a memory problem and buying a memory product to fix a grounding problem, and both are avoidable with an afternoon of triage.
2. Require two timestamps and a source on every edge of the knowledge graph from the first commit: when the fact was true, and when the system learned it. Retrofitting provenance onto a graph already in production costs more than building it correctly, and Article 12 of the EU AI Act has been enforceable since 2 August 2026.
3. Treat the cognitive graph as a production data store rather than a log. Before it ships it needs a data classification, a retention period, an access model, and a defined procedure for invalidating a conclusion that turns out to be poisoned. If nobody owns that procedure, the layer is not ready.
4. Add causal structure only where a counterfactual has to be defended to a regulator, a customer, or an incident review. Everywhere else, correlation with a drift monitor is cheaper and honest about what it is.

The word graph will keep being used to mean all three of these things at once. Teams that separate them by the question each answers will spend their next architecture budget on the layer they are actually missing.