Graph engineering: the edge is the product

Everyone can draw circles and arrows.

The difficult bit starts when an arrow has to be correct.

If a product says Alice can view a document because she belongs to a team, that membership edge matters. If a fraud system says two accounts share a device, the relationship matters. If an AI system connects a claim to its source, that link matters too.

It needs a definition, an owner, a source, a time window and a way to be corrected. Otherwise the graph is a tidy-looking collection of rumours.

I use graph engineering to mean the practice of designing, building, evaluating and operating systems where relationships are first-class product data.

That is broader than choosing a graph database. Storage is only one decision. The real work is making the connections trustworthy enough that a product, a person or an AI agent can depend on them.

A useful correction before we go further

Graph engineering is not a standard term with one accepted industry definition.

I reviewed Anthropic's current engineering material because its work is often referenced in discussions like this. Anthropic does not appear to define "graph engineering" as a named discipline. Its relevant term is context engineering: curating the smallest set of high-signal information that gives a model the best chance of completing a task.

A graph can help supply that context, but the two ideas are not the same.

Anthropic's Building effective agents article makes a similar distinction on the execution side. It separates predefined workflows from agents that dynamically choose their own actions, and recommends starting with the simplest system that works.

That advice matters. Teams often reach for a graph because the diagram looks intelligent. The question should be simpler: does the relationship carry information the product needs?

If it does, a graph may be useful. If it does not, a table, search index or ordinary retrieval pipeline may be better.

There are three different graphs hiding in AI conversations

People regularly use the word "graph" while talking about different parts of a system. That causes expensive confusion.

1. The graph can be the knowledge

A knowledge graph stores entities and the relationships between them.

The nodes might be people, companies, documents, services or products. The edges might mean

WORKS_FOR

OWNS

CITES

DEPENDS_ON

CAN_ACCESS

Google's original Knowledge Graph announcement described this as moving from strings to things: understanding an entity and how it connects to other entities. The wider knowledge graph research survey shows why this is a proper engineering discipline. Schema, identity, context, extraction, quality and refinement all matter.

A pile of nodes and

RELATED_TO

2. The graph can be part of retrieval

GraphRAG uses graph structure to help retrieve or summarise information for a language model.

Microsoft's GraphRAG pipeline extracts entities and relationships from source text, detects communities in the resulting graph, creates summaries, and uses those structures to answer questions. Its strongest use case is not simple fact lookup. It is global sense-making across a corpus: themes, patterns and relationships that may be spread over many documents.

Neo4j documents another pattern in its GraphRAG Python guide. Vector search finds a relevant node, then a graph query traverses connected nodes to enrich the context. AWS's GraphRAG Toolkit uses graph traversal and structurally relevant information in its own way.

These approaches are related, but they are not one standard algorithm. "GraphRAG" is a family of retrieval patterns.

3. The graph can be the program

Agent frameworks also use graphs to represent execution.

In LangGraph, nodes perform work and edges decide what happens next. A graph can route a request, call a tool, evaluate the result, loop, ask for human approval or recover from a failure.

That is a control-flow graph. It does not automatically provide a knowledge graph, and it does not improve retrieval by itself.

This is the distinction I would keep pinned above any architecture discussion:

• A knowledge graph represents the domain.
• GraphRAG uses graph structure during retrieval and context assembly.
• An agent graph controls how work moves through a system.

You can combine all three. You should not blur them together.

The GRAPH framework

The useful way to approach graph engineering is to start with the product question and work outward.

G: Ground it in a relationship-dependent question

Write the question the graph must answer.

"Can this user view this file through any group they belong to?"

"Which live services depend on this vulnerable package?"

"Which new accounts are within two reliable hops of confirmed fraud?"

"What themes recur across this complete research library?"

Then describe the path needed to answer it: the starting entity, permitted relationship types, traversal depth, filters, time window, output, freshness and latency.

Neo4j's own modelling guidance recommends starting from priority queries and testing models against real data. That is a better first step than choosing a vendor.

If the important questions do not depend on connections, paths or global structure, stop. You may not need a graph.

R: Resolve identity and relationship semantics

A graph becomes unreliable when identity is vague.

Is Brendan Tack in one source the same person as B. Tack in another? Are two packages with similar names the same dependency? Is a company record a legal entity, a brand or a workspace account?

Every important node needs a stable identifier, source of truth, alias policy, merge and split rules, deletion behaviour and security boundary.

Every important edge needs more than a label. Define:

• its direction and permitted node types;
• when it became valid and when it stopped being valid;
• when the system observed it;
• where the claim came from;
• confidence if it was inferred;
• who owns and updates it.

An edge without provenance or ownership is a rumour with an API.

A: Assemble and assure the graph

A production graph needs a repeatable pipeline.

Capture source changes. Normalise entities. Resolve identity. Attach provenance, time and confidence. Validate constraints. Publish updates. Reconcile with the source systems. Support backfills, corrections and deletion.

For RDF systems, the W3C's SHACL standard defines executable shapes for validating graph data. Property-graph systems can enforce equivalent rules through constraints, pipeline checks and application tests.

LLM-extracted graphs need even more care. Extraction is probabilistic. Microsoft warns that GraphRAG indexing can be expensive and recommends starting small. Its documentation also recommends prompt tuning for the target domain.

Do not let a fluent model turn an uncertain relationship into an authoritative-looking edge.

Track duplicate entities, relationship precision, constraint violations, provenance coverage, freshness lag and the delay between a correction in the source and its removal from the graph.

P: Pick the serving pattern from the workload

Now choose how the product will serve the relationship data.

The answer could be:

• relational tables with explicit adjacency records;
• a search index with relationship facets;
• vector retrieval for local semantic matches;
• a graph database for multi-hop traversal;
• precomputed paths or neighbourhoods;
• a batch graph analytics engine;
• a hybrid of graph, vector and relational systems.

Meta's TAO engineering write-up is a useful reminder that a graph product does not require every part of the stack to look graph-native. The abstraction, caching, consistency and operational behaviour matter as much as the storage label.

Benchmark the ugly cases, not the clean demo: high-degree nodes, missing edges, stale replicas, skewed tenants, deep traversals, bursts and deletion storms.

H: Hold it to evidence

A graph is not successful because it contains a lot of nodes.

Measure four layers separately.

At the product layer, measure whether the graph helps people complete the task: access decisions made correctly, investigations completed faster, risks found or recommendations improved.

At the graph layer, measure identity accuracy, edge accuracy, coverage, freshness, provenance and constraint compliance.

At the system layer, measure latency by traversal depth, visited-node count, ingest lag, hot-node behaviour, cache effectiveness and cost per query.

For AI products, also measure answer correctness, citation coverage, retrieval faithfulness, abstention quality and performance by query type.

This last part matters because ordinary RAG may be better for a direct local question, while GraphRAG may help with global questions across a whole corpus. "Does GraphRAG beat RAG?" is too vague to be a useful evaluation.

Four examples where the edge really is the product

A permissions system connects users, groups, folders and documents. The difficult parts are inheritance, revocation, consistency and speed. Google's Zanzibar paper is the classic large-scale example.

A software dependency graph connects services, repositories, packages, deployments, owners and vulnerabilities. The useful question is not "does this package exist?" It is "which customer-facing deployments are transitively exposed, and who owns them?"

A fraud graph connects accounts, devices, cards, addresses and merchants. Shared IP addresses can create enormous noisy hubs, so confidence, time windows and traversal limits matter.

A research graph connects claims, sources, entities and topics. It can support local questions about one announcement and global questions about themes or contradictions across a library. It can also produce very convincing nonsense if entity resolution and provenance are weak.

The traps are predictable

Most graph failures start before the database is installed.

Teams choose an engine before writing the questions. They use generic edges. They postpone identity resolution. They forget that relationships change over time. They allow unbounded traversal through supernodes. They treat LLM extraction as truth. They create a shadow copy with no owner and no deletion path.

Then they evaluate the final AI answer for fluency instead of checking the entities, paths and source claims underneath it.

A polished answer can still rest on a false merge.

A quick decision test

Before building a graph, answer these:

1. Which product question requires relationships?
2. Which entities have stable identities?
3. What does each traversed edge mean?
4. Who owns and updates it?
5. How are time, provenance and confidence represented?
6. What simpler baseline must the graph beat?
7. How will graph correctness be measured?
8. What traversal, freshness and cost limits apply?
9. How will corrections and deletions propagate?
10. Can the product explain the path behind an answer?

If several answers are "we will figure that out after choosing a graph database", the team is not doing graph engineering yet.

Use a graph when the connection is part of the answer.

Engineer it when the connection has to stay correct.