Zach Blumenfeld (Neo4j) explains how context graphs extend standard RAG for AI agents by capturing decision traces—not just documents. The talk breaks a context graph into three layers: short-term conversation history, long-term extracted entities, and reasoning traces embedded as vectors so structurally similar past decisions surface alongside semantically similar ones, enabling agents to judge new cases by how similar cases resolved. It also covers tooling: the `uvx create-context-graph` one-command scaffold (backend, frontend, demo data, MCP server; 22 built-in domains or custom ontology generation) and the `neo4j-agent-memory` package, which extracts entities via a spaCy → GLiNER → LLM pipeline with deduplication and merging, and integrates with pydantic AI, LangGraph, Crew, and Google ADK. # Channel Presentation Observations ## Speaker & Affiliation - Presenter identifies as **Zach**, an employee of **Neo4j**, describing the company as a "graph intelligence company" with a "knowledge layer graph database at the core." - Self-described career context: formerly in **technical marketing**, recently transferred to a **research engineering role**, returning to "my AI and machine learning roots." ## Explicit Self-Description Claims - Company mission claim: > "We help connect and resolve information so AI systems can be a little bit more accurate and explainable." - Product scope framing: presentation centers on **"context graphs"** as an evolution beyond RAG/knowledge bases — delivering "past decision traces and precedents, and dynamic information about why decisions were made" so agents can "act with subject matter expertise." ## Intended Audience - A **live, technically skilled developer audience**: speaker polls the room ("How many people in this room have heard about context graphs before?" — "about half"; same for hands-on graph coding). - Assumes familiarity with **text embeddings, vector search, agent frameworks** ("a lot of you in here are probably familiar with text embeddings, right?"), and references tooling like Pydantic AI, LangGraph, Crew, OpenAI, Google ADK without explanation. - Audience expected to **code along**: "all the code for this is available. I'll show links at the end," and the goal is "so that you can get started with them very quickly with your own code and your agent framework." ## Claimed / Demonstrated Scope - **Tools demonstrated**: - A hosted context graph demo (financial analyst agent example with risk scoring, hybrid semantic + structural search, graph embeddings via Neo4j GDS). - `create-context-graph` CLI scaffolding tool: > "allows you to create a full stack application to start with just a one-line command in the terminal," likened to "create React app or create Next app." - **Neo4j agent memory package** — "a complete memory API" with short-term memory, long-term memory, and reasoning; includes text-to-graph extraction ("spaCy to gliner and and more advanced to an LLM fallback" plus "merging, deduplication, and enrichment"). - **Ecosystem claims**: "22 built-in domains" (e.g., healthcare, FinServ), data connectors for GitHub, Notion, Jira, Slack, MCP server generation, integrations with "Microsoft agent framework as well as Google ADK." - **Openness claim**: "this project is just getting started. It's open source. People are welcome to commit and contribute." ## Demonstrated Presentation Patterns - **Live demo with candor about limitations**: internet issues acknowledged ("with internet connection, I never really know how things are going to go"), and honest hedging in Q&A — e.g., on auto-writing decision traces: > "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." - **Honest maturity framing**: "It's a new project. So, it's all still a little bit rougher on the edges." - **Educational, non-salesy structure**: definitions first, then demos, then resources; generous Q&A with direct, sometimes "I don't know"-style answers ("I I don't know if it does that quite yet"). - **Resource-forward closing**: blog with live hosted demo, website with step-by-step instructions, GitHub repository all offered. ## Notes on Distinguishing Claims vs. Demonstration - Functional claims (one-line scaffolding, 22 domains, connectors) are paired with **observable screen demos**, strengthening them as demonstrated capability. - Some claims are **creator-asserted only** within this transcript (e.g., hybrid structural/semantic precedent matching accuracy, "22 built-in domains" — stated, not shown). - No channel-wide identity statements (subscribe requests, channel description) appear in the transcript. # Delivery Observations — Zach Blumenfeld, "Why your agents need decision traces, not just documents" ## Overall Tone & Register - **Conversational, informal engineer-presenter style**: frequent filler words ("um," "uh," "you know") and self-directed hedging throughout, e.g. *"I know it's probably hard to read"*, *"I don't know how hopeful that is. It's probably hard to see."* - **Live-demo improvisation**: the talk leans on a running demo, with visible real-time troubleshooting — *"Sorry. I'll let it run for a little bit here and um get moving cuz we only have… Can you hear me now? Okay. How long did that go on for by the way?"* This suggests a live, partly unscripted delivery. ## Audience Interaction Habits - **Opens with show-of-hands calibration** (stable pattern for tech talks, observable here once): > "How many people in this room have heard about context graphs before? Okay, so we've got about half." He repeats the technique immediately: *"And how many people have actually coded anything with a context graph…?"* - **Talks to the room during Q&A**, affirming audience suggestions: *"Yeah, that that is a good point. It's a good idea."*, *"Um But yeah, that's a good point"*, *"Yep."* — a recurring acknowledgment habit across multiple answers. ## Vocabulary & Framing Devices - **Contrast framing** — repeatedly defines concepts by opposing them to a prior state: - *"not only answer questions correctly, but make better decisions"* - *"systems of record, really about facts, entities, current state"* vs. *"about precedents, causal chains, expected outcomes"* - *"that might be very very hard to pull out if you just had it inside of documents"* - **Analogy to familiar tooling** when introducing new tools: > "you can think about this like um create React app or create Next app, like you basically get this boilerplate" Also: *"a graph embedding is the same concept except…"* — anchoring new concepts (graph embeddings) in known ones (text embeddings). - **Concrete-example-first teaching**: introduces the financial analyst agent (*"should you reject, accept, and why"*) before abstract definitions; later uses a healthcare demo (*"I asked it about um prescription medications"*). - **Name-dropping the stack precisely** when describing demos: *"using um Claude in sort of the agent runtime, has some open AI embeddings… Neo4j database… Next.js front end"* — a habit of enumerating technologies as evidence. ## Recurring Phrases & Verbal Tics - **"So," as a sentence starter** — extremely frequent: *"So, my name is Zach"*, *"So, context graphs"*, *"So, if I was to show you"*, *"So, this is a great place to get started"*, *"So, um, underpinning this…"* - **"Right?" as a check-in tag**: *"we need to ask ourselves, 'Would you agents really be accurate?' Right?"*, *"it does this because… and why, right?"*, *"On on words, right?"* - **"Basically" as a softener** — appears many times: *"basically helps an agent"*, *"it'll basically helps…"*, *"basically create this folder for me"*, *"basically just uses a few stages"*, *"basically just the GitHub repository."* - **"Kind of" and "sort of" as hedges**: *"to kind of think actually about what a context graph is"*, *"Cypher in sort of the agent runtime"*, *"like some sort of sentiment or um like quality score."* ## Transparency & Uncertainty Signaling - **Openly admits limits of the technology and his knowledge**, a consistent pattern in Q&A: > "Um I I don't know if it does that quite yet." > "Yeah, I think we're still figuring that out at the moment." > "Again, it's a new project. So, it's all still a little bit rougher on the edges." - **Flags environmental issues candidly**: *"some of it because, you know, with internet connection, I never really know, you know, how things are going to go"* and *"I know on our Wi-Fi for this com for some reason it blocks that website."* ## Structural / Signposting Habits - **Forward-references to resources and links**: *"all the code for this is available. I'll I'll show links at the end"* — repeated later: *"and I'll give you a link to all of this at the end like I said."* - **Time-awareness signposting**: *"we're getting towards the end here and we might actually have a few extra minutes for for questions"*, closing with *"I made it through with a couple minutes to spare."* - **Layered structure**: definition → concrete demo → tooling for beginners → underlying dependency (agent memory package) → resources → Q&A. ## Q&A Delivery Style - Answers are **exploratory and conditional** rather than definitive: *"At minimum, if you're able to describe the ontology… then you can definitely create a graph schema from there. Um and then that will help you do…"* - Uses **dependency-branching reasoning**: *"It then depends on how structured your data is. So, if it's like very structured and it's in like… CSV files or tables, um then it's just a matter of like mapping the Cypher statements over."* - Frequently **redirects to resources**: *"Yeah, I would look at the I would look at the create context graph package."* ## Uncertainty Notes - Transcript gaps mid-demo (segments ~[303]–[413]) limit observation of delivery during that stretch. - Audience questions are not transcribed, so his answers are observed only from his responses. - Single-talk sample: patterns like show-of-hands and contrast framing are well-evidenced within this talk, but whether they are stable across other talks cannot be confirmed. # Observation Document — Why your agents need decision traces, not just documents (Zach Blumenfeld, Neo4j) ## Speaker - **Zach Blumenfeld**, Neo4j ("graph intelligence company" / graph database). Recently moved from technical marketing to a **research engineering role**. ## Core Position - Agents need **context graphs** — not just knowledge bases — to make better decisions, by capturing **decision traces** and **precedents**, not only facts for answering questions. ## Key Claims & Reasoning ### Context graphs vs. knowledge bases - A knowledge base (RAG / graph retrieval) helps an agent **answer questions correctly**. - A context graph extends this to **making better decisions**: providing past decision traces, precedents, and dynamic information about *why* decisions were made. - Contrast: a RAG-style system might output a **risk score and recommended review**; a context graph enables an actual **accept/reject answer with reasons**. - Systems of record cover facts, entities, current state; context graphs add **precedents, causal chains, expected outcomes**, letting the agent "act with subject matter expertise." - Model components: **entities** (things that exist), **events** (decisions, transactions, approvals), **context/policies**, and reasoning recorded by AI and by past human employees. - Attribution: term "context graphs" — he credits **Foundation Capital, ~December** (garbled in transcript), noting "a lot of noise around this idea." ### Demo: financial analyst agent - Demo scenario: credit-increase request using customer info, transactions, policies; agent retrieves decision traces and uses **"find precedents"** to pull structurally similar past decisions, yielding a reject recommendation. - Retrieval uses **hybrid search**: semantic similarity (vector index) plus **structural similarity via graph embeddings** — embedding connected decision-trace subgraphs so similar traces can be found by vector similarity. - Claim: this structural precedent matching "might be very very hard to pull out if you just had it inside of documents." - Stack: CRM/support data fixtures, Claude in agent runtime, OpenAI embeddings, Neo4j with vectors, Next.js front end, **GDS (graph data science)** for graph embeddings. All code available. ### `create context graph` tool (by William Lyon) - One-line terminal command (UVX) generating a full-stack boilerplate app — "like create React app / create Next app" — with front end, back end, and demo fixture data; domain specified at creation. - Features: **22 built-in domains** (e.g., healthcare, FinServ) plus custom domains that can **auto-generate an ontology/graph schema**; connectors to import from GitHub, Notion, Jira, Slack; Cypher-based retrieval; generates an **MCP server**; multi-turn conversation; frameworks include Pydantic AI, OpenAI, LangGraph, Crew, Strands, Google ADK. - Status qualification: project is **new, open source, "a little rougher on the edges"**, just getting started; contributions welcome. ### Neo4j agent memory package - Underpins the tools; a complete memory API requiring three parts: **short-term memory** (conversation/session), **long-term memory** (entities resolved over time), **reasoning** (decision traces in the context graph). - Text-to-graph pipeline implemented in the package: staged extraction via **spaCy → gliner → LLM fallback**, plus separate **merging, deduplication, and enrichment**; alternatives exist for structured data or custom NER/LLM extraction. - Integrates with Microsoft Agent Framework, Google ADK, and others. ## Q&A Positions (short answers, often tentative) - **Timestamps in traces**: Yes, timestamps can be added; steps linked by "caused" or "next" relations over time. - **(Unheard question re: some capability)**: "I don't know if it does that quite yet… that will happen as the technology matures" — explicit uncertainty. - **Ontology preparation**: Ontology prepared beforehand; predefined domains often use a pattern he refers to as **"pole-e"** (likely POLE — person/object/location/event; transcript garbled) with predefined entity/relationship types guiding extraction and mapping. - **Automating graph creation from existing data**: If you can describe the ontology and the data, a graph schema can be generated; structured data (CSVs/tables) reduces to mapping Cypher statements; unstructured data needs entity extraction. Depends on how structured the data is. - **Writing new decision traces / memory persistence**: "I think we're still figuring that out." In the first demo, decisions are stored **only when the user prompts it to**; create-context-graph is still working on how to write new decision traces. Open ideas: sentiment or quality score on decisions. ## Preserved Uncertainties & Qualifications - Live-demo reliability concerns: internet/Wi-Fi issues, the venue Wi-Fi blocks one resource link ("I don't know why"). - Repeated hedges: "I don't know," "I think," "it depends," "still working on," "rougher on the edges" — multiple features described as immature. - Transcript contains garbled passages; several claims (e.g., the Foundation Capital attribution, "pole-e") are only partially recoverable from the speaker's wording. # Speaker Attribution Record ## Video - **ID:** `01a15ca9-1a4f-7ef3-8a9c-37624d9d8060` - **Title:** Why your agents need decision traces, not just documents — Zach Blumenfeld, Neo4j - **Format:** Conference/talk presentation with live demo and audience Q&A ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Zach (Zach Blumenfeld)** | **Creator / Presenter** — Neo4j employee (self-described: "my name is Zach. Uh I work for Neo4j"); recently moved from technical marketing to a research engineering role | Delivers the full talk, demos, and answers audience questions | | **Audience members (unnamed)** | **Other — Q&A questioners** | Ask questions at the end (e.g., about timestamps, ontology preparation, front-end automation, storing decisions); only the speaker's answers are transcribed | | **William Lyon** | **Referenced third party (not present)** — Neo4j product manager credited with building the tools demonstrated | Named by the speaker only | ## Speaker Statements of Note (provenance) - Self-introduction and employer affiliation (Neo4j, "graph intelligence company"). - Attribution of demo tooling to **William Lyon**, Neo4j product manager. - Note on audio dropout mid-talk ("Can you hear me now?") with audience reply ("just a minute"). ## Referenced Sources & Technologies (per speaker) - **Foundation Capital** — credited for the term/idea of context graphs ("I think back in December"). - **Neo4j** stack: Neo4j database, **GDS (Graph Data Science)** for graph embeddings, **Cypher** query language. - **Neo4j agent memory package** — dependency underpinning the tooling; integrates with **Microsoft Agent Framework** and **Google ADK** (speaker's claim). - **create context graph** CLI tool (UVX command) — open source project, recently created. - Third-party AI tools mentioned: **Claude** (agent runtime), **OpenAI embeddings**, **Pydantic AI**, **LangGraph**, **Crew**, **Strands**, **Google ADK**, **Next.js**, **spaCy**, **gliner**, **POLE** ontology ("pole-e" per transcript). - Data connectors: **GitHub, Notion, Jira, Slack**. ## Promotional Segments - The talk functions partly as a **product/tool showcase for Neo4j** (context graph demo, create-context-graph CLI, agent memory package, hosted live application, links/website/GitHub repository). This is inherent to the talk's framing and is flagged as such rather than a discrete ad segment. ## Availability & Limitations - Live demo experienced **internet/Wi-Fi issues** on the venue network; one resource website blocked by venue Wi-Fi (works on normal networks, per speaker). - No curated metadata was supplied; no comment availability information is present in the source. - Transcript contains gaps and garbled passages (e.g., "Should you agents really be accurate?", partial sentences around demo segments) — attribution of those fragments to the presenter is inferred from continuity. So, my name is Zach. Uh I work for Neo4j. We're a graph intelligence company. You can think of us like a knowledge layer graph database at the core. We help connect and resolve information so AI systems can be a little bit more accurate and explainable. Um I used to work in technical marketing. I very recently I'm going back to my AI and machine learning roots. Uh I'm transferred over to a to a research engineering role. So, I'm going to talk to you today about context graphs. How many people in this room have heard about context graphs before? Okay, so we've got about half. And how many people have actually coded anything with a context graph or with a graph like Neo4j in general? Okay. Okay, about half. So, that's good to know. So, I'm going to talk a little bit about how we think about context graphs at Neo4j, define what they are, and then I want to go over some tools um that were built by William Lyon, who's one of our product managers, um so that you can get started with them very quickly um with your own code and your agent framework. So, context graphs Foundation Capital, I think back in December. And essentially uh we saw a lot of noise around this idea uh of creating decision traces and reasoning um to help agents make better decisions. And so, to kind of think actually about what a context graph is, we need to ask ourselves, "Would you agents really be accurate?" Right? And so, um for one thing, doing a lot of retrieval, you're going to need a knowledge base, obviously. Um so, a knowledge base for something like rag or graph retrieval basically helps an agent or a chatbot answer questions correctly. What a context graph does in the evolution of this is really the information required to not only answer questions correctly, but make better decisions. So, if we took an a concrete example, and I'll show you a demo of this, financial analyst agent, um and say that this agent has a question around improving increase. And a request for a certain amount of money. To allow that agent give information about the of the system. So, customer info, transactions, and policies. And the response from that is likely to look something like this, where it could maybe assign some sort of risk score and recommend some sort of review and talk about some key risk factors. What is helpful What a context graph enables an agent to do is actually give an answer, should you reject, accept, and why, right? And it does this because in addition to getting that customer information and those transactions, it's also going to get you past decision traces and precedents, and dynamic information about why decisions are made. Um Um systems of record, really about facts, entities, current state, about precedents, causal chains, expected outcomes, and enabling the agent to act with subject matter expertise, um and telling the agent really model for a context graph. Um the entities, about things that exist, there'll be uh events, so decisions, transactions, approvals, things like that. And then context, policies that are um in different reasoning by AI that records memory, but um by employees and and past humans that have made decisions. some of it because, you know, with internet connection, I never really know, you know, how things are going to go. Um all the code for this is available. I'll I'll show links at the end. Um basically data that we generate replicates taking data in from a CRM and a support system and some other places. Um it's using um Claude in sort of the agent runtime, has some open AI embeddings. Um there's Neo4j database assisting the data with some vectors. Um and then we have our Next.js front end um as well. So, let me show you this recording running here so you can kind of see what this looks like cuz again, all these are going to go So, you asked it a question, and it will call basically a series of tools, and you can see it bringing the graph data back. Um and then you see it getting these different decision traces, and eventually it will get this reject decision, right? And if that a Then it does this thing called find precedents, which is going to be more in a second, but it's going to look at structural information in the graph to pull a bunch of And it did internet would work. connect to each other in these causal chains. So, you build off of each other. is uh So, like I was saying before, um we queried just context around Jessica's profile. We pulled back decision traces. Then we did a special of hybrid search, especially around those precedents, both on semantic similarity and structural similarity inside of the graph that actually looked at how the decision traces were made um from previous decisions, and it tried to match that, and I'll talk a little bit about how that works with graph embeddings in the next slide to ultimately come up with the recommendation. And so, we have a we have a vector index, so we're able to search like fraud rejection, for example, sort of on the semantics. But then we have this concept called graph embedding. So, you a lot of you in here are probably familiar with text embeddings, right? On on words, right? A graph embedding is the same concept except those green nodes that I was showing you before everything was connected. We actually embedded those into a vector. And so, what that means is similar decision traces are now going to be able to be looked up by vector similarity. And so, if you have system, right? Where you've had past decisions and tickets that have been Now up just like you would with vector search for for another type of text, and that might be very very hard to pull out if you just had it inside of documents. Um this is just some more information around uh the context graph demo and some of the scenarios you can run, um and some of the tools that were used here. Um GDS is called graph data science. That's what we use for the uh for the graph embeddings themselves. Um and then I'll link you over to the code here to rerun that. But what I really wanted to show you today um was another tool that was just recently created a little month ago, um which allows you to create a full um stack application to start with with just a one-line command in the terminal to actually create the context graph and the front end and the back end. Um and so, basically you can think about this like um create React app or create Next app, like you basically get this boilerplate, um and all of the scaffolding that you specify and you can specify the domain when you create the graph, um or when you create the application, rather, in the command line, um and it will give you this, you know, basically the back end, the front end, and and and everything um out of the box. So, if I was to show you uh if I go over here, kind of looks like this, and I know it's probably hard to read. There's just a UVX command, UVX create context graph, um specify the name of the app, the domain, um the framework I want to use. There's a ton of them that that we can use here. I'm choosing Pydantic AI. Um and I'm and I'm specifying demo data. And it will go and basically create this folder for me with a bunch of fixture JSON be the data in this case going to use its uh you know, basically dummy data that I can use to help host the application. And which we don't have enough time to run through all of them. It takes a few minutes to basically install the application and seed the data and stuff and start. But I do have it running. Um that it would give you I don't know how hopeful that is. It's probably hard to see. If I go back to uh right. It'll give you um you know data inside of a graph and then um you know, you can go ahead and ask questions um and it will go and and you know, basically do this type of retrieval with Cypher and and everything else. Cypher's a graph query language um to pull data back. Very similar to what we saw in that uh context graph demo that was hosted. Sorry. I'll let it run for a little bit here and um get moving cuz we only have All right. Can you hear me now? Okay. How long did that go on for by the way? How long was it? Uh just a minute. Okay. All right. Okay. Well, here's our response back. So, you can see um you know, I asked it about um prescription medications and and it and it went ahead and and pulled everything back and there's a visualization of the schema here and like I was saying different traces that you can look through. Um so, this is a great place to get started if you just want to you're interested in context graphs and you just want to code something up really quickly. Uh there's a website that we have for this too that you can go to. Um it explains this step-by-step um about how to you know, get the app started and explore everything. Um there's also some very interesting neural tools if you want to import from um software as a service. So, if you want to import from GitHub or Notion or Jira or Slack. So, you don't have to use just demo data. You can import data from these other tools. Um and then some other features and I'll give you a link to all of this at the end like I said. Um So, we were looking at a Pydantic AI application, but you can also do it with OpenAI and LangGraph and Crew and Strands and Google ADK and all these others. There's a 22 built-in domain. So, healthcare was the one that I just showed, but there's also FinServ. You can also create your own custom domain and it will actually help generate an ontology basically a graph schema for you and put everything together. We talked about um the different data connectors for GitHub, Slack, and etc. Um and it has all of the graph native stuff to power your queries um that we were seeing to pull the data, look at decision traces, um generating an MCP server and doing actually multi-turn conversation inside of that app. Um so, again, this project is uh just on it's just getting started. Um so, it's open source. People are welcome to commit um and contribute there. Now, I'll talk a little bit about what this project is uh based on. So, um underpinning this, one of the big dependencies is our Neo4j agent memory package. Um so, this is a complete memory API. Uh it includes and context graphs really need all three of these things. Um a short-term memory, a long-term memory and reasoning. So, short-term is more conversation history and session context. I think we we understand that. Uh long-term is the entities that are extracted from that um and those that repeat over time and resolving those down. And then the reasoning is going to really be sort of the um the traces inside of that context graph. Um and there's also inside of here which is very useful. I know a lot of people think about well, if I have this text data, how do I put it into a knowledge graph, right? Is is you usually one of these big questions that people have. Um so, here uh we actually implemented this inside of the package. Um where it goes through a few different stages on raw text. There's other tools that you can use sort of outside of this if you want to um take in structured data um or you can use your own language model extraction um NER processes. Um but this one just uses a few stages where you go from spaCy to gliner and and more advanced to an LLM fallback. Um and then there's a separate merging, deduplication, and enrichment strategy. So, um it's a little bit more well thought out and that helps especially with the short-term memory take that information out and transition it into useful long-term memory and entities that can be resolved over time. And the schema kind of looks like this where you have your conversations um and then in yellow you have your um your entities that get pulled out and those connect to your reasoning traces. All righty. So, we're getting towards the end here and we might actually have a few extra minutes for for questions if if that's allowed. Um but here are the resources. So, the context graph demo that I showed, if you go to that blog, it'll also link you to a live application that's just hosted. Um and so that that's very useful if you just kind of want to explore the concepts out of the box. Create context graph in the middle. On the top one, I know on our Wi-Fi for this com for some reason it blocks that website. It won't block the website if you go on a normal Wi-Fi network. I don't know why it does for this one. Um but that link does work. And then on the one on the bottom is basically just the GitHub repository. Uh Neo4j agent memory um is the agent memory package that underpins um all of that and that also integrates with Microsoft agent framework um as well as Google ADK and and a whole bunch of others. Um so, that's actually it for me. I made it through with a couple minutes to spare. So, I'm happy to open it up to any questions for the next couple minutes if if there are any in the room. Yes. Yep. Yeah, there is. You can add timestamps. Um you can add timestamps and then obviously as they occur in time the different steps, they'll be linked by like caused or next. Yeah. Um I I don't know if it does that quite yet. I think that's something that will happen as the you know, as the technology matures a little bit, but yeah, that that is a good point. It's a good idea. So, you'll prepare the ontology beforehand. For those domains that um I showed you the preexisting ones, a lot of them will use this there's something called pole-e which is like um entity um basically policy. There's like a few like predefined entity and relationship types and that's used to guide the extraction and all of the mapping and stuff. Um so, yes. Yes. Automate creating a front uh Yeah, I would look at the I would look at the create context graph package. At minimum, if you're able to describe the ontology um then describe what's in the data, um then you can definitely create a graph schema from there. Um and then that will help you do if it's unstructured do entity entity extraction. Um I it then depends on how structured your data is. So, if it's like very structured and it's in like um for example, like CSV files or tables, um then it's just a matter of like mapping the Cypher statements over. Uh yeah, so I think that that text stuff I think that can be handled inside of here. If you look at like create your custom domain, there might be some things that you can do there to help you. Again, it's a new project. So, it's all still a little bit rougher on the edges, but at least you'll see the code and you'll see how it can generate an example ontology and then how that can be fed to an extraction process to to move everything through. Yep. Yeah, I think we're still figuring that out at the moment. Um I know in in this first demo that it is like you can ask it to store like if I I for my previous conversation, I can ask it to store decisions, but I don't think it will do it unless I prompt it to. Um But yeah, that's a good point and then in the create context graph, we're still working on how you would write um new decision traces. Um so, so yeah, it's something to think about like some sort of sentiment or um like quality score on the decisions. All right. Cool. Well, thank you guys.