Make Your AI Agents Predictable With Graph Engineering: The Idea From Neo4j's Talk
Graph engineering, as Neo4j's Zachary Blumenfeld presents it in his AI Engineer talk, gives agents a map of the logic to follow instead of prose instructions. Steps and allowed transitions become a graph, and past decision traces can be distilled into graph-shaped skills. Runs become predictable and auditable, at the cost of flexibility and graph maintenance.
What the talk covers
"Make Your AI Agents Predictable With Graph Engineering" is a talk by Zachary Blumenfeld, an AI research engineer at Neo4j, published on the AI Engineer YouTube channel on November 3, 2026. Its official description opens: "Graph engineering is a new name for an old idea: give agents a map of the logic they should follow, not just a pile of text." It says Blumenfeld explains how graphs make agents more predictable, governable, and portable, shows how to compile skills and past decision traces into graph-shaped skills, and demos a loan-approval agent that follows them.
The chapter list adds the rest of the outline: three types of graphs, Neo4j's knowledge layer, context graphs and agent memory, distilling skills from memory graphs, customer use cases, compiling runs into a graph-shaped skill, and observability on graph branches. This page explains the underlying idea and its trade-offs; it does not reproduce the talk's specific examples.
The problem: skills are prose
Most agent skills today are written instructions. A markdown file says: check the applicant's income, verify identity, compare against policy, escalate if the debt ratio is high. The model reads that text and decides, each run, which steps to take and in what order.
That works until it matters that the agent does the same thing every time. Prose is interpreted, not executed. Two runs on similar inputs can skip different steps, reorder checks, or invent a shortcut. For a coding assistant that is tolerable. For a loan decision, a claims process, or anything an auditor will read, it is not.
The idea: give the agent a map
Graph engineering, as the talk frames it, replaces the pile of text with structure. In practice that means two kinds of graph working together.
A graph of the process
Nodes are steps or decisions. Edges are the transitions allowed between them, each with a condition. At any node, the agent can only move along an outgoing edge. The model still does the judgement inside a step, reading a document, assessing a case, but the shape of the run is fixed by the graph rather than improvised.
A graph of the knowledge
Entities and their relationships, such as an applicant, their accounts, the policy that applies, and similar past cases, stored so the agent can traverse them. This is the territory of knowledge graph RAG: grounding each step in connected facts rather than loose text chunks.
Why graphs make agents predictable, governable, and portable
Those three words come from the talk's description. Here is the mechanism behind each.
- Predictable. The set of possible runs is the set of paths through the graph. You can enumerate them, test each one, and know that the agent cannot take a path that does not exist.
- Governable. Policy becomes edges and conditions a reviewer can read. Changing a rule means changing a node or edge, which can be versioned and approved like code, instead of editing a paragraph and hoping the model reads it the same way.
- Portable. A graph does not depend on one model's reading of a prompt. Swap the model and the process structure stays the same; only the judgement inside steps changes, which is easier to re-evaluate.
Compiling skills and distilling traces
The description names two ways to build these graphs. The first is compiling a written skill into graph form: turning prose steps and conditions into explicit nodes and edges. The second is distilling from memory: recording the decision traces of past runs, which steps were taken, with what inputs, and with what outcome, then extracting the paths that worked into a reusable graph-shaped skill.
Neo4j has written about this second idea elsewhere. Its blog describes decision traces stored in a context graph alongside knowledge and conversation history, so an agent can query what was decided before and why. The appeal is that good behaviour observed in practice becomes a structure the next run follows, rather than an example the model may or may not imitate.
Observability on branches
Once runs follow a graph, monitoring changes. Instead of reading transcripts, you count traffic per branch: how many cases took the escalation path, how often a condition fired, where runs stalled. A sudden shift in branch counts is a signal, whether from changed inputs, a regressed model, or a policy edge that is wrong. That is the kind of observability the talk's chapter on graph branches points at, and it is much cheaper than reviewing free-form traces one by one.
The trade-offs
Structure costs flexibility. An agent bound to a graph cannot handle a case the graph does not anticipate, so every graph needs an explicit off-graph path: stop and escalate to a person. Graphs also need maintenance. When policy changes and the graph does not, the agent follows the old rules perfectly, which is worse than following new rules approximately. Compiling prose into a graph can introduce its own errors, so compiled graphs need review before they govern anything.
Use graph-shaped skills where the process is known, repeated, and audited: approvals, compliance checks, support workflows. Keep open-ended prose skills for exploratory work where variety is the point. And keep retrieval underneath both, because a predictable process still fails if the facts it reasons over are stale.
Frequently asked questions
- What is graph engineering for AI agents?
- In Neo4j's framing, from Zachary Blumenfeld's AI Engineer talk, graph engineering means giving agents a map of the logic they should follow rather than a pile of text. Processes are expressed as graphs of steps and allowed transitions, and knowledge as graphs of connected entities, so agent runs become more predictable, governable, and portable.
- What is a graph-shaped skill?
- A graph-shaped skill is an agent skill expressed as nodes and edges instead of written instructions. Each node is a step or decision, and each edge is a permitted transition with a condition. The model handles judgement within a step, while the graph fixes which steps can follow, so different runs follow the same reviewable paths.
- How is this different from knowledge graph RAG?
- Knowledge graph RAG uses a graph to retrieve connected facts for a model to reason over. Graph engineering, as described in the talk, also uses graphs to constrain behaviour: which steps an agent may take and in what order. The two combine well, with one graph governing the process and another grounding each step in facts.
- What are decision traces?
- Decision traces are records of what an agent did on past runs: the steps it took, the inputs it used, the tools it called, and the outcomes. Neo4j's blog describes storing them in a context graph with knowledge and conversation history. The talk describes distilling such traces into graph-shaped skills that future runs follow.