Make Your AI Agents Predictable With Graph Engineering - Zachary Blumenfeld, Neo4j

Where should the logic for an agent’s work live? A framework such as LangGraph can put it in the runtime. Nodes do work, and edges carry state to the next node. The machinery is familiar from state machines and workflow graphs. Blumenfeld uses graph engineering to describe a practice that also lets an agent pick up a procedure stored alongside its data.

• Execution graph. What runs next? Agents and routers are nodes in the harness that executes the workflow.
• Context graph. What happened on a particular run? A decision trace connects the steps an agent took to the records involved in that decision.
• Procedural graph. What paths does the task allow? A step can call a script, ask a model for a decision, escalate to a person or validate an output. Many runs can follow the same procedure.

The last two graphs work together. An explicit procedure constrains the choices available to the agent. A trace lets a reviewer inspect which choices it made. Packaging the procedure as a skill also gives it a life outside the original runtime. Another harness that can run the skill can use the same routing logic.

Neo4j places a knowledge layer between agents and their sources. Those sources can include tables in Databricks, BigQuery or Snowflake as well as a collection of Markdown files. The database stores the connected data. Memory tools around it load and retrieve that data, giving different runtimes a common place to find records and the procedures that use them.

A context graph keeps three kinds of memory together. Conversation history preserves the immediate exchange. Entities extracted from conversations or source records supply longer-term memory. Decision traces capture the steps and tool calls the application recorded. With those links, a reviewer can start at a question, find the run it prompted and follow a step back to the entity it used. Neo4j Agent Memory

What changes when a written skill becomes a graph? Neo4j’s workshop research started with a SKILL.md file and its scripts, references and assets. The compiler represented decisions and routing points as nodes and translated some prose instructions into deterministic scripts. Where the agent once had to read a paragraph and work out what to do, a step in the graph could now invoke a particular script.

The experiment required the agent to run the graph. Across tasks in fields including physics, computer science and physical training, the team observed higher overall task reward, including with a smaller model. The result applies to the tasks and models in that study. Experiments with newer models were still under way.

The memory graph offered a second starting point. A successful run already contains examples of decisions and tool calls. Distilling a skill from those traces lets each procedural step retain links to the runs and records it came from. If a tool call changes, a reviewer can inspect its origin, compare versions and decide whether to edit the skill. The Neo4j Agent Memory Service (NAMS) is the reference architecture for this approach.

Two customer examples illustrate why it helps to store logic alongside the data it governs. The teams may use different tooling from the Neo4j Labs project.

• Asset-management audits. An audit report may draw on compliance documents and databases that identify the same entity by different names or ticker symbols. Before applying a rule, the agent has to resolve which records refer to the entity under review. A reviewer can then follow the match behind the report.
• Vehicle eligibility at Uber. Blumenfeld illustrates the configuration problem by asking which rule applies to a car component in a particular area when the relevant data is scattered across microservices. Uber’s case study gives the operational consequence. A driver can pass onboarding with a vehicle that dispatch considers ineligible for the local product, leaving the driver approved but receiving no rides. Linking the two services’ requirements lets a validation check catch the mismatch. Uber’s configuration graph

The loan demo begins with an uploaded business plan and a question about whether to approve a new loan. The plan is a PDF, represented by the orange data in the graph. It connects to past transactions, lending policy and earlier decisions pulled from Databricks. Following those links can uncover a prior loan or an earlier mistake that bears on the application. The agent can explain its answer with a trail back to the records it used.

What happened when the agent ran the review twice? Each conversation has a decision trace with timestamps and tool calls. The two chains differ in length because one run found a precedent. That is a sensible reason for paths to diverge. The difficulty is that the trace explains the divergence only after the fact. The written instructions leave the agent free to choose its route on the next application.

Consider the fork between approving a loan and sending it to a person. An instruction to escalate when uncertain leaves that choice to the agent’s estimate of its own confidence. Here the scores were uncalibrated. A reviewer seeing a high score had little basis for estimating how often an automatic decision at that confidence would be right.

Using the AIP library, the team compiled the successful runs into a graph described in YAML. The skill packages that graph with execution scripts, assets and the source lending policy. The policy gives a reviewer something to check the implementation against. The YAML lets different tools read the same procedure, including the tool that displays its steps as a graph.

A small command-line interface lets the agent invoke the whole skill. Which applications still need a decision model? Scripts check the hard policy rules first. Those checks can approve an application, deny it or leave it open. Only the third case calls the decision model, whose task covers a risk-tier choice, whether there is material exposure, and an approve-or-deny outcome.

A later router handles escalation. A case requiring human review goes to a person. On the other branch, the agent writes a report and the procedure runs the report through a check-and-lint loop. Applications can still follow different paths. The command now applies the routing rules, so the agent can concentrate on the work assigned to it at each step.

Where did judgment enter a particular loan decision? The skill saves each run and its individual steps in the graph. The inspector shows the run’s status, what was approved or denied and which branches it took. A reviewer can distinguish an outcome settled by policy from one that needed the model. Across runs, the same comparison reveals something a collection of decision letters would miss entirely: a branch that the procedure allows but no recorded application has taken.

The live run was still waiting on the network, so the timing comparison came from a few earlier runs. With the larger model working directly over the data graph, the agent answered correctly nearly every time and took 2.7 minutes. Adding the AIP procedure nearly halved that time with the same model. Once scripts handled routing, the team could use the smaller Haiku model for the remaining work, reducing model time and cost further. These were demo runs, so the timings describe this loan task under those conditions.

For the implementation, Blumenfeld points to the code and agent-memory projects on the closing resource slide at 20:01.