Knowledge Graphs

Confidence 0.90 · 11 sources · last confirmed 2026-08-20

Knowledge graphs — heterogeneous graphs with typed nodes (entities) and typed edges (relationships) used as deterministic, queryable, updatable substrates for machine reasoning and AI-agent grounding. The data structure is not new — knowledge graphs were popular in industrial search (Google Knowledge Graph, Amazon’s product graph, Facebook Graph API) and academic research (FreeBase, Wikidata, DBpedia) for decades before the LLM era. What changed in 2024–2026 is the role they play: from standalone-search-result-enrichment to deterministic-grounding-layer-for-LLM-agents.

The wiki holds four sources engaging this concept substantively, from four distinct vantages:

• Academic-foundation vantage: Leskovec’s Stanford CS224W lecture (December 2023) — the wiki’s pre-GenAI-era theoretical reference. KG-completion task formulation; shallow-embedding methods (TransE / TransR / DistMult / ComplEx); relation-pattern taxonomy (symmetric / antisymmetric / inverse / composite / 1-to-N); FreeBase scale-and-incompleteness empirical anchor.
• Industrial-OT vantage: Manditereza 2026 (HiveMQ) — knowledge graphs as the semantic foundation for industrial AI agents. Three-tier semantic data layer (semantic model + domain ontologies + knowledge graph); four structural pillars (object types / properties / link types / action types).
• Agentic-memory vantage: Neo4j) — knowledge graphs as the persistent-memory substrate across agent sessions. Linked-list session graph; dream-phase distillation into durable Markdown memories; hooks-as-portable-primitive across harnesses.
• Practical-engineering vantage: Martin 2026 — knowledge graphs as the GraphRAG retrieval substrate for production AI agents. Full ETL pipeline (parsing / chunking / embedding / entity-extraction / relationship-extraction / deduplication / ontology); chunking-strategy taxonomy; SurrealQL hybrid-query mechanics.

Working definition

Composite from the four wiki sources:

• Heterogeneous graph: typed nodes (entities — Leskovec) + typed edges (relationships — Leskovec). The data structure is a heterogeneous graph; knowledge graph is the interpretive label.
• Encodes domain knowledge: “we encode our knowledge about a given domain in this type of graphical form” (Leskovec). Distinguishes a KG from a generic graph by intent, not structure.
• Supports reasoning + retrieval + ML integration: “a knowledge base over which you can reason, over which you can retrieve, and allows you to bring in the knowledge to your machine learning model” (Leskovec).
• In the LLM era — adds deterministic structure on top of vectors (Martin): “LLMs are very good storytellers … but if they don’t have factual data or context, they are just going to hallucinate. … The idea is to put them together — a very good storyteller generating answers, but a very good knowledge graph that as deterministic as possible generates good contexts.”

Why vector-only RAG breaks — what KGs add (SurrealDB 2026)

Martin’s three named failure modes for vector-only RAG at scale:

Failure mode	Mechanism	KG remediation
Context clash	Too many similar-score chunks compete for inclusion; all could be correct but the LLM gets overloaded	Graph relationships trim retrieval to typed-relevant-subgraph only
Context confusion	Retrieved chunks contradict each other; LLM picks the wrong one	Deterministic graph traversal returns the authoritative fact, not a similarity-score nearest neighbour
Dense neighbourhood degradation	Vector space saturated near common topics; many candidates within distance threshold	Graph-trimmed vector search reduces candidate-set size while preserving topical fit

Martin’s structural framing: “adding graph to that helps you trim down the results.” The KG isn’t a replacement for vector search — it’s a constraint on the vector-search-space that adds deterministic-structure-on-top-of-similarity-score-retrieval.

GraphRAG — the unified-query mechanic

SurrealDB 2026’s GraphRAG demonstration:

1. Embed the user prompt as a query vector.
2. Vector-search for nearest chunk(s) in the KG (chunks are vector-embedded nodes).
3. Multi-hop graph traversal from nearest chunks to related entities (typed edges).
4. Combine vector + graph results into the LLM’s context window.
5. (Optional) full-text search overlay for additional precision.
6. LLM generates grounded response.

In SurrealQL, all six steps can be expressed as a single query — “the beauty of having our own SQL-like query language is that we can have all those modalities in a single query.” The wiki’s first single-query-language-for-hybrid-search worked example.

The KG-ETL pipeline as a named discipline (SurrealDB 2026)

Stage	Sub-steps	Strategy choices
Extract	Parsing → Chunking → Embedding → Entity extraction → Relationship extraction	PDF parsing strategies; chunking taxonomy (recursive / structural / semantic / agentic / no-chunking — accuracy vs cost); LLM-driven entity + relationship extraction
Transform	Deduplication → Ontology mapping → Canonicalisation	Merge LLM-extracted entities referring to the same real-world thing; canonical typed-vocabulary for entities and relationships
Load	Insert into the database	Co-locate vector + graph + full-text to avoid stitching-stores operational cost

The pipeline is the practical engineering form of Leskovec’s academic KG-construction question. Leskovec: “how do you bring any structure to this 38,000 different relationships” — ontology design is hard. Martin: chunking, entity-extraction, and relationship-extraction are all LLM-assisted now, lowering the marginal cost of KG construction below the pre-GenAI-era hand-curation cost.

Chunking strategy taxonomy (SurrealDB 2026)

Strategy	Mechanism	Cost	Accuracy
Recursive	Count ~1000 tokens, split, repeat	Cheapest	Lowest — may split mid-concept
Structural	Split at paragraph / heading / page boundaries within token windows	Very cheap	Better than recursive
Semantic	Embed adjacent paragraphs; high similarity → keep together; low similarity → split	Moderate (embedding LLM only)	High — “really really cool, very well balanced”
Agentic	Big-LLM decides chunk boundaries per document	Expensive	Highest potentially; research frontier
No-chunking	Don’t chunk at extraction; let the LLM read the whole doc and chunk on-the-fly during RAG	Very expensive	Highest theoretically; limited by context window

Martin’s production recommendation: “For now, I would suggest you just chunk your data in this extraction step.” Semantic chunking is the practical sweet spot; agentic and no-chunking remain research-frontier as of April 2026.

Decision criteria — when to use a KG (vs vector-only)

Martin’s rule of thumb (SurrealDB 2026):

• Manual-driven Q&A on a single product line → vector-only may suffice.
• Multiple products / domains / use-cases in the same store → graph trimming becomes valuable.
• Decisions / policy-following / complex workflow → KG required.
• Explainability / traceability needed → KG required.
• Dynamic knowledge where future retrievals depend on past decisions → KG required (decisions stored back into the graph for future retrieval).

KG completion task — the canonical academic formulation (Leskovec 2023)

“Given a head and a relation type, predict the missing tails.”

Example: (J.K. Rowling, genre, ?) → Fantasy / Young-Adult Fiction.

The task generalises link-prediction to heterogeneous-relation graphs. The wiki’s GraphRAG-era practitioner sources don’t operate directly on KG completion — they treat the KG as a given and focus on retrieval. But the incompleteness problem the task addresses motivates the LLM-driven entity-extraction stage of the SurrealDB ETL pipeline: real-world KGs are sparse, and LLMs help fill in missing edges at lower cost than human curation.

Shallow-embedding methods and relation-pattern coverage (Leskovec 2023)

Method	Embedding form	Symmetric	Antisymmetric	Inverse	Composite	1-to-N
TransE	h + r ≈ t (Euclidean translation)	✗	✓	✓	✓	✗
TransR	Project entities into relation-specific space, then translate	✓	✓	✓	✗	✓
DistMult	Bilinear scoring (Hadamard product)	✓	✗	✗	✗	✓
ComplEx	Complex-valued embeddings; bilinear with conjugate	✓	✓	✓	✗	✓

The matrix is the canonical pedagogical artifact of the shallow-embedding KG literature: no single method covers all relation patterns. The pattern taxonomy is wiki-load-bearing — it transfers to other contexts where typed-relationship reasoning matters (LLM-driven relationship-extraction in GraphRAG ETL; multi-hop traversal semantics in agentic RAG).

Knowledge graphs in the LLM-era agentic stack

The four wiki sources address KGs at different layers of the agentic stack:

Layer	Source	KG role
Foundation theory	Leskovec 2023	Mathematical formulation of the construct (heterogeneous graph; KG completion; shallow embeddings)
Industrial reasoning substrate	Manditereza 2026	Three-tier semantic data layer underlying industrial AI agents (OT/IT convergence)
Agentic memory	Bratanic 2026	Persistent memory across agent sessions (linked-list session graph + dream-phase distillation into Markdown)
GraphRAG retrieval	SurrealDB 2026	Deterministic-grounding-substrate for production RAG (vector + graph in one query)

The KG construct is maximally polymorphic: same data structure, four distinct uses across the agentic stack. This is structurally analogous to how MQTT became a polymorphic primitive across industrial protocols (Manditereza 2026’s unified namespace) — the right data structure adopted in multiple layers compounds organisational leverage.

Cross-source positioning

• Knowledge graphs are not new. Both Leskovec (academic, 2023) and Martin (practical, 2026) explicitly anchor the construct historically — “this became very popular a couple of decades ago already and was very popular in the Google search engine” (Martin). The GenAI-era story is adoption-curve compression, not invention.
• Convergence with agent-harness: KGs are one of the persistent-context substrates the harness reads from. Specifically, they sit in Chatterjee’s Context layer (assembling the right context per request) and feed Chatterjee’s Compounding layer (telemetry-feeds-learning) when used as agent memory.
• Convergence with Hu 2026’s queryable-organization: Hu’s “the whole organization should be legible to AI” operates on the same make-the-substrate-legible-and-queryable principle as Martin’s “the graph is a representation of your knowledge.” At company scale (Hu) and at application scale (Martin) the same architectural choice repeats.
• The LLM-driven entity-extraction inversion: pre-GenAI-era, KGs were expensive to build (hand-curation; ontology engineers). LLMs invert that economics — “chunks, concepts, and probably companies are things that are going to be inferred by an LLM” (Martin). The KG-construction-cost-curve drops by ~1-2 orders of magnitude.

KG-as-attention-direction (Nodus Labs / InfraNodus, April 2026)

The wiki’s prior KG sources (SurrealDB, Manditereza, Leskovec, Bratanic) frame KGs as retrieval substrates (graph-traversal supplements or replaces vector similarity). InfraNodus introduces a second use mode for KGs in agent workflows: attention direction.

The mechanism: compute clusters and cluster-pair gaps from concept-page co-occurrence; emit a gap-prompt (structured representation of two disconnected clusters + the densest source extracts from each); paste the gap-prompt back to the LLM and ask it to generate cluster-bridging insights using the underlying source documents. “I point the LLM’s attention to the gap that exists. I provide the underlying structure. I give it some context.” The KG is not retrieving anything; it is telling the LLM where in its existing context to look harder.

This complements rather than replaces KG-as-retrieval. A mature stack carries both: graph-traversal for deterministic retrieval (Martin) + gap-analysis for non-generic ideation (Paranyushkin / InfraNodus).

Semantics as an agent requirement: the data-strategy vantage ( Sydney 2026)

The AWS data-strategy keynote arrives at the knowledge-graph construction story from the agent-readiness angle: one of the three things agents need from data is semantics — the relationships between entities (alongside machine-readable structure and memory). The recipe is the LLM-entity-extraction pipeline this page already documents: “extract the entities from unstructured data — people, places, time — and then find the associations between them,” visualised as a rotatable cube where changing perspective surfaces different relationships (cats/dogs vs “AWS and Gartner connected because they’re both talking about cloud strategy”). The framing’s contribution is motivational: traditional data gives the what; agents demand the why, and “the more why we can give it, the more autonomous we can permit these agents to be” — a crisp business case for KG-as-agent-substrate that complements the page’s SurrealDB engineering treatment.

Semantic layer versus context layer — and a warning about the word ontology ( MotherDuck, July 2026 + Stanford CS547, July 2026)

Bev Turnbaugh draws a distinction this page needs and has not previously stated cleanly, because the two are “conflated quite a bit”:

Layer	Contents
Semantic layer	”Pretty cut and dried — your schema, your joins, your table and column annotations.”
Context layer	”A whole different animal — your definitions of business terms. It documents specific business knowledge.”

Her test for what belongs in the second is the onboarding conversation a new hire has: don’t include that account, that company has this problem; we have an exception for that one. “Where do you codify that?” The failure without it is silent rather than loud — an agent lacking your definitions “guesses. They don’t call it guessing… they infer” — which is precisely the failure a well-formed schema cannot prevent.

Three structural points travel beyond her product. Standards support is not adoption: the Open Semantic Interchange was finalised in Q1 2026 with “support across 50-plus platforms — but that’s support… and then the vendors go off and build their own product with their own specifications.” The Iceberg parallel: the property worth wanting is that the layer “separates what a metric means from where it is run,” and she catches practitioners who chose Iceberg for vendor independence simultaneously coupling their semantics to an ETL vendor. And invocation beats authoring: context that must be remembered to be used will not be used — “you have to have a way that forces your LLM to use those skills” — which is why she treats automatic surfacing when an agent touches the relevant data as the design problem, not the authoring format.

Nava Haghighi supplies a caution that belongs on this page specifically. She opens by warning that ontology means something different in computer science than in her usage, and asks listeners to hold their existing definition aside: hers is “the boundaries of what we allow ourselves to talk or think about,” in the plural. The relevance is not terminological pedantry — it is that a knowledge graph or semantic layer is an ontological commitment in her sense, and “what ontological assumptions get built into systems… risk becoming everyone’s reality.” Her design implication is that categories should be able to change: merging and splitting, hierarchies and nesting, carrying the traces of past boundary decisions, and “algorithmic support of living classifications — forking, comparing, facilitating progress beyond focusing on an end state to allow the evolution of categories.”

The ontology as a digital twin of the operating model ( McKinsey, August 2026 + Toyota via LangChain, August 2026)

Two sources a day apart supply the strategy-consulting argument for building the artifact Turnbaugh describes from the data-platform side, and a target-firm instance of someone doing it.

Banholzer’s version is the most senior articulation of the case the wiki holds. Asked how a company should track advantage holistically, he lands on encoding it: firms are “really think[ing] about this idea of a semantic layer, or what us and others have called an ontology, to think through how do you really codify what makes your business unique and special.” What he wants encoded is decision structure, not documentation:

“If your advantage is how you manage your supply chain, there are real decisions you probably do make in terms of which plant gets allocated which resource, how you do S&OP planning, how you prioritise which customers… how do you map the connections of how decisions flow through the organisation — what people take what decision to do what, what asset moves what resource from one place to another. There are ways to map that in a digital way. Almost think about it as a digital twin to your operating model.”

Three claims for the artifact, each distinct from the retrieval-quality argument this page usually carries. It is itself hard to replicate, so building it is a competitive-advantage move rather than an IT project. It functions as agent infrastructure — “it creates the railroad tracks that underpin how different AI agents can navigate… to prevent hallucination,” and supplies “the right guardrails for when you do advanced analytics.” And it answers the talent cliff: “a lot of great people who are retiring soon — how do you encode their knowledge into [the system] while you also train the next generation?” He closes by tying it to extensibility: “if you have this, it’s easy to apply that agent to a new market, a new industry.”

Toyota is the instance. Ravi Chandu Ummadisetti describes a central Enterprise AI group authoring curated skills per business function — “especially in terms of branding, or in terms of the research, or in terms of the manufacturing, in terms of the supply chain” — supplied to agents as input: “that way, we are trying to feed in the institutional knowledge that we have at Toyota.” Note what this is not: not a graph database, not an ontology in the formal-semantics sense, but per-function prose artifacts authored centrally and consumed by agents. Held against Banholzer’s decision-flow framing and Turnbaugh’s guides-beside-the-tables, the corpus now has three quite different implementations of the same intent, which is worth noting precisely because they do not agree on form.

The open question this sharpens. All three sources assert that codified institutional knowledge is the differentiator; none measures it. There is no evidence in the wiki on how much of an agent’s error rate a context layer actually removes, how such artifacts decay, or who maintains them once the authoring push ends — and Toyota’s testimonial, being vendor-produced marketing with no numbers, cannot supply it.

The “company brain” — codification argued from the SOP-versus-practice gap ( YC, August 2026)

A fifth vantage on the layer this page tracks, and the one that argues most directly about why the codification is hard rather than what form it should take.

Blomfield’s definition of the construct, borrowing Jack Dorsey’s phrasing: “in a conventional company, intelligence is spread throughout the people and the hierarchy routes it. In this new model, intelligence lives in the system.” He flags the term as already worn out — “it got very very popular about six weeks ago and as of two weeks ago I see people in the audience with company brain written on a t-shirt” — and then gives it substance via the gap between documented and actual practice:

“Lots of companies try and write down standard operating procedures — the way things should be done. But then when you actually observe people, how they actually do the job, they’re like, oh, well, in this edge case really I should do this other thing. And there’s a lot of stuff in people’s heads that, if it weren’t in people’s heads and it was actually written down, you’d get a lot of value out of it.”

The mechanism he proposes is mining the gap rather than authoring against it, and YC’s own worked example is the most concrete instance of that in the corpus. YC’s internal user manual — “written over the last 15 years, like 500 pages long, and a lot of it was very very good like 5 years ago, and then AI happened, and honestly a bunch of the advice is just not relevant anymore” — was not rewritten by hand. Instead: record office hours (3,000–4,000 hours accumulated in six months), transcribe, “mine all of the advice we actually give in office hours and then use that to rewrite the user manual… so when the advice changes, the AI will see what the humans are saying, extract the insight, and just rewrite the user manual and push it.” The manual then becomes queryable by an advice agent that can answer “not just Tom’s answer, but here’s how [another partner] would answer it.”

His claim about the composite is stronger than anything else in the cluster and completely unevidenced: “I think you can actually get superhuman advice from this thing, because it’s able to recall perfectly and access the intelligence of 16 partners, not just one with fallible memory.”

Where this sits against the other four. The wiki now holds five sources naming the data-and-knowledge layer as the binding constraint — Turnbaugh’s guides-beside-the-tables, Ng’s agent-ready data, Banholzer’s ontology-as-digital-twin, Toyota’s per-function curated skills, and now Blomfield’s mined transcripts. They still do not agree on form (graph, guides, prose skills, mined recordings), and Blomfield sharpens the disagreement in a useful direction: the other four all assume the knowledge can be authored, and his premise is that the valuable part is precisely the part nobody writes down. His prescriptions follow from that premise — transcribe every meeting, ban Slack DMs, “every action needs to create an artifact… otherwise it basically didn’t happen to the AI.”

And the shared gap holds. None of the five measures anything: there is still no evidence in the wiki on how much error a context layer removes, how such artifacts decay, or who maintains them once the authoring push ends. Blomfield’s self-rewriting manual is the first of the five that even proposes a maintenance mechanism, and he offers no assessment of whether the rewritten manual is any good.

Related concepts

Related concepts

• agent-harness — KGs are one of the persistent-context substrates the harness reads. The Context + Compounding layers in Chatterjee’s 4-layer model are where KG retrieval lives.
• agentic-engineering — knowledge-graph-aware retrieval is one of the operational disciplines an agentic engineer needs.
• industrial-ai-agents — KGs are load-bearing in industrial-OT settings (Manditereza); see that page for the OT-specific framing.
• generative-ai — the LLM-era is what gave KGs their second life as agent-grounding substrates.
• foundation-models — LLMs drive KG entity-extraction and relationship-extraction in the modern ETL pipeline.

Open questions

• GraphRAG benchmarks — Martin claims qualitative improvements over vector-only RAG; empirical benchmarks (which KG-RAG architectures, on which corpora, with which retrieval metrics) would substantiate. Open primary-source target.
• Ontology design as a discipline — both Leskovec and Martin name ontology design as load-bearing but neither details the how. Worth tracking primary sources on ontology-as-engineering-discipline.
• The chunking-strategy decision frontier — Martin’s recommendation is “semantic chunking is the practical sweet spot.” As LLM costs drop, when does agentic or no-chunking become production-ready? Open empirical question.
• KG-embedding methods in the LLM era — TransE / TransR / DistMult / ComplEx (Leskovec) were designed for static KGs. Do they transfer to dynamic LLM-populated KGs, or does the LLM era favour different embedding architectures? Open primary-source target.
• The KG vs vector-only decision — Martin’s rule of thumb is practitioner-prescriptive. A controlled comparison (same corpus, same questions, both architectures, measured outcome) would let the wiki engage the tradeoff empirically.
• GraphRAG-vs-classical-KG-embedding — production deployments of GraphRAG (SurrealDB / Neo4j / others) vs classical KG-embedding completion (TransE family). Different paradigms; comparative evaluation an open question.

Debates and supersession

None substantive yet — the four wiki sources are aligned in framing. The construct itself is decades old (Leskovec) and well-established; the LLM-era re-adoption is what’s recent (Martin / Manditereza / Bratanic) and the four sources converge rather than contradict.