Graph Engineering Decoded: Two Definitions, One Test
Two camps gave the same term two meanings this summer. One models what your system knows, the other models how work moves. Picking wrong costs a rebuild.
TL;DR
Graph engineering now means two different things, and both definitions shipped in 2026: a graph of what the system knows, and a graph of how work flows through agents.
They fail differently. A knowledge graph fixes wrong answers. An agent graph fixes wrong steps. Building the wrong one buys you weeks of work that does not touch your actual failure.
The test is four questions, at the bottom of this post. Answer them before you write a schema or a state machine.
Search for graph engineering today and you get two answers that do not agree.
One set of articles tells you it means modeling your data as entities and typed relationships so a language model can traverse facts instead of guessing at them.
Another set, most of it published in July, tells you it means designing your agent system as an explicit graph: nodes are agents and tools, edges are routes, and the whole thing has shared state.
Both camps are describing something real. They are not describing the same thing.
I wrote the field guide that defines the term and I have watched the second meaning arrive over the last six weeks. This post is not a referee call about who owns the word. It is the thing neither camp gives you: a way to tell which one your problem is, before you spend a month building the wrong grap
Definition one: a graph of what the system knows
In this version, the nodes are things. A person, a project, a decision, a document, a customer. The edges are typed relationships between them: this decision supersedes that one, this person owns that project, this bug blocks that release.
You build it because retrieval by similarity keeps failing you. Vector search finds text that reads like your question. It cannot follow a chain. Ask which decisions are now dead because of a call made in March and similarity search returns three notes that mention March.
A knowledge graph answers that by walking edges. The value is the walk, not the storage.
This is the definition with the longer history. Knowledge graphs predate language models by decades. What changed in 2026 is that the graph stopped being a database problem and became a retrieval problem, which is why GraphRAG turned into a common pattern rather than a specialist one.
Definition two: a graph of how work moves
In this version, the nodes are workers. An agent, a tool, an evaluator, a human approval step. The edges are routes: after this step, go there, unless the check fails, in which case go back.
You build it because a single agent loop stopped being enough. One agent with a long prompt and twelve tools works until it does not, and when it breaks you cannot say where. Turning the loop into an explicit graph gives you named steps, typed transitions, and a place to put a retry.
This is the definition that showed up loudly in July. It is close to what workflow engines have done for years, and several writers in this camp say so themselves. That does not make it empty. The new part is that the nodes are non-deterministic, so the edges carry more weight than they used to.
Why one term ended up with two meanings
Two groups needed a word in the same year.
The retrieval people had a problem with knowledge: the model cannot find what it needs, so it makes something up. They reached for graphs to make knowledge walkable.
The orchestration people had a problem with control: the model does the wrong thing in the wrong order, so nobody can debug it. They reached for graphs to make control explicit.
Both problems get solved by drawing nodes and edges. So both got called graph engineering. Nobody did anything wrong here. New fields collide on vocabulary before they settle, and this one is still being settled in public. The pieces arguing for the second meaning are dated July and August of this year.
The cost is not linguistic. The cost is that a builder reads the wrong article, recognizes the shape of the diagram, and starts building.
The test: four questions
Answer these before you build anything. They take five minutes.
1. When it fails, is the output wrong or is the path wrong?
Wrong output means the system had bad or missing information. That is a knowledge problem. Wrong path means the system had the information and did the wrong thing with it. That is a topology problem.
Read your last ten failures and sort them into those two piles. The bigger pile picks your definition.
2. Does it fail the same way twice?
Run the failing case again. If it fails identically, something in what the system knows is wrong, and it will be wrong every time. If it fails differently, or works on the second run, the problem is in how the work moved: a timeout, an order, a tool that returned early.
Repeatable points at knowledge. Variable points at topology. This is the fastest of the four and most people never run it.
3. Which path can you not draw today?
Take one real failure. Try to draw the route the answer took through your data. Then draw the route the run took through your code.
Whichever one you cannot draw is the one you have not engineered yet.
4. What happens if you double one thing?
Double your documents. If quality drops, your problem is knowledge. Double your steps or your tools. If reliability drops, your problem is topology.
Most systems eventually need both. Almost nobody needs both first.
The same failure, run through the test
An agent answers questions about your own project history. Someone asks why a library got dropped last quarter. It returns a confident answer citing the document that argued for keeping it, because a later decision reversed that one and nothing in your store says so.
Output is wrong, not path. It fails the same way every time. You can draw the route the run took through your code and you cannot draw the route the answer took through your data. Double the documents and it gets worse.
Four for four on the knowledge side. The fix is one edge: the newer decision points at the older one and says it replaced it. No amount of orchestration would have helped.
Now change one detail. The agent finds the reversal, calls a summarizing tool that truncates it, and answers from half a decision with no error raised. Same question, different answer on a rerun, and you cannot say why the run continued after a short read. That is topology, and the fix is also one edge, this time a route: after that tool, verify, and stop if the check fails.
What each mistake costs
Building the wrong graph is not a small detour. Both mistakes are expensive in the same specific way: you get a working system that does not touch your failure.
Building a knowledge graph when the problem was topology. You spend weeks on an ontology. Entity resolution eats another week, because deciding that two names are the same person is genuinely hard. You ship it. Retrieval gets sharper. Your agent still calls the wrong tool at step four and still cannot recover from a timeout, because none of that was ever about knowing things.
Building an agent graph when the problem was knowledge. You split one loop into nine nodes with typed edges and a state schema. Every run is now traceable. You can see exactly where it went. It goes to the right node, retrieves the wrong context, and produces a confident wrong answer with a beautiful trace attached.
The second mistake is worse, because observability feels like progress. You can watch the failure in high definition for a month before admitting it never moved.
Where the two actually meet
They meet at state.
A knowledge graph is state at rest: what is true, how it connects, what replaced what. An agent graph is state in motion: what this run has done, what it holds now, where it can go next.
That is why the same drawing works for both, and why the confusion was inevitable.
In my own system the split is literal. The vault is the knowledge graph. Edges live in frontmatter as typed fields, so a machine reads them without parsing prose, and a superseded note points at the note that replaced it instead of quietly disagreeing with it. I wrote up the five steps I use to keep those edges honest separately.
The agent side is deliberately thin. A handful of scheduled agents, each with one narrow job, and nothing orchestrating between them. That is still a topology decision, just a very small one, because my failures were almost all knowledge failures.
The repo that runs it is obsidian-second-brain, MIT licensed, about 3,900 stars as of this week. Six months of running it produced the same lesson the test above encodes: I built structure where the failures were, and left the other side small until it earned the work.
What I would tell you if you only read one line
Do not pick the definition that matches the article you found. Pick the one that matches your last ten failures.
The term will settle eventually. Your rebuild will not un-happen.
Frequently asked questions
What is graph engineering?
Designing the graph structure a language model system depends on. As of 2026 the word covers two structures: a graph of what the system knows (entities and typed relationships) and a graph of how the system works (agents, tools, and routes between them).
Is graph engineering the same as GraphRAG?
No. GraphRAG is one retrieval pattern that walks a knowledge graph and combines it with vector search. Graph engineering in the knowledge sense is the design work that makes such a graph worth walking. GraphRAG is a consumer of it.
Is graph engineering just workflow orchestration with a new name?
In the agent-topology sense, it borrows heavily from workflow engines and the people writing about it usually say so. The difference is that the nodes are non-deterministic, so edges carry retries, checks, and stopping rules that a deterministic pipeline never needed.
Do I need a graph database to do graph engineering?
No. My knowledge graph is markdown files with typed fields in frontmatter. A graph database earns its place when traversal is your bottleneck at scale, not when you are figuring out which edges matter.
How do I know which definition applies to my project?
Sort your last ten failures into wrong-output and wrong-path piles. Wrong output points at knowledge. Wrong path points at topology. The four questions in this post do this in more detail.
Can a system need both kinds of graph?
Yes, and mature systems usually do. Almost none need both at the start. Build the side your failures live on, keep the other side to a few rules, and let it grow when it earns the work.
Key takeaways
Graph engineering has two live definitions in 2026: a graph of what the system knows, and a graph of how work moves through agents.
Knowledge graphs fix wrong answers. Agent graphs fix wrong steps. The distinction is what your failures look like, not what your stack looks like.
Sorting your last ten failures into wrong-output and wrong-path piles picks your definition faster than any article can.
The expensive mistake is an agent graph built for a knowledge failure, because full traceability feels like progress while the failure sits untouched.
Both graphs are about state, one at rest and one in motion, which is why the same diagram fits both and why the term split in the first place.
Build the side where your failures live, keep the other side to a few rules, and let it grow when it earns the work.
Further reading
What is graph engineering? A field guide for builders - the definition post this one builds on.
How to do graph engineering in a markdown vault - the five steps, with the edge taxonomy I use.
Karpathy’s LLM Wiki v2: what to keep, what to skip - where the knowledge-graph side of my vault came from.
GraphRAG in its original form: the Microsoft Research paper From local to global and the project documentation.
The agent-topology camp, in their own words: Graph engineering for AI agents and a complete guide in LangGraph.
About the author
Eugeniu Ghelbur builds production AI agent systems and the tooling around them. He maintains obsidian-second-brain, an open-source Claude Code skill that runs an Obsidian vault as a living knowledge system, starred by over 3,900 developers on GitHub and MIT licensed. He writes The AI Operator, where this post first appeared.