Graph engineering for enterprise AI: knowledge graphs, GraphRAG and context graphs

Graph engineering is the discipline of modelling your enterprise as entities and relationships so AI systems can retrieve structure, not just similar text. Use a knowledge graph when answers depend on relationships across systems, add GraphRAG when questions are multi-hop or thematic, and assemble a per-request context graph so every model call carries the entities, permissions and provenance that justify its answer.

Most enterprise AI programmes hit the same wall. Chunk-and-embed retrieval answers the easy questions well, then fails on the ones that matter: "which suppliers are exposed if this component is delayed?", "what changed between the approved design and the site instruction?", "which of my accounts share this risk factor?" Those answers do not live in a single paragraph. They live in the relationships between records that are scattered across an ERP, a document store, a ticketing system and a spreadsheet somebody guards personally.

Graph engineering is how you close that gap. It treats the connective tissue of the business—entities, relationships, hierarchies, events and their provenance—as a first-class engineering artefact, versioned and tested like code. In 2026 this is no longer a research topic: retrieval frameworks, managed graph databases and agent runtimes all assume some form of structured context. The differentiator is no longer whether you can build a graph; it is whether you build one narrow enough to maintain and rich enough to answer real questions.

What graph engineering actually means

A knowledge graph is a curated store of typed entities (customer, asset, contract, work order) and typed relationships between them (supplies, supersedes, reports-to, caused-by). Its value comes from three properties that flat text indexes lack: identity, because one real-world thing has one node no matter how many systems mention it; traversal, because you can follow relationships to arbitrary depth; and constraint, because the schema tells you which connections are meaningful and which are nonsense.

Graph engineering is the practice around that store. It covers ontology design, ingestion and change data capture, entity resolution, edge provenance, query design, evaluation, and the operational work of keeping a live graph consistent while source systems keep moving. The modelling language matters less than the discipline—property graphs queried with Cypher-style languages, the ISO-standardised GQL, and RDF with SKOS-style vocabularies for taxonomy governance all work, and the practical choice usually follows your team's existing skills and platform.

GraphRAG: what it adds over vector-only retrieval

GraphRAG is a family of retrieval patterns that use a graph to decide what context a language model sees. Microsoft's open-source GraphRAG project popularised one influential variant: extract an entity graph from a document corpus with an LLM, cluster it into a community hierarchy, pre-summarise each community, then answer broad questions from those summaries instead of from raw chunks. That is why GraphRAG is strong at global or thematic questions—"what are the recurring causes of cost overrun across these 400 project reports?"—where no single chunk contains the answer and top-k similarity search returns 20 near-duplicates.

The second variant, more common in enterprise systems, starts from a curated operational graph rather than an extracted one. You find candidate entities with vector or keyword search, then traverse the graph a bounded number of hops to gather the neighbourhood, and pass both the structured facts and the linked source snippets to the model. Neo4j's GraphRAG retriever documentation is a useful reference for how these retrievers compose vector search with graph expansion, and the same hybrid shape appears in managed platforms—Google Cloud's Spanner Graph, for instance, exposes graph traversal alongside relational and vector queries in one operational database, which removes a synchronisation problem many teams underestimate.

Both variants buy you the same three things: fewer hallucinated joins, because relationships are asserted rather than inferred from adjacency in text; explainable answers, because the traversal path is itself the citation; and tighter prompts, because a well-scoped subgraph is dramatically smaller than the text needed to imply it.

A reference architecture that survives production

The architectures that hold up in production separate five concerns cleanly. Treat these as layers, not products—several can live in one platform.

Ingestion and change capture. Stream from systems of record rather than re-crawling nightly. Every node and edge carries source system, source record ID, extraction timestamp and confidence. If you cannot answer "where did this edge come from?", you cannot defend the answer built on it.
Identity and entity resolution. This is where most graph projects succeed or fail. Use deterministic keys where they exist, blocking plus similarity scoring where they do not, and keep merges reversible with an audit trail. Store rejected candidate matches too—they are your best evaluation set.
Ontology and semantic layer. Start with the 10–20 entity types and 20–40 relationship types your priority questions actually need. Version the schema, require a migration for changes, and keep definitions in the same repository as the code so a term means one thing across teams.
Retrieval and context assembly. A retrieval service that owns hybrid search, bounded traversal (depth, fan-out and token budgets), permission filtering and snippet selection. Its output is the context graph: the small, per-request slice of entities, edges, source excerpts and access decisions handed to the model. Make it a returnable object, not a string, so you can log, replay and diff it.
Evaluation and observability. A frozen question set with expected entities and expected paths, run on every schema or prompt change. Track answer accuracy, retrieval precision, path validity, unresolved-entity rate and cost per query—not just user thumbs.

Two design rules save the most pain later. First, filter permissions during traversal, never after generation: if a user cannot see a node, that node must never enter the context graph. Second, keep the graph as the index and the source systems as the truth—store IDs, pointers and derived relationships in the graph, and fetch sensitive payloads at query time so you are not maintaining a shadow copy of regulated data.

Trade-offs to decide before you build

Graphs are not free, and the honest failure mode is an elegant ontology nobody can keep current. Weigh these deliberately.

Extracted versus curated graphs. LLM extraction gives fast coverage over documents but noisy, drifting types; curated graphs give precision and stable semantics at the cost of modelling effort. Extraction suits exploratory and thematic corpora; curation suits anything feeding a decision or a regulator.
Indexing cost versus query cost. Community-summary GraphRAG front-loads significant LLM spend at index time and re-incurs it as the corpus changes; traversal-first designs are cheap to index and heavier per query. Estimate both against your real refresh cadence, not a one-off backfill.
Freshness versus consistency. Streaming updates keep answers current but expose partially resolved entities; batch rebuilds are consistent but stale. Most teams land on streaming edges with scheduled resolution passes, and label freshness in the answer.
Schema depth versus maintainability. Every added relationship type is a permanent maintenance obligation across ingestion, resolution, retrieval and tests. Add a type only when a question you have committed to answering cannot be answered without it.
Specialised graph store versus your existing database. A dedicated graph engine wins on deep traversal and expressiveness; keeping graph, relational and vector data in one operational store wins on transactional consistency, governance and headcount. For most enterprises, one fewer system to synchronise is worth more than the last increment of traversal performance.
Latency budget. Traversal, permission checks and snippet fetches stack up before the model even starts generating. Set an explicit end-to-end budget early; it constrains hop depth and fan-out more usefully than any style guide.

Where the returns show up first

The strongest early candidates share a shape: high-value questions, relationships that already exist implicitly, and a painful manual workaround. In practice that means supply chain and project delivery exposure analysis, engineering and construction document lineage (which revision supersedes which, and what it changed), customer 360 and entitlement-aware support, incident and root-cause investigation across services, and compliance mapping from control to evidence to owner.

Graph context also changes how agents behave. An agent that can traverse a governed graph plans against real structure instead of guessing at names, and its tool calls become auditable because each step names the entities it touched. That combination—structured context plus logged tool calls—is what makes agentic workflows reviewable enough for regulated environments.

Readiness checklist

Before committing to a graph programme, confirm you can tick most of these. Anything unticked is your first sprint.

You have written down 15–25 real questions the graph must answer, with the expected entities and paths for each.
At least two of those questions provably fail with vector-only retrieval today.
You have named an owner for the ontology and a review path for schema changes.
Each priority source system has a change feed or an agreed extraction cadence.
Entity resolution rules are documented per entity type, with a measured target for precision and recall.
Every edge type carries provenance: source, timestamp, method and confidence.
Access control is enforced inside retrieval, and you have a test proving a restricted user cannot surface a restricted node.
You have a frozen evaluation set in CI, with thresholds that block a release.
Context assembly is logged and replayable for any answer a reviewer questions.
Cost per query and per re-index is instrumented, with an alert on regression.
Freshness expectations are agreed with the business and surfaced in the interface.
There is a documented rollback: a way to revert a merge, a schema version and a bad ingest batch.

Start with one domain, two or three source systems and a deliberately small ontology. Prove the retrieval quality lift on your own questions, instrument it, then expand the graph along the questions that actually get asked—not along the diagram that looked complete on a whiteboard.

Frequently asked questions

Do we need a knowledge graph, or is vector search enough?

Vector search alone is enough when questions map to a single passage of text. You need a graph when answers depend on relationships and structure: multi-hop questions, entity roll-ups across systems, permission-aware retrieval, or anything that must respect a hierarchy such as a bill of materials, org chart or account tree. Most teams end up with both, using vectors to find candidate entities and the graph to expand and constrain the context that reaches the model.

What is the difference between a knowledge graph, GraphRAG and a context graph?

A knowledge graph is the curated store of entities and relationships. GraphRAG is a retrieval pattern that traverses or summarises that graph to assemble grounded context for a language model. A context graph is the runtime slice actually handed to the model or agent for one request, including the entities, edges, source snippets and permission checks that justify the answer.

How long does a first enterprise GraphRAG pilot take?

A focused pilot on one domain and two or three source systems typically takes six to ten weeks: one to two weeks on ontology and question inventory, two to three weeks on ingestion and entity resolution, two weeks on retrieval and evaluation, and the remainder on guardrails and observability. Scope creep in the ontology, not the model, is the usual reason pilots run long.