Graph Engineering in AI: Agentic Graphs vs Knowledge Graphs

One phrase, two disciplines

If you have ever watched two engineers argue past each other about “graph engineering”, this is usually why: the term has been claimed by two unrelated parts of the AI stack, and both claims are legitimate. One group means control flow — modelling an LLM application as a state machine of nodes and conditional edges. The other means data modelling — representing facts as entities and typed relationships in a graph database so a model can retrieve them precisely.

The clean way to hold both in your head: one governs how the system executes, the other governs what the system knows. They live at different layers, they fail in different ways, and mature systems use both.

Definition 1: agentic graph engineering

Early LLM applications were chains: prompt in, model out, maybe a retrieval step in the middle. Chains are directed acyclic — they run once, front to back. Real work is not like that. A drafting assistant needs to revise. A research agent needs to decide whether it has enough evidence. A support bot needs to escalate. All of those require branching and cycles, which is exactly what a DAG cannot express.

Agentic graph engineering models the application as a graph where nodes are units of work — an LLM call with a specific role, a tool invocation, a deterministic Python function — and edges are the routing rules that decide what runs next. A shared state object flows through the graph, and each node returns an update to it rather than mutating hidden globals.

The three concepts that matter

• State. A typed, shared structure — messages, intermediate artefacts, counters. Reducers define how concurrent node outputs merge, which is what makes parallel branches safe.
• Nodes. Pure-ish functions of state. Keeping them side-effect-light is what makes replay, testing and time-travel debugging possible.
• Conditional edges. A routing function reads state and returns the name of the next node. This is where “agency” actually lives — not inside the prompt, but in the code that interprets the model's output.

const graph = new StateGraph(State)
  .addNode("plan", planner)
  .addNode("write", writer)
  .addNode("review", reviewer)
  .addEdge(START, "plan")
  .addEdge("plan", "write")
  .addEdge("write", "review")
  .addConditionalEdges("review", (s) =>
    s.approved || s.attempts >= 3 ? END : "write"
  )
  .compile({ checkpointer });

The dominant framework is LangGraph, built by the LangChain team precisely for this style. AutoGen and CrewAI approach the same problem from a conversational multi-agent angle: less explicit graph, more emergent coordination. The trade-off is predictability — explicit graphs are easier to reason about and much easier to debug when a production run goes wrong at 2am.

Definition 2: knowledge graph engineering

The second meaning is short for knowledge graph engineering: taking messy, unstructured source material — contracts, wiki pages, incident reports, product catalogues — and representing it as explicit entities connected by explicit relationships, so retrieval can follow facts instead of guessing at semantic similarity.

The unit of storage is a triple: (Rahul)-[:WORKS_AT]->(Google). Nodes carry labels and properties; edges carry a type, a direction, and properties of their own (a SINCE date on an employment edge, a confidence score on an extracted fact).

The pipeline

1. Ontology first. Decide the node labels and edge types you will allow before you ingest anything. A graph without a schema degrades into an unqueryable hairball within weeks.
2. Extraction. Run documents through an LLM with a constrained output schema to pull entities and relations. Constrain hard — free-form extraction invents edge types.
3. Entity resolution. The genuinely hard part. “Google”, “Google LLC” and “Alphabet subsidiary” must collapse into one node, or every traversal silently misses data.
4. Loading and indexing. Write into Neo4j, Amazon Neptune, Memgraph or similar; add full-text and vector indexes on node properties for hybrid entry points.
5. Query at inference. Map the user's question to a traversal (hand-written Cypher templates, or LLM-generated Cypher validated against the schema), then feed the returned subgraph to the model as context.

MATCH (u:Customer {id: $customerId})-[:HAS_ACCOUNT]->(a:Account)
      -[:HAS_INVOICE]->(i:Invoice)-[:PAID_BY]->(p:Payment)
WHERE p.status = 'FAILED'
RETURN i.number, p.failureReason, p.attemptedAt
ORDER BY p.attemptedAt DESC LIMIT 5;

Side-by-side comparison

GraphRAG vs vector RAG

Knowledge graphs matter to AI mostly because of retrieval quality. Vector RAG chunks documents, embeds them, and returns the top-k chunks nearest your query in embedding space. That works beautifully for “what does our refund policy say?” and poorly for “which services owned by teams that report to Priya had incidents last quarter?”. The second question needs joins, and embeddings do not do joins.

In practice the winning pattern is hybrid: use vector or full-text search to find the entry-point nodes, then traverse the graph from there to collect the surrounding subgraph. You get the recall of embeddings and the precision of structure, and the model gets context whose provenance you can display.

How they work together

Consider an AI support agent for a bank. Both meanings of graph engineering show up, at different layers.

1. Control plane. A router node classifies the query and routes to a billing agent or a technical-support agent. A verifier node checks the drafted answer against the retrieved evidence and loops back if it does not hold up.
2. Data plane. When the billing node runs, it does not grep documents. It runs a parameterised Cypher query to trace account → invoice → payment → failure reason, and hands the model a small, exact subgraph.

The separation is worth defending architecturally. The control graph should not know Cypher, and the knowledge graph should not know about agents. Put retrieval behind a tool interface with a typed contract, and both halves stay independently testable.

Where each one goes wrong

Agentic graphs

• Unbounded loops. Every cycle needs a hard attempt counter and a token budget. “The reviewer keeps rejecting” must terminate in a defined failure state.
• State bloat. Appending every intermediate message to shared state grows the context window until cost and latency explode. Summarise or prune at node boundaries.
• Over-decomposition. Six agents where one prompt with two tools would do. Each hop adds latency, cost and a new failure mode.
• Non-deterministic routing. If a router is an LLM, it will occasionally route wrong. Constrain it to an enum, validate the output, and have a default branch.

Knowledge graphs

• Weak entity resolution. Duplicate nodes mean traversals return partial truth — which is worse than no answer, because it looks confident.
• Schema sprawl. LLM-extracted edge types like WORKS_AT, EMPLOYED_BY and WORKS_FOR coexisting is a silent killer. Whitelist the vocabulary.
• Staleness. Facts change. Decide upfront whether edges are versioned or overwritten, and how re-ingestion reconciles conflicts.
• Unvalidated generated queries. Text-to-Cypher must run read-only, against a schema-aware prompt, with a parser check and a timeout.

Which one should you build

Pick by the symptom you actually have.

How to discuss it in an interview

1. Disambiguate first. If someone says “we use graph engineering”, ask whether they mean orchestration or data. Doing this in an interview signals real exposure.
2. Justify the cycle. If you propose an agent graph, name the specific loop it enables and the termination condition. A graph without a cycle is a chain with extra ceremony.
3. Justify the graph database. Say the query shape out loud: “this is a three-hop relational question, so embeddings will miss it.” That is a stronger argument than “graphs are better for context.”
4. Budget the cost. Tokens per run, p95 latency per node, ingestion lag for the graph. Numbers separate people who have run these systems from people who have read about them.
5. Name the failure modes unprompted — loop runaway, state bloat, entity resolution, staleness. It is the fastest way to sound senior.

Worth reading directly: the LangGraph state and edges reference, Neo4j on unifying LLMs and knowledge graphs, and Microsoft Research's GraphRAG write-up. Build one of each at toy scale — a three-node loop and a fifty-node graph — and the distinction stops being terminology and starts being intuition.