Why your agents need decision traces, not just documents — Zach Blumenfeld, Neo4j

What would a financial analyst agent need to recommend accepting or rejecting a customer’s request? Retrieving the customer’s records is a start. The harder question is how to supply the experience behind a defensible decision.

Zach Blumenfeld approaches this problem from Neo4j, which he describes as a knowledge layer with a graph database at its core: a way to connect and resolve information for more accurate, explainable AI systems. Having recently moved from technical marketing back into AI and machine learning research engineering, he introduces context graphs through application tools built by Neo4j product manager William Lyon. The broader discussion draws on Foundation Capital’s context-graphs essay, which emphasizes decision traces and reusable precedents.

A knowledge base supports RAG or graph retrieval by supplying the information needed to answer questions. In the financial example, that includes customer information, transactions and policies. An agent can use those facts to assign a risk score, identify risk factors and recommend review.

A context graph adds past decision traces and precedents. Instead of stopping at a risk assessment, the agent can use that history to recommend acceptance or rejection and explain why. The completed slide illustrates a credit-limit request, contrasting the knowledge-base assessment with a recommendation to reject or escalate for senior review. The additional context is how earlier decisions were made, not simply more facts about the current customer.

This extends the role of a system of record. Facts, entities and current state remain necessary; precedents, causal chains and outcomes make them useful for decisions. The graph model separates three kinds of information:

The reasoning history can come from an AI system’s memory or from employees who made earlier decisions. Connecting those records gives the agent access to accumulated subject-matter experience.

The financial application uses generated data that simulates inputs from a CRM, a support system and other sources. Claude runs the agent, OpenAI embeddings support vector retrieval, Neo4j stores the connected data and vectors, and Next.js supplies the frontend. Blumenfeld uses a recorded walkthrough because the venue’s internet connection is uncertain; the companion walkthrough provides the implementation and setup path.

Submitting a question starts a series of tool calls. The interface shows graph data returning, then decision traces, and finally a rejection recommendation. The displayed result sits beside the connected graph and the trace cards, so the recommendation can be read alongside the context used to produce it.

The Find Precedents tool looks beyond the customer’s immediate records to structural information in the graph. Decision traces connect through causal chains, allowing earlier steps and decisions to build on one another.

In the walkthrough, the agent retrieves Jessica’s profile, pulls back decision traces and searches for precedents using both semantic similarity and structural similarity. Semantic retrieval finds related content; structural retrieval looks for similarities in how previous decisions were made. Those retrieved precedents then inform the recommendation.

A text-vector index can retrieve something semantically related to a phrase such as fraud rejection. Graph embeddings add another representation: vectors derived from connected nodes, rather than only from words.

Blumenfeld points to the connected green nodes in the demo to explain the second case. Encoding graph structure into vectors makes structurally similar decision records accessible through vector similarity search. The companion implementation identifies FastRP node embeddings for this purpose; this does not require treating each complete trace as a single embedded document.

That makes previous decisions and tickets searchable as precedents, including patterns that may be difficult to recover when their relationships are buried in documents. Neo4j’s Graph Data Science, or GDS, generates the graph embeddings in this demo. The combined retrieval mechanism is clear, but the talk does not specify a score-fusion formula or weights for semantic versus structural similarity. The accompanying demo scenarios and code provide a starting point for exploring the implementation.

Create Context Graph packages the starting application in the style of create-react-app or create-next-app. Its job is to scaffold the frontend, backend and graph setup together, with a domain and agent framework selected for the application.

The command entry point demonstrated is:

uvx create-context-graph

Blumenfeld supplies an application name and domain, chooses Pydantic AI, and requests demo data. The generator produces an application folder containing fixture JSON and dummy data. Scaffolding is only the first step: dependencies still need installation, the graph needs seeding, and the application needs starting. He describes that setup as taking a few minutes and switches to an already-running instance onstage. Current repository instructions default to a hosted backend and use --self-hosted --demo for the local seeded path; those are current setup options, not a reconstruction of his full stage command.

Once the application is running, questions trigger retrieval from the graph using Cypher, Neo4j’s graph query language. This follows the same broad interaction as the financial demo: ask a question, retrieve connected records, and return an answer supported by that context.

The generated example uses healthcare data. A question about prescription medications returns retrieved information, while the interface exposes a schema visualization and decision traces for inspection. The project’s website walks through starting and exploring the application. Imports from GitHub, Notion, Jira and Slack provide a route beyond the bundled demo data.

The scaffold offers several independent choices:

• Agent framework: Pydantic AI in the demonstration, with alternatives including OpenAI, LangGraph, CrewAI, Strands and Google ADK.
• Domain: Blumenfeld reports 22 built-in domains, including healthcare and financial services. A custom-domain path helps generate an ontology—the graph schema describing the relevant entity and relationship types.
• Application capabilities: Graph-native queries, decision-trace retrieval, MCP server generation and multi-turn conversations.

The domain count describes available templates, not measured decision accuracy across industries. Blumenfeld presents the generator as a new open-source project and invites contributions.

Underneath the generated application is Neo4j Agent Memory, an API spanning three kinds of memory. Blumenfeld treats all three as necessary for a context graph:

Conversation history preserves what happened in a session. Long-term memory identifies the entities that recur across sessions and resolves their mentions over time. Reasoning memory connects that context to the traces of decisions.

The next problem is ingestion: how does raw text become a graph? The package includes a staged extraction pipeline, though structured-data tools or custom language-model and named-entity-recognition processes can also supply the data.

Its text pipeline proceeds through increasingly capable extraction stages:

1. Start with spaCy.
2. Use GLiNER for further entity extraction.
3. Fall back to an LLM.
4. Apply a separate strategy for merging, deduplication and enrichment.

Extraction and resolution do different jobs. Finding an entity mention in a conversation does not by itself establish whether it refers to an entity already stored in memory. The subsequent processing helps turn short-term text into useful long-term entities that can be resolved over time.

The resulting schema connects conversations to extracted entities—shown in yellow in the schema illustration—and connects those entities to reasoning traces. This is how the three memory categories become parts of one connected model rather than separate stores of chat messages, names and decisions.

The financial-demo blog links to a hosted application for exploring the concepts before setting up a local project. Create Context Graph supplies the full application scaffold, while Agent Memory exposes the underlying memory functionality, including integrations with Microsoft Agent Framework and Google ADK. Blumenfeld notes that the conference Wi-Fi blocks one of the resource sites, although he says it works on other networks.

The audience’s first implementation question concerns time: can a causal chain represent when its events occurred, and does their age affect retrieval?

Timestamps can be attached to events, and successive steps can be linked by relationships such as caused or next. That provides temporal information and connections between steps. When asked whether more recent events receive greater weight, however, Blumenfeld says he does not know whether that capability exists yet and treats it as a possible future development. Representing time is distinct from using recency to rank precedents.

The ontology establishes the kinds of nodes and relationships the application will use. Blumenfeld explains that it is prepared beforehand and guides both extraction and mapping. Many predefined domains use a POLE-style model. POLE denotes Person, Object, Location and Event; Agent Memory’s documented POLE+O model adds Organization. These predefined types constrain how incoming information becomes graph records.

For a large existing collection of information, Blumenfeld suggests the generator’s custom-domain path. Describing the intended ontology and the contents of the data can produce a graph schema, which then guides ingestion. The next step depends on the input:

• Unstructured text: Use the schema to guide entity extraction.
• Structured CSV files or tables: Map the existing fields and relationships into graph writes using Cypher.

The generated example ontology can feed an extraction process, and the project’s code makes that path inspectable. Blumenfeld cautions that the new project is still rough around the edges; the proposed workflow starts with a description of the data and desired ontology, rather than promising automatic discovery of a complete schema from any archive.

The final audience question reaches beyond retrieval. As the graph grows, how does the system distinguish good decisions from bad ones? Should people provide thumbs-up or thumbs-down feedback? Can it detect whether a new trace contains novel information or merely repeats something already represented? Those questions determine whether the system could learn autonomously or would need users involved in selecting its experience.

Blumenfeld says those mechanisms are still being worked out. In the first demo, a user can prompt the agent to store decisions from a previous conversation; he does not think it stores them without that request. Writing new decision traces in Create Context Graph is also still under development. Sentiment or decision-quality scores are possibilities he raises, not established features of the demonstrated system.

A graph can make earlier decisions retrievable without establishing that they deserve to become precedents. The unresolved step is deciding what to retain, how to judge it, and when to let new decisions change the memory that future recommendations will use.