Graph-Shaped Skills Turn Agent Decision Traces Into Governed Procedures

Zach Blumenfeld defines graph engineering as designing agent work as an explicit graph: nodes do work, and edges route state between them. The name is new, he says; the underlying ideas are not. Computer science has long used state machines, workflow graphs and knowledge graphs. What has changed is applying them to agents, where the work itself—its steps, decisions and hand-offs—needs structure.

Blumenfeld separates that work into three kinds of graph. An execution graph describes what runs next: the familiar workflow of agents, tools and routers inside an agent framework. A context graph records what is known and why, connecting decision traces and conversation history to relevant domain data. A procedure graph describes what an agent should do repeatably: the steps, decision points, tool calls, validation checks and escalations that make up a skill.

The distinction matters because an execution graph is only one place to put structure. Blumenfeld’s focus is on context and procedure graphs, which can make an agent’s knowledge and instructions explicit—and, in his account, portable beyond the runtime that executes them.

The case for this structure is practical. As agents take on more steps, tools and hand-offs, there are more ways for a run to go wrong. Blumenfeld says graphs help address that complexity through predictability, governance and portability. A constrained path can make behavior more consistent. A recorded path can be inspected and improved. And a graph stored alongside data, rather than embedded only in a particular runtime, can be made available to different runtimes.

That last point shapes Neo4j’s approach. Instead of treating the graph solely as orchestration inside a framework such as LangGraph or an agent SDK, Blumenfeld describes a knowledge layer between systems of record and the agent runtime. The underlying information might come from warehouses such as Databricks, BigQuery or Snowflake, or from documents and Markdown files. The knowledge layer holds data, memory and skills, with interfaces such as MCP, REST, skill files or Cypher/GQL making them accessible to different tools.

The intended division is that the runtime handles execution while the knowledge layer contains what the agent knows and the procedures it can follow. In that design, a graph-shaped skill is an artifact that can move between compatible agent harnesses rather than logic tied to one orchestration framework.

The context graph Blumenfeld describes brings together short-term conversation history, longer-term entities extracted from conversations or other data, and reasoning or decision traces. Those traces can link an agent’s actions back to the information that informed them. The goal is not just to give an agent more context, but to preserve connections between its decisions, the source data and the procedure it used.

Neo4j’s research on the Agent Instruction Protocol (AIP) explores compiling written procedural knowledge into graph form. A source skill may include a SKILL.md file, scripts, references and other assets. AIP turns that material into a graph whose nodes represent decisions, routing points and actions, including scripts that can make parts of a procedure deterministic. Blumenfeld says that, in the research they had conducted, requiring an agent to run the compiled graph improved task reward across challenging tasks in areas including physics, computer science and security. He also cautions that the results he showed were from earlier work and that he was still updating them for newer models.

The approach can also run in the other direction: rather than compile a written skill into a graph, distill a skill from a graph of past work. Blumenfeld says Neo4j’s Will Lyon extended the idea to memory graphs, so a skill can be derived from prior decision traces and remain connected to them. That connection provides provenance: the skill can be versioned and tracked, and people can inspect its history, change it and assess whether behavior has drifted over time. In Blumenfeld’s framing, it also makes it easier to trace where a tool call came from.

He presents this as a route to portability as well as oversight. If the resulting procedure is packaged as a skill that an agent harness can use, its logic does not have to be rebuilt inside every runtime. The graph preserves the procedure and its links to the evidence behind it; the harness runs it.

Blumenfeld points to compliance work as one application. A report may draw on information from multiple sources, while the entities in those sources may use different names or ticker symbols. The agent has to reconcile the records and follow the relevant logic in a way that can be audited. He says representing that logic alongside the data can help automate the work without losing the ability to trace how the result was reached.

He also cites configuration management at Uber. In his description, different geographic areas have different requirements, and the relevant configuration is spread across microservices. A graph can represent the relationships and rules that need to be considered across that sprawl. In both examples, the graph is not simply a store of facts: it also encodes how those facts should be used.

Blumenfeld’s demo applies the approach to a commercial-loan decision. A business plan is uploaded for Rosa’s Bakery, and the agent connects it to lending-policy information, past transactions and earlier decisions. The interface shows a recommendation to deny the request: the requested loan is $250,000, below a stated $300,000 minimum for the business, and the business has been flagged for a past incident. The displayed policy also lists thresholds for loan-to-value, debt-service coverage and debt-to-income.

The graph behind the interface connects the uploaded plan with those other sources. Blumenfeld says the agent can traverse the connected information, find relevant history and produce an audit trail. That makes the initial system useful for resolving entities, applying policies and explaining how information is connected.

But the first version does not force the agent to follow the same path every time. Blumenfeld shows two reasoning traces with different numbers of steps: one run found a precedent that the other did not. A written skill may tell an agent what to do, but it does not necessarily enforce a precise route through the work. He also flags a separate issue: decisions such as approve, deny or send for human review can rely on confidence scores that are not calibrated. He suggests that type-safe decision models could handle some of those decision points.

To address the variation, Blumenfeld compiles successful runs and the loan policy into a graph-shaped skill. The resulting YAML-based skill includes execution scripts and supporting material, as well as policy documentation and instructions for running the procedure. Rather than asking the agent to decide every routing step, the demo gives it a command-line interface for running the skill, with the routing handled programmatically.

The procedure begins by checking hard policy rules. Cases that are not automatically approved or denied go to a decision model, which receives information such as a risk tier and whether there is material exposure. The workflow then determines whether human review is needed. If it is not, the agent writes a report, which is checked and linted. The design separates the steps that can be made deterministic from the decisions assigned to a model or a human.

Blumenfeld is careful about the status of the demonstration: it is not a formal research result, and he describes the code as available for inspection. The figures he gives are from runs of the demo, not a controlled benchmark or a general performance guarantee. He says using the original model alone took 2.7 minutes; with the procedure, it took about half as long. Using a smaller model such as Haiku with the procedure reduced model time further. He also describes average wall-clock time as falling from roughly seven and a half minutes to about half a minute or two minutes, depending on the run. The measures and comparisons are not presented as one controlled before-and-after test.

The explanation Blumenfeld offers is that the procedure takes routing and other workload away from the model and puts it into scripts and designated decision steps, allowing a simpler model to do less work.

The compiled skill is not only a way to standardize future runs. Blumenfeld’s demo also persists runs in the graph, where each step can be examined over time. An inspector shows run status and lets a user inspect what was approved or denied, which branches were taken and how the process unfolded.

That supports a form of observability organized around the procedure. A reviewer can look for branches that were never taken, scripts that failed or decisions that were overridden. Blumenfeld presents these views as governance tools: they make it possible to examine the behavior of a skill across runs, rather than treating each agent response as an isolated answer.

The system, he emphasizes, is not creating an agent loop to manage all of this. The agent invokes a compiled, programmatic skill; the graph stores the procedure and its runs alongside the data. As Blumenfeld puts it, “there’s nothing actually like enforcing that the agent follows an exact path” in the earlier runs. The compiled procedure is his proposed way to make that path explicit enough to constrain, inspect and reuse, while keeping the procedure and its provenance available beyond any one agent runtime.