AI Agents Need Decision Traces—And a Threat Model

There's a demo moment in Zach Blumenfeld's talk at AI Engineer that I keep turning over. A financial analyst agent gets asked whether to approve or reject a credit request. A standard RAG setup—the kind most teams are building right now—pulls the customer's transaction history and risk policies and produces something like a risk score with caveats. Useful. A context graph setup does something different: it also pulls past decision traces, the reasoning behind similar cases, how those cases resolved, and what the structural pattern of those decisions looked like. The agent doesn't just answer the question. It makes a call.

Blumenfeld, who recently moved from technical marketing into a research engineering role at Neo4j, frames this as the evolution from "answering questions correctly" to "making better decisions." The distinction is sharper than it sounds. A knowledge base tells you what the rules are. A context graph tells you what the organization has actually done under those rules, and why, and what happened next.

That's a meaningful architectural step. It's also, from where I'm sitting, the most interesting threat surface in the current AI agent stack.

What the system actually does

The neo4j-agent-memory package—which underpins the tooling Blumenfeld demos—structures agent memory into three layers: short-term conversation history, long-term extracted entities, and reasoning traces. The extraction pipeline moves through spaCy, then GLiNER for more sophisticated named entity recognition, with an LLM as fallback for anything the earlier stages miss. There's deduplication and merging built in, which matters because entity resolution is where naive implementations fall apart.

The piece that's technically novel is graph embeddings applied to decision traces. Text embeddings capture semantic similarity—"fraud rejection" matches "fraudulent transaction denial." Graph embeddings capture structural similarity: two decisions are similar not just because they used the same words but because they traveled the same reasoning path through the same relationship types. An agent querying for precedents gets both signals simultaneously. If you've spent time trying to surface similar past cases from document stores, you know why that matters. Documents flatten structure. A graph preserves it.

The scaffolding tool—uvx create-context-graph—is designed to get developers into this architecture fast. Blumenfeld describes it as analogous to create-react-app: a single terminal command that generates a back end, front end, and demo data for a specified domain. The video description includes MCP server generation as part of the scaffold, though Blumenfeld's demo notes this is a project still early in development, so specific capabilities—including what ships in the default scaffold versus what's configured separately—are worth verifying against the current repository before you build production dependencies on it. Similarly, the "22 built-in domains" figure comes from the live demo; template counts shift in active open source projects, and the number matters less than the fact that custom domain generation with LLM-assisted ontology creation is part of the design. The comparison to create-react-app is Blumenfeld's own framing, and it's apt: the goal is to remove the bootstrapping friction so developers engage with the conceptual architecture rather than yak-shaving their way through setup.

The open source question isn't just about transparency

The project being open source is genuinely good for developers who want to understand what they're building on—and for the research community that needs to stress-test these ideas. But I want to be direct about something the "open source is great for transparency" frame tends to skip over: it means the attack surface is documented and public.

When I was doing red team work, open source systems weren't harder to attack—they were easier. You don't have to reverse-engineer anything. The extraction pipeline stages, the deduplication logic, the graph embedding approach: all of it is readable. That's not an argument against open source. It's an argument for building threat models alongside the tooling, not after deployment.

The question I'd actually want answered

Here's where I'll speak from experience rather than observation. I've built automated decision systems. I've also been hired to break them. And the failure mode that keeps me up at night—the one that's hardest to catch in a demo, hardest to catch in QA, and hardest to explain to a CISO after the fact—isn't the agent making a wrong decision. It's the agent making a confident decision based on a corrupted history it has no way to doubt.

Context graphs accumulate institutional memory over time. That's the value proposition. It's also the attack vector. If an adversary—internal or external—can inject plausible-looking decision traces early in a system's life, those traces become precedents. The graph embedding means structurally similar future decisions will surface those poisoned traces as relevant prior art. The agent isn't hallucinating; it's reasoning correctly from compromised data. And because the traces look like legitimate institutional history—they have the right relationship types, the right causal chain structure, the right entity connections—they're much harder to flag than an obviously wrong output.

Blumenfeld is honest that the system for writing new decision traces is still being worked out: "I know in this first demo... you can ask it to store decisions, but I don't think it will do it unless I prompt it to... we're still working on how you would write new decision traces." In a demo context, that sounds like a feature backlog item. In a production financial services deployment, the write pathway and its access controls are a security design question that needs an answer before the memory starts accumulating. Who can write a trace? Under what conditions? What prevents a malicious insider from seeding the graph with traces that will steer future agent decisions? What's the anomaly detection story for the graph itself?

None of this is unsolvable. But the "let the memory accumulate and get smarter" framing elides the fact that accumulated memory is accumulated risk if you can't verify its provenance.

Where this is actually going

The demo domains—financial services, healthcare—are not coincidentally the two sectors with the most regulated decision-making processes in the US. An agent that can point to prior decisions and explain its reasoning in terms of precedent is genuinely useful for compliance narratives. "The agent rejected this because structurally similar cases were rejected for the same pattern of risk factors" is a more auditable output than "the model scored this 0.73."

But auditability of the output isn't the same as auditability of the memory. The graph is the evidence base. If you're going to use it to justify decisions in regulated contexts, you need to be able to answer questions about when each trace was written, by what process, and whether it's been modified. That's not a Neo4j problem specifically—it's a problem for anyone deploying this pattern—but it's conspicuously absent from the developer-facing framing, which is all about getting something running quickly.

"What a context graph enables an agent to do is actually give an answer—should you reject, accept, and why," Blumenfeld says. The why is what makes this compelling. It's also what makes the integrity of the underlying graph load-bearing in a way that a purely generative system's outputs are not. A wrong LLM answer is a wrong answer. A wrong decision trace is a wrong precedent—one that shapes every structurally similar decision that follows it.

The tooling here is genuinely well-thought-out for what it is: a fast path to a sophisticated architectural pattern that most teams wouldn't build from scratch. Getting developers to experiment with decision traces and graph-native memory is a legitimate contribution. The harder problem—and the one I'd want to see get as much engineering attention as the extraction pipeline—is what it means to trust the memory itself.

---

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.