The Graph Is the Context

There's a new label doing the rounds: graph engineering. Like every label before it, it's half marketing. But underneath the hype is a real shift, and it's one I've felt in my own systems for a while: the flat context window is running out of road, and the thing that increasingly decides what goes into it is a graph.

Here's the whole idea in one line. If you take nothing else, take this: vector search finds things that sound like your question; a graph finds things that are connected to your answer. That's shorthand, not a law of physics — but it's the right intuition, and the gap between the two is where a lot of AI systems quietly fail.

The ladder: prompt → context → loop → graph

Graph engineering is the newest rung on a ladder the field has been climbing — less a strict timeline than a shifting center of gravity. These overlap and predate their labels; treat this as where the emphasis has moved, not tidy history. Each rung was a real shift in where the leverage lived — and each got briefly crowned “the one skill that matters.”

The word “graph engineering” will get worn out like the three before it. That doesn't make the underlying move fake. It makes it worth understanding before the noise crests.

Why similarity search hits a wall

Vector retrieval turns your text into coordinates and finds the nearest neighbors. It's excellent at “find me stuff like this.” It falls apart when the answer is spread across documents that don't individually resemble your question — the multi-hop problem, and it's everywhere.

Ask your knowledge base: why did we drop Redis for the job queue? Single-shot similarity hands you ten notes that mention Redis — a setup guide, two postmortems, a config snippet — and not one of them is the answer. The answer lives in the path between them: the decision that changed it (ADR-007), the older design it superseded (ADR-003), and the outage that triggered the switch (Incident-142).

Three notes, none of them similar to your question, joined by a causal chain. A graph walks that chain directly, because the connections are already written down. Single-shot similarity can't reconstruct it — it was looking at resemblance, not relationships. (Iterative, multi-hop RAG can chase some of this; it's just doing by repeated guesswork what the graph does by lookup.)

Typed edges are the whole game

The magic isn't “graph.” Systems have had graphs of loosely-linked notes for years. The magic is typed edges. An untyped edge says these two things are related. A typed edge says how: supersedes, depends_on, decided_by, caused, blocks.

That one extra bit — from “related” to “related in this specific way” — lets an agent follow a relationship instead of guess at one. “ADR-007 supersedes ADR-003” is a declared relationship you can act on. “ADR-007 sits near ADR-003 in embedding space” is a similarity signal you still have to interpret. A declared edge can be stale or wrong too — but at least it's a claim you can check, not a proximity you have to squint at.

Treat knowledge as a sack of semantically similar paragraphs and you've stripped out its skeleton, then asked the model to guess the anatomy. Typed edges are the skeleton. It's why the questions that need graphs are the ones with hidden verbs — caused, replaced, depends on, approved, blocked. Those verbs are edges wearing human clothes. And it's why graph engineering isn't “put your data in Neo4j”: the database is the implementation; the ontology is the product. A sloppy ontology inside an expensive graph database is just a nicer-looking pile of mislabeled boxes.

The part nobody puts on the slide: it compounds against you

Here's where the marketing ends and the engineering starts. Graphs are not a free lunch, and the reason is arithmetic. Every hop in a traversal depends on the previous hop being correct — the right entity resolved, the right edge followed. Under the wrong conditions those errors don't add. They multiply.

The surrounding failure modes rhyme with it: a lot of enterprise RAG never reaches production at all; extraction pipelines hallucinate entities and relationships while building the graph in the first place; and multi-hop traversals that flew on a tidy test set can crawl once real fan-out, permissions, and multi-tenant data show up.

So a lot of “our AI hallucinated” incidents are really representation failures in disguise — the retrieval layer handed the model a coin-flip chain and called it “context.” Check the path before you blame the model.

What actually ships: hybrid, not either/or

The pattern that keeps winning in 2026 isn't “replace vectors with graphs.” It's both, behind a router — for the workloads that genuinely mix semantic, relational, and exact-lookup questions. Vector search for find me things like this. Graph traversal for follow the connections. SQL for give me the exact number. A router picks the right tool per question.

The division of labor is the point: the model does what it's genuinely good at — reasoning inside a bounded, well-chosen context — and the graph does what it's good at: holding structure across contexts that no single prompt could fit. The mantra worth stealing from the graph crowd: representation, not prompting, is the leverage. Shape the knowledge right and the prompt gets boring. Boring prompts are the goal.

Concretely: “which runbook covers intermittent checkout timeouts?” leans vector. “what depends on the certificate that expires next week?” leans graph. “how many payments failed yesterday?” leans SQL. “why did failures spike after release 81, and who was affected?” wants all three. One warning if you expose the graph to an agent as a tool — increasingly over the Model Context Protocol (MCP), which standardizes the interface, not the graph semantics: the safe tool isn't run_arbitrary_cypher, it's a narrow capability with typed inputs, a traversal budget, and permission checks. Raw query access is a very fast way to melt the database.

Living graphs: where retrieval and memory start to merge

The frontier is the graph that doesn't sit still. A living graph updates as the agent works — a decision, an artifact, a “we tried X and it broke” can become a node, ideally as a provenance-bearing record. At that point retrieval and memory start sharing one substrate: the thing the agent searches is also where it records what happened, and it grows itself.

The discipline that keeps a living graph from rotting: agent-written edges must stay distinguishable from human-confirmed facts. Source, timestamp, confidence, review state — all first-class. A living graph without governance isn't memory, it's undead knowledge: active, persistent, and no longer attached to the truth.

The direction is credible because the need is structural: agents are being asked to run longer investigations across more tools and more fragmented knowledge, and that demands identities, dependencies, provenance, and causal chains no prompt can manufacture. Analysts are already forecasting graph-based context as a near-default for agent systems and the knowledge-graph market as a fast-growing, multi-billion-dollar category. Treat the specific numbers as momentum signals, not physics — but the vector points where it points.

You're probably already doing this (the cheap version)

Here's the part the enterprise buyer's guides skip, because there's no seven-figure contract in it. If you keep a linked markdown knowledge base — notes that reference each other, [[wikilinks]], a cross-reference discipline — you're already doing proto-graph-engineering. Your wikilinks are edges.

Give them types — a link that means supersedes versus one that means see_also — and you've hand-built the foundation that GraphRAG's expensive entity-extraction pipeline is trying to reconstruct after the fact. Here's the part the platforms don't advertise: in a well-maintained base, human-curated links are usually more precise than machine-extracted ones. You do not need a graph database and a platform contract to start. You need typed links and the discipline to keep them honest — a drum I've been beating for a while.

Concretely, it's just letting your frontmatter carry the edges:

---
type: architecture_decision
status: accepted
supersedes:
  - "[[ADR-003]]"
triggered_by:
  - "[[Incident-142]]"
affects:
  - "[[Job Queue]]"
---

Add a linter that checks the targets exist and the edge types are legal, layer semantic search over the note bodies, and you've got a real hybrid system with Markdown as the inspectable source of truth. And don't reach for the enterprise graph DB because the category sounds important: a sound ontology makes a later migration much easier; a bad one just gives you distributed nonsense.

What to do Monday

1. Treat your knowledge base as a graph to walk, not a pile to search. Start typing your links. caused, supersedes, depends_on will carry you a shocking distance before you need anything fancier.

2. When the agent gets it wrong, count the hops before you touch the prompt. If it walked a five-link chain to get there, it may have been reasoning from a coin flip. Shorten the chain or raise per-hop accuracy first — the model is often not the bug.

3. Go hybrid on purpose. Vectors for resemblance, graph for connection, SQL for facts, a router to choose. Treat any single-tool-solves-everything pitch with suspicion.

4. Measure the chain, not the top-ten. Don't check whether the right document showed up somewhere in the results — check whether every node and edge the answer leaned on was correct. Track per-hop accuracy, unresolved entities, contradictory edges, and the share of answers that can show their evidence path. Twenty correct nodes with provenance beat twenty thousand extracted ghosts.

Most teams don't have a prompting problem — they have a representation problem wearing a prompt-shaped mask. Prompts express intent, context supplies evidence, loops organize action; graphs preserve the structure that makes the evidence navigable. Graph engineering doesn't replace the other three — it completes them.

Ignore the label; it'll wear out like the ones before it. The move under it — from what sounds right to what's actually connected — is the real one, and it's been the missing half of context engineering all along. Build the bones first, and the intelligence has something real to inhabit. The context window was never the whole of knowledge. The graph is how you decide what belongs in it.