Graph Engineering for Agents: Explicit Procedures, Memory and Governance

Zachary Blumenfeld of Neo4j defines graph engineering as designing agent work as an explicit graph: nodes do work and edges route state. The name is new, he says, but ideas such as state machines, workflow graphs and knowledge graphs are not.

He distinguishes execution graphs, context graphs and procedural graphs. Execution graphs coordinate runtime work; context graphs connect decisions and traces to domain data; procedural graphs represent steps, routing, validation and escalation in a repeatable process.

Blumenfeld argues that explicit graphs can make behavior more predictable, governable and auditable. A graph stored as an artifact alongside data can also be portable between runtimes, rather than existing only inside one orchestration framework.

He describes a knowledge layer between systems of record and agents. In Neo4j’s approach, this layer connects source data, documents and memory, while protocols and artifacts expose procedures to different agent runtimes.

A context graph can connect short-term conversation history, longer-term entities and decision traces. Neo4j researchers asked whether procedural knowledge in a written skill, its scripts and references could be compiled into a graph of decisions, routes and executable steps.

Blumenfeld says their earlier research found higher task reward when agents followed the compiled graph, including with a smaller model. He notes the results were from earlier experiments and were being updated for newer models.

The team also explored distilling a skill from memory and connecting it to prior decision traces. He says this can preserve provenance, version history and governance, allowing humans to inspect or revise the process and trace where decisions came from.

He gives examples of compliance reporting across multiple data sources and geographic configuration rules. In each case, the proposed graph connects data to the logic needed to interpret it. He notes that customers may use different implementations from the lab project.

The demo concerns a loan decision for a fictional bakery. The agent combines a business plan, past transactions, lending policy and previous decisions. Blumenfeld emphasizes that this is a demo, not a formal research result.

A graph connects those sources and records the agent’s reasoning and tool calls. But repeated runs can take different paths, and confidence claims around approval, denial or escalation are not necessarily calibrated.

The team compiles information from successful runs and policy documentation into a graph-shaped skill represented in YAML, with scripts and supporting assets. The aim is both traceability and a portable description of how to execute the procedure.

A command-line wrapper lets the agent run the compiled procedure. Rather than asking the model to decide every routing step, the system handles much of the policy and routing programmatically.

The demonstrated flow first checks hard policy rules. Cases not automatically decided can go to a decision model, then to report writing or human escalation; the report is checked before completion.

Runs and their individual steps can be stored in the graph. An inspector can show status, decisions and branches taken, helping a reviewer understand what happened and which parts of the procedure were exercised.

In the small demo, Blumenfeld reports that adding a procedure shortened runtime, and using a smaller model with the procedure reduced it further. The displayed table shows different cost outcomes for the same model with and without the procedure; the cheaper-model combination is the one shown as substantially cheaper.

He stresses that the example involved a few runs and directs viewers to the code and resources. The broader proposal is to make procedural logic explicit and inspectable, while keeping it reusable across agent environments.