What Is Graph Engineering? A Field Guide for Builders
The term went viral on X in 48 hours, with three competing meanings and one fabricated study. Under the noise: a real discipline with benchmark numbers, one gap nobody has claimed.
TL;DR
“Graph engineering” exploded on X this week with three competing definitions and a viral study that does not exist.
The discipline underneath is real and measurable: graphs beat vector search on multi-hop and temporal questions, and lose on simple lookups and cost.
A vault of linked markdown is already 80% of a graph index. I am building the missing 20% in the open.
Agents that read flat documents miss chains: who decided X, what replaced it, what broke because of it. Graph-shaped memory is the fix, and it is measurable. LinkedIn cut support resolution time 28% with it, and the best graph systems answer multi-hop questions 10 points better than vector search.
That is the business case. Now the story.
On July 18, Peter Steinberger posted twelve words on X: “Are we still talking loops or did we shift to graphs yet?” Thousands of likes. Within 48 hours, “graph engineering” had three competing definitions, a wave of copycat posts, and a viral claim about a “$3.1M Stanford and Anthropic study.”
I went looking for that study. It does not exist. Fabricated engagement bait.
But I kept digging, because under the noise there is a real discipline with a decade of research, working tools, and benchmark numbers that survived independent evaluation. I spent the weekend reading all of it so you do not have to.
By the end of this issue you will understand graphs better than most people posting about them this week.
The whole primitive in 60 seconds
Strip every buzzword away and a graph is two things.
Nodes: the things you know about. A person, a project, a decision, an incident.
Edges: the connections between them.
That is the entire primitive. The reason it matters for AI is retrieval. An agent answering a question has to find the right knowledge first, and there are only three ways to find things:
Keyword search finds notes containing a word. Fails when the answer uses different words.
Vector search finds notes that are about similar things. Fails when the answer is spread across notes that are individually not similar to the question.
Graph traversal starts at one node and walks the connections. It is the only method that can follow a chain of reasoning.
The question that breaks vector search
Here is a synthetic example, the kind of question every real knowledge base gets asked:
“Why did we drop Redis for the job queue?”
Vector search embeds the question and pulls the ten chunks most similar to it. You get ten notes that mention Redis. None of them explains the decision, because the decision lives in the structure: a decision record, the thing it replaced, and the incident that triggered it. Three separate notes. Similarity search has no concept of “these three belong to one causal chain.”
Graph traversal walks it:
hop 1: [[Job queue]] --decided_by--> [[ADR-007 Postgres queue]]
hop 2: [[ADR-007]] --supersedes--> [[ADR-003 Redis queue]]
hop 3: [[ADR-003]] --caused--> [[Incident 2026-03-11]]
Three notes, about 1,000 tokens, causal chain intact.
Each step is a hop. Questions needing more than one hop are multi-hop questions, and they are where flat retrieval consistently breaks. “Who decided X and what broke because of it” is a two-hop question. Most interesting questions about any real body of knowledge are multi-hop.
One sentence to keep: vector search finds things that sound like your question. Graphs find things that are connected to your answer.
One bit versus meaning
Now the detail that decides whether a graph is useful or just pretty.
An untyped edge says “these two notes are related.” One bit of information. A typed edge says how: supersedes, depends_on, decided_by, caused.
Run the Redis example without types. The traversal becomes “the queue is related to a decision, which is related to another decision, which is related to an incident.” Did ADR-007 replace ADR-003, or the other way around? Did the incident cause the decision or the decision cause the incident? The chain survives. The meaning is gone, and the agent has to re-read every note and guess.
Typed edges turn a pile of links into something you can reason over. Hold onto that. It is the center of everything that follows.
Where the term actually came from
Know the history, so nobody can bluff you with it.
“Graph engineering” sits on a treadmill of terms. Each one described a real shift. Each one got turned into content slop within weeks:
2023: prompt engineering. Craft the words you send the model.
Mid-2025: context engineering. Curate everything in the window.
June 2026: loop engineering. Design the agent’s act-observe-retry cycle.
July 2026: graph engineering. Design what happens between and across loops.
The receipts: a quiet blog post by Josh Simmons on July 4 is the earliest documented use I found. Steinberger's July 18 post lit the fuse (he was mocking the treadmill; the treadmill did not care). Carlos Perez published one of the first serious essays about ten hours later. The backlash started the same day.
Within 48 hours the term meant three different things:
Orchestration graphs: design multi-agent systems as explicit graphs instead of loops. Typed nodes, typed transitions, checkpoints. This is LangGraph and Temporal territory.
Graphs of loops: networks of self-improvement cycles watching each other. The most abstract meaning, and the least actionable today.
Graph-structured knowledge and memory: the agent’s knowledge stored as typed nodes and edges it can traverse.
Only the third one has a decade of research, working tools, and real money behind it. Serious people were building it before the name existed, under different words: Foundation Capital called it “context graphs” in December 2025 and put a trillion-dollar label on it. Gartner predicts over half of enterprise agent systems will use graph-based context by 2028. SAP shipped a knowledge graph as its agent context layer.
The term is new. The substance is not.
How GraphRAG actually works
The umbrella name for graph-based retrieval is GraphRAG. Four systems matter, and each teaches one lesson.
Microsoft GraphRAG (2024) is the reference architecture:
An LLM reads every chunk and extracts entities plus relationships.
Community detection clusters related entities into neighborhoods.
An LLM writes a summary report for every community.
At query time, broad questions map-reduce over the reports; specific questions expand from a matched entity.
It works. It is also brutal on cost: an LLM call per chunk at index time. One widely cited estimate put it at around $33,000 to index a single large enterprise dataset. Lesson one: the naive version is too expensive, and its free-text edges do not compose.
LazyGraphRAG (Microsoft’s own correction) flips the design: build only a cheap structural graph at index time, and do the expensive thinking at query time. Indexing cost drops to about 0.1% of the original. Answer quality stays comparable.
Lesson two, and remember this one: you do not need to pre-compute the graph’s meaning. A cheap structural graph plus smart traversal at query time gets most of the value.
HippoRAG 2 (2025) is the benchmark king. It fuses graph structure with embeddings and ranks results by spreading importance along edges from wherever the query touched the graph. It spends about 1,000 tokens per query, wins on multi-hop, and, critically, does not get worse at simple questions to get better at hard ones. Most graph systems do. Lesson three: the winning retrieval is hybrid, never graph-only.
The 2026 trend line across the whole field: lazy indexing, agentic traversal (the agent decides which hops to take, live), small controlled edge vocabularies, and honest routing. Use the graph only for questions that need it.
Memory that knows what time it is
GraphRAG answers questions about a corpus. Agent memory is harder: knowledge that changes while the agent uses it. You change jobs. A decision gets reversed. A fact true in March is false in July.
This is where graphs do something vector stores structurally cannot.
Graphiti, the open-source engine behind Zep, tracks two timelines per edge: when the fact was true in the world, and when the system learned it. When new information contradicts an old edge, the old edge is not deleted. Its validity interval is closed, and the new edge takes over.
The agent can now answer both “where does she work?” and “where did she work in 2024?” from the same graph. Facts get superseded, not overwritten. A vector store can only overwrite or duplicate; it has no native concept of “this was true until May.”
Any long-lived knowledge base has this shape. Decisions supersede decisions. Claims go stale. A system that cannot represent “X replaced Y on this date” slowly fills with contradictions, and an agent reading it will confidently cite the stale half.
Notice the vocabulary this needs: supersedes, contradicts, valid_from, valid_until. Typed edges again.
The scoreboard, honestly
Half the numbers in this field are vendor-reported on their own benchmarks. Here is what independent evaluation actually shows, as of mid-2026:
Graphs win three things, by wide margins:
Multi-hop reasoning: 53.4% vs 42.9% for vector RAG on GraphRAG-Bench; HippoRAG 2 beats a strong embedding model by 9.5 F1 points on 2WikiMultiHopQA.
Temporal reasoning: the graph variant of Mem0 scores 58.1 where OpenAI’s memory scores 21.7. The most lopsided numbers in the field.
Corpus-wide synthesis: 64.4% vs 51.3%.
Graphs lose two things:
Simple fact lookup: 60.9% for plain vector RAG vs 60.1% for the best graph method. The graph adds redundant context and wins nothing.
Cost: Microsoft GraphRAG’s global search burned 331,375 tokens per query in the benchmark. Vector RAG: 880. (HippoRAG 2: 1,008. Efficiency is possible.)
Two warnings worth the whole section. LightRAG posted huge wins on its own benchmark, then collapsed to 6.6 average F1 (versus 59.8 for HippoRAG 2) under independent evaluation. Never trust a system evaluated only by its authors. And in Mem0’s own paper, the graph variant lost to the non-graph variant on multi-hop questions. Graphs are a tool, not a religion.
The practitioner consensus: route by question type. Vector for lookups, graph for chains.
The math that kills graph projects
If graphs win benchmarks, why does not everyone run one? Because of one number almost nobody says out loud.
Entity resolution is deciding that “Dr. John Smith,” “J. Smith,” and “John” are one node, and that “Mercury the planet” and “Mercury the element” are two. Extraction pipelines get this wrong constantly, and the errors compound multiplicatively over hops.
At 95% per-hop accuracy, a 5-hop chain is 77% trustworthy. At 85%, it is 44%.
Your impressive multi-hop traversal is a coin flip.
Sit with that, because it flips the whole build order. The expensive part of graph engineering is not graph algorithms. It is deciding what is the same thing. And there is one place where that problem is already solved: human-curated wikilinks. When someone writes [[ADR-007]] in a note, entity resolution is done, by construction. No fuzzy merging, no compounding error.
Extraction pipelines spend most of their engineering budget trying to recover what a wikilink gives you for free.
The gap nobody has claimed
I maintain obsidian-second-brain, an open-source Claude Code skill that runs an Obsidian vault as an AI-first second brain (45 commands, MIT, starred by 3,400+ developers). I have written before about what a working second brain has to do that Karpathy’s LLM Wiki pattern does not. So the question I actually cared about all weekend: who has built graph engineering on plain markdown?
The answer surprised me. The space is five months old, moving fast, and every single player is missing exactly one leg of the tripod: typed edges in the files, graph rules and validation, agent retrieval.
Basic Memory (3.5k stars) has typed relations in markdown and a real agent API. But the types are freeform strings: no vocabulary, no rules, no validation.
Breadcrumbs, the veteran Obsidian plugin, has real graph engineering: typed links, automatic inverses, transitive rules. Built entirely for human navigation. No AI surface at all.
Penfield is the only team articulating the full vision, and they route your graph into their cloud for $10 to 20 a month. Your markdown is an import source, not the store.
Others (Rowboat at 13.1k stars, obra’s knowledge-graph, IWE) ship agent-facing graph tools over vaults with explicitly untyped edges.
And two things, as of this weekend, exist nowhere:
A linter for typed edges. Nothing validates a vault’s graph: unknown types, dangling targets, missing inverses, contradiction cycles. Zero tools.
An eval proving typing works. Nobody has published evidence that typed links measurably improve agent answers over plain links. Zero hits.
A well-kept vault is already 80% of a GraphRAG index. Entity resolution: solved by wikilinks. Indexing cost: zero, the graph is built at write time. The missing 20% is exactly those two lists above.
What I am doing about it
I am building the missing 20% into obsidian-second-brain, in the open, starting this week:
A small typed-edge vocabulary (10 to 20 verbs: supersedes, depends_on, decided_by, caused) written as plain inline fields, so notes stay human-readable and Obsidian-native.
The linter. The thing that exists nowhere, and the cheapest to ship.
The eval: same vault, same questions, typed versus untyped retrieval, published numbers.
Update (July 21): the typed-edge vocabulary and the linter shipped in the repo the day after this post went out. The eval is the piece still open.
The 2026 consensus from every serious system points the same way: small typed core, cheap indexing, hybrid retrieval, temporal supersession. All four of those are implementable on markdown files you own. That is the version of graph engineering that survives after the hype cycle moves on.
If you want to watch it get built (and get the benchmark numbers when the eval lands), subscribe. This is the kind of thing I ship here every two weeks.
Turns out the term everyone laughed at pointed at something real. The people laughing and the people building are not the same people.
Frequently asked questions
What is graph engineering? Graph engineering is designing AI systems around explicit graphs: knowledge stored as nodes (entities) and typed edges (relationships) that an agent can traverse, instead of flat documents searched by similarity. The term went viral in July 2026, but the underlying discipline (knowledge graphs, GraphRAG, graph-based agent memory) predates the name by years.
Is graph engineering the same as GraphRAG? GraphRAG is one part of it: retrieval-augmented generation where the retrieval step uses a graph. Graph engineering also covers agent memory graphs (like Zep’s Graphiti) and multi-agent orchestration graphs (like LangGraph).
Is GraphRAG better than vector RAG? It depends on the question type. Independent benchmarks show graphs win multi-hop reasoning (53.4% vs 42.9%), temporal reasoning, and corpus-wide synthesis, and lose on simple fact lookups and cost. The practitioner consensus is to route by question type.
What is a typed edge in a knowledge graph? An untyped edge only says two things are related. A typed edge names the relationship: supersedes, depends_on, decided_by, caused. Types are what let an agent reason over the graph instead of guessing what each link means.
Can I build a knowledge graph in Obsidian? Yes. Every note is a node and every wikilink is an edge, which solves entity resolution by construction. What Obsidian lacks out of the box is typed edges, graph validation, and an AI retrieval layer, which is the gap this article describes.
Why do knowledge graph projects fail in production? Entity resolution errors compound multiplicatively over hops: at 85% per-hop accuracy, a 5-hop chain is only 44% trustworthy. Stale graphs and indexing cost are the other two killers.
Key takeaways
Vector search finds things that sound like your question. Graphs find things that are connected to your answer.
“Graph engineering” was born on X on July 18, 2026 with three competing meanings. Only graph-structured knowledge and memory has benchmarks and production evidence behind it.
Graphs win multi-hop, temporal, and synthesis questions by wide margins, and lose simple lookups and cost. Route by question type.
An untyped link carries one bit. A typed edge (supersedes, depends_on, caused) is what turns a pile of links into something an agent can reason over.
Entity resolution, not graph algorithms, is where graph projects die: at 85% per-hop accuracy, a 5-hop traversal is 44% trustworthy. Human-curated wikilinks solve it by construction.
Typed edges plus graph rules plus agent retrieval on plain markdown exists nowhere as one local-first package. The linter and the typed-vs-untyped eval have never been shipped by anyone.
Further reading
HippoRAG 2 (arXiv 2502.14802) - the benchmark-king paper; also the independent evaluation where LightRAG collapsed.
Zep: temporal knowledge graphs for agent memory (arXiv 2501.13956) - the bi-temporal model behind “facts expire, not die.”
GraphRAG-Bench (arXiv 2506.05690) - the honest scoreboard: where graphs win and lose by task type.
We are entering the graph engineering phase - the July 4 post that quietly coined the term before the meme wave.
I rebuilt Karpathy’s LLM Wiki. Here’s what’s missing. - my earlier piece on what a working second brain needs beyond the static wiki pattern.
About the author
Eugeniu Ghelbur is an AI Automation Engineer and the creator of obsidian-second-brain, an open-source Claude Code skill starred by over 3,400 developers on GitHub. He builds production AI systems for marketing and sales workflows, and his personal research covers AI agent memory, AI-first knowledge management, and second brains that maintain themselves. He writes The AI Operator (theaioperator.io), a weekly systems newsletter where every post documents a working build, including this one. The fastest way to reach him is e.ghelbur@gmail.com, and his open-source work lives at github.com/eugeniughelbur.
Really clear breakdown, graph engineering concepts finally make sense to me now.