Make Your AI Agents Predictable With Graph Engineering - Zachary Blumenfeld, Neo4j
A walkthrough of graph engineering, the practice of expressing agent logic as an explicit graph of nodes and routed state. It covers execution, context, and procedural graphs, how skills and decision traces can be compiled into portable graph-shaped skills, and a loan-approval demo showing gains in predictability, governance, and cost.
Graph engineering is the practice of designing agent work as an explicit graph, where nodes do the work and edges route state between them. The name is new, but the underlying mechanisms (state machines, workflow graphs, knowledge graphs) have long been standard in computer science. What has changed is how they are applied to agents. The core idea is to give an agent a map of the logic it should follow, not a pile of text instructions.
Three kinds of graphs
This view distinguishes three overlapping graph types:
- Execution graphs are the workflow graphs that run inside an agent harness, with routers and agents as nodes. Frameworks such as LangGraph, ADK, and Anthropic’s multi-agent research system fit here.
- Context graphs hold decision traces, which are records of what happened and how it connects to other data in a domain.
- Procedural graphs express a skill or procedural knowledge as a graph. Their steps may not be agents at all. They can be decision models, escalation checks, validation steps, or calls to different scripts.
The talk focuses on the last two because they receive little attention. Understood well, they reproduce much of what the execution graph does, but in a more portable and efficient form.
Why graphs help agents
Graphs offer three benefits. The first is predictability: constraining the path an agent takes keeps its answers accurate on a given task. The second is governance: an explicit graph can be controlled, guided, and audited, so you can see what the agent did and improve it next time. The third is portability: a graph stored in a knowledge layer, rather than living only in a runtime, can move between runtimes. That gives interoperability and a simpler stack.
Neo4j’s knowledge layer
Neo4j’s approach places a knowledge layer between systems of record (Databricks, BigQuery, Snowflake, documentation, and markdown note collections such as Obsidian) and the agents that use them. Above the core database and analytics sits an agentic memory layer. Data from many sources is loaded into the graph, and standard protocols and artifacts stored there let any agent or runtime execute a graph-engineered process.
The context graph combines several kinds of memory: short-term memory (conversation history), long-term memory (entities extracted from conversations or data), and reasoning or decision traces.
Compiling skills and memory into graphs
The research started at the level of individual skills. A workshop paper asked whether procedural knowledge, whether from past decisions or from a skill file with its scripts, references, and assets, could be compiled into a graph. The method turns written material into a graph structure whose nodes represent decisions, routing points, and scripts to execute. When the agent was forced to traverse that graph, task reward improved across diverse problems in physics, computer science, and security, and a smaller model could be used.
A colleague on the labs team extended the idea to memory. A skill can be distilled from the context graph and stay connected to past decision traces and underlying data. This keeps the performance gains and adds provenance for every step, along with versioning, tracking, and the ability to assess drift over time. Neo4j’s Agent Memory service is the reference architecture, and a human can inspect and edit the resulting graph. Because the skill is now a portable artifact, any harness that can read it can run the graph.
Customer use cases
Consultancies working with asset managers apply graphs to compliance. One example is audit reports that draw on several sources and must resolve entities with different ticker symbols and names across databases. Uber uses configuration graphs for compliance and regulatory rules, which vary by geography and are scattered across a sprawl of microservices. In both cases, expressing the logic next to the data makes automation both trustworthy and operational.
Demo: a loan-approval agent
The demo asks whether a loan should be approved for a bakery business. The business plan PDF, past transactions from Databricks, lending policy data, and prior decisions are all connected in the graph. The agent traverses them to produce an audit trail and a recommendation quickly. Repeated runs revealed a weakness, though. Decision chains varied in length, nothing enforced an exact path, and approve-or-deny decisions carried confidence scores that were not well calibrated.
To address this, successful runs were compiled into a graph-shaped skill in YAML. The skill includes scripts, assets, the source policy documentation for traceability, and instructions for running it. The graph runs a check of hard rules, then routes to a decision model that selects a risk tier and an outcome. A router decides whether to escalate to human review, the agent writes a report, and a linting loop checks the report. A small CLI wrapper lets the agent invoke the skill, so routing is handled programmatically instead of being re-decided by the model on each run.
Each run is persisted in the graph with timestamps, tool calls, and the branches taken, and an inspector makes these visible. Observability over branches shows which paths were and were not taken, and failures can be examined. This is valuable for governance.
On cost and speed, an unconstrained frontier model was correct almost every time but took about 2.7 minutes. With the procedure compiled and executed through the AIP library, the run time nearly halved. Moving to a smaller model such as Haiku reduced time and cost further. The gains come from offloading routing and policy logic into deterministic scripts and simpler decision models, so the model no longer has to work out the whole process on each run.