Graph Engineering Aims to Make AI Agents Predictable, Governable and Portable

Blumenfeld opened by asking the room who had heard the term graph engineering; only a fair number of attendees raised their hands. He noted that Peter Steinberger had posted a tweet earlier in the year that presented graph engineering as a possible evolution beyond prompt engineering and context engineering, and that the term has attracted considerable hype.

He offered his own definition: graph engineering is the practice of designing agent work as an explicit graph, where nodes do work and edges route state between them.

Blumenfeld said the name is new but the mechanisms are not. Computer science has long known about state machines, workflow graphs and knowledge graphs. What is changing, he said, is how these ideas are applied to agents.

Blumenfeld said he thinks of graph engineering in three types. The first is general execution graphs, which are workflow graphs with routers and agents as nodes inside an agent harness. The second is context graphs, which hold decision traces and records of what happened, connected to other data in a domain. The third is procedural graphs, in which a skill or procedural knowledge is expressed as a graph whose steps may be decision models, different agents, escalation decisions or validation steps rather than agents themselves.

He said he would focus on the last two, context and procedural graphs, because he feels they are not discussed enough, and that understanding them can also help with what the execution graph does, in a more portable and efficient way.

Blumenfeld said graph engineering lets agents take on bigger and more complex work. He divided the benefits of a graph for agents into three. Predictability means constraining the path an agent takes so that its answer is accurate for the task. Governance means having an explicit graph that lets people control, guide and audit what the agent does, so they can understand it and improve it next time.

The third benefit, portability, is the one he said he would focus on most. Rather than treating a graph as something that happens inside the runtime, it can be stored and moved between different runtimes within a knowledge layer, giving more interoperability and a simpler stack.

Within a runtime, Blumenfeld said, the graph acts as a piece of orchestration. He named LangGraph, ADK and other agent frameworks as examples that fit this pattern, and said that to a certain extent Anthropic's multi-agent research and some of its work also fits within graph engineering.

He described what Neo4j is defining as a knowledge layer that sits between systems of record that would ordinarily be queried for data, such as Databricks, BigQuery and Snowflake, and places such as documentation or Obsidian markdown files. He said the aim is to create standard protocols and artifacts in that layer, so that a graph engineering process can be made available to any runtime or any agent.

Blumenfeld said Neo4j's core is a database and an analytics layer, with a lot of other AI tooling built on top. He said he would show some of this during the talk, but that he would focus on the top layer, which covers the agentic brain and memory tools that wrap around the database. Data loaded from multiple sources into the database constitutes the knowledge layer, and the extensions and experimental tools he would show hook into it to load data in and out.

Blumenfeld said Neo4j starts from a concept called the context graph, which holds different types of memory. Short-term memory is the conversation history. Long-term memory consists of entities extracted from conversations or from the data. Reasoning or decision traces are stored inside the same structure.

He said this is how Neo4j thinks about the problem, and that the interesting research started not at the level of the whole graph but at the level of individual skills.

Blumenfeld described a paper his team published in a workshop earlier in the year. It asked whether procedural knowledge, whether from past decisions or from a skill, can be compiled down into a graph. The process took written material, often a skill markdown file together with its scripts, references and assets, and moved it into a graph structure. In that structure, nodes represent decisions, routing points and scripts to execute, which are compiled into deterministic scripts.

When the agent was given access to this graph and forced to run it, the speaker said, task reward and performance increased. The experiment was run some time ago with a smaller model, which he said was Sonnet, and he said the team is updating it to the latest models and is now using Haiku. He reported that the overall increase in task reward held across challenging tasks in physics, computer science and security.

Blumenfeld said a colleague on the labs team, Will Loin, took the skill idea and asked whether the same could be done with memory graphs. The context graph can be used to distill a skill that stays connected in the same graph to all past decision traces and data. That gives the performance benefits, along with provenance that traces back from every step, versioning and tracking, and governance over time, including assessing drift and understanding where tool calls come from and their history.

He pointed to Neo4j's agent memory service as the reference architecture, where a person can inspect how this works, edit it and change it. He said the artifacts discussed can be moved around, and that any agent harness able to take the skill can run these graphs.

Blumenfeld said various customers use Neo4j for graph engineering tasks. Consultancies working with other asset managers use it for tough compliance problems, such as writing audit reports from data that comes from multiple sources in a governed and trustworthy way. Such work may involve compliance documentation and entities with different ticker symbols and names in different databases that must be resolved.

He said giving an agent graphs that express the logic required, in addition to the data, allows these tasks to be automated in a trustworthy way. He also cited Uber, which he said uses configuration graphs. He gave the example of driver compliance and regulations that vary greatly by geographic area and come from a sprawl of microservices that must be queried to determine, for each area and each component of a car, what applies.

Blumenfeld introduced a demo he warned would be fairly long and that he would move through quickly. It uses the AIP library he had mentioned to compile a skill from a task that was not well governed and took a long time to run. He said this cut the task's cost by about 100% and then ran it much faster. He described the demo as not a formal research proposal, but said the code is available and transparent.

The example is a loan-approval process. He said such a process typically has many policies that must be followed, a policy document, and a sequence of steps that must be followed exactly. The agent must explain those steps clearly and reach the answer a human reviewer would reach. Because the internet would be slow during the live talk, the run had been preloaded.

The question in the demo was whether to approve a new loan for Rosa's Bakery, based on a business plan uploaded as a PDF. In the graph, the business plan, shown as orange data, connects to data pulled from Databricks, past transactions, lending policy data and past decisions actually made. The agent can crawl this data to find whether the applicant had a previous loan, mistake or event, and then produce an audit trail and a quick resolution. Blumenfeld said this is a good start for resolving data, following policies and understanding how things connect.

He showed a reasoning trace stored in the graph, with timestamped steps and tool calls. He then displayed two decision chains from repeated runs of the same process. They were of different lengths; in one case, he said, the agent found a precedent, meaning something that had happened before. He said the problem is that nothing enforces an exact path when these runs are repeated. Decision steps such as approve, deny or send to a human carry confidence scores, but he said those scores are not calibrated, and he suggested sending some of this to a type-safe model.

Blumenfeld said the runs were successful, although a little inconsistent. He scraped them and compiled the information into a graph-shaped skill, which he said is written in a YAML shape inside the skill. The skill contains scripts, assets and, in some cases, other reference resources, though not for this example. It also includes source documentation on the policy the loan must follow, which he said adds a great deal of material for traceability, along with instructions telling the agent how to run it.

He said that once a skill is in this YAML format, it can be ported into different tooling, including a graph, because it is in a deterministic format.

In the graph view, the skill appears as a set of steps. Blumenfeld said he would run the process again, and he showed the steps laid out as nodes. He noted that the viewer would not be able to read much of the detail, but said the important point is that the information from the successful runs has been compiled down into this structure.

Blumenfeld wrapped a small CLI around the skill so the agent can simply say to run it. Instead of the agent deciding all the routing steps, these are done programmatically. He said much of the policy was moved into execution scripts.

He summarized the flow: the execution checks whether certain hard policy rules are met. If the application is not automatically approved or denied on that basis, it is routed to a decision model such as Jev or a type-safe model. That model receives a risk tier and some exposure material and produces an outcome of approving or denying. The rest of the process writes a report, and a router decides whether the case must be escalated to human review. If not, the agent writes a report, and a step checks and lints that report.

Once the skill is a CLI that can be run, the speaker said, each run can be tracked. He showed that a single run can be persisted in the graph along with the individual steps it ran, and that these runs can be stored over time and examined for how well they work. He said he had built a small inspector that shows the status of runs, how a specific run went, what was approved or denied, and which branches were taken.

He said that once there is a graph, observability questions become possible, such as which branches were taken and which were not, which he called interesting from a governance perspective. All of this is stored apart from the underlying data. He added that the approach does not create a loop inside the agent; it simply gives the agent a programmatic skill compiled from documentation, or in this case from the memory graph. He noted that the run could take a while because of internet speed.

Blumenfeld said that running the graph with a powerful model, which he said was Fable and which he noted his organization already criticizes for spending, was correct nearly every time, but took 2.7 minutes. With the procedure, runtime almost halved while still using the stronger model. Because the procedure carries the routing, the team could use a simpler model such as Haiku, which cut the model time further and lowered cost substantially. He said this is because the work of figuring out routing is moved into execution scripts and models, making the process much more efficient.

He said average wall-clock time dropped from about 7.5 minutes to about 2 minutes, and that the remaining time is mostly internet access. He closed by pointing to Neo4j resources, including Aura, its cloud offering, which he said includes $100 in free credits, a speakers event, a startup program, and the code and projects for hooking the graph up to agent memory.