Graph Rot: Why Your Knowledge Graph Is Lying to Your AI

Two years ago we built an eight-stage document-intelligence pipeline for a family office managing hundreds of millions in assets. The system read PPMs, SPAs, SAFEs, K-1s, cap tables, and operating agreements, extracted the entities inside them, and wrote everything into a Neo4j knowledge graph that AI agents could query.

During validation, we found the same portfolio company in the graph under eleven different names. Same company. Eleven nodes. Every agent that queried it got a different slice of the truth, and none of them knew the other slices existed.

Nothing had crashed. No error logs. The graph just quietly disagreed with reality, and the AI on top of it answered with full confidence.

We started calling this graph rot. This post defines the term and walks through the seven ways we've watched it happen in production.

What is graph rot?

Graph rot is the silent decay of a knowledge graph's correctness over time. The graph stays queryable and the system stays up, but the facts inside it drift away from the documents and the world they came from: duplicate entities, wrong edges, stale values, unvalidated merges.

You may have heard of “context rot,” where an LLM's long context degrades its answers. Graph rot is the structural version of the same disease. It doesn't live in a context window that resets with each session. It lives in your database, it compounds, and every agent that uses the graph inherits it.

A knowledge graph isn't a database. It's a witness, and witnesses can lie.

Why does this matter now?

Because the industry is wiring agents directly to graphs. Gartner named GraphRAG one of its top data and analytics trends for 2026, and knowledge graphs are becoming the standard answer to “how do we give agents memory that survives a session?”

That changes the cost of a wrong fact. In classic RAG, a bad chunk produces one bad answer. In an agentic system, a bad node produces bad decisions. An agent acts on it, writes results back, and the error compounds. MIT's 2025 research on enterprise GenAI found 95% of pilots produce no measurable P&L impact, and the failure usually isn't the model. It's the layer between the model and the company's actual data. The graph is that layer.

The 7 ways a knowledge graph rots

These come from production systems we run, not from a survey.

1. Duplicate entities

The same real-world thing exists as multiple nodes. “Acme Holdings LLC,” “Acme Holdings,” and “ACME HOLDINGS, L.L.C.” each get their own node, and each collects a partial history. Entity resolution is the hardest problem in graph construction, and LLM extraction alone doesn't solve it. Extraction gives you names, not identity. Our eleven-name company is the canonical case.

2. Phantom edges

The extraction model invents a relationship that isn't in the source document. LLMs are eager to please; ask one to find connections and it will find connections. Without a grounding check against the source text, invented edges enter the graph wearing the same confidence as real ones.

3. Mislinks

Both entities are real, but the connection between them is wrong: an investment attached to the wrong fund, a director attached to the wrong company. These are nastier than phantom edges because every individual piece looks valid. We built post-creation mislink detection into the family office platform precisely because spot-checks kept finding these by accident.

4. Stale facts

The world changed and the graph didn't. A valuation from an old cap table, an officer who left, an address from three filings ago. A graph without timestamps and validity windows treats 2023 and 2026 as the same moment.

5. Schema drift

Your extraction pipeline was tuned for the documents you had at launch. Then a new fund sends a differently structured SPA, a K-1 format changes, and the pipeline keeps running, extracting the wrong fields into the right shape. The graph fills with values that are perfectly formatted and quietly wrong.

6. Orphan islands

Subgraphs that nothing connects to. They usually appear when entity resolution fails (see #1): the new document's entities didn't match the existing ones, so a parallel island formed. Retrieval traverses connections, so an island might as well not exist. It still shows up in counts and exports, though, making the graph look richer than it is.

7. Silent merges

The opposite failure: two entities that shouldn't be merged, merged anyway by an over-eager matching rule. Two people named Daniel Chen become one person with two careers. Silent merges are the hardest rot to detect because the evidence of the mistake was destroyed by the mistake.

How do you know if your graph is rotting?

You'll see the symptoms in the AI before you see them in the graph. The tells we watch for:

• Agents give different answers to the same question, depending on phrasing
• Answers cite the right document but the wrong entity
• “How many X do we have?” returns numbers nobody trusts
• The same search returns near-duplicate results with conflicting details
• Engineers stop trusting the graph and quietly go back to grepping the source documents

That last one is the loudest signal. When the people who built the system route around it, the rot is already advanced.

What can you do about it?

Treat graph correctness as an engineering discipline, not a byproduct of extraction. In practice, building these systems has pushed us to four habits:

1. Resolve identity separately from extraction. Extraction finds names; a dedicated entity-resolution pass decides which names are the same thing. On the contract-review side of our work, where 23 agents analyze legal documents, routing and identity checks cut LLM calls by 75%. Correctness work pays for itself.
2. Check every edge against its source. A relationship that can't point to the sentence it came from doesn't go in the graph.
3. Score the graph before you trust it. We run judge models with a 100-point rubric across five dimensions, against a suite of 61 evaluation cases, before agents are allowed to consume the graph. If you can't score it, you can't trust it.
4. Audit on a schedule. Rot is gradual, so detection has to be recurring. We run a structured health check across all seven vectors. It's the same one we offer as a knowledge graph audit.

Each of these deserves its own post, and over the next few months we'll write them: duplicate entities, mislink detection, scoring, and the full health-check method, with real numbers from production systems.

We build and fix knowledge graphs for AI systems, including a document-intelligence platform for a family office managing hundreds of millions in assets. If your graph is misbehaving, book a 15-minute call.