---
title: "How Do Graph Databases and the Context Layer Fit Together? | EP 05 Recording | Atlan"
url: "https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/"
description: "Watch the full EP 05 recording. Emil Eifrem (Neo4j) and Prukalpa Sankar (Atlan) work through whether graph databases are the foundation of the context layer, or just where the structure gets stored."
keywords: "context layer, graph database, neo4j, enterprise AI, atlan events, context layer series, emil eifrem, prukalpa sankar"
---

> Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/

# How Do Graph Databases and the Context Layer Fit Together?

WTF Context Layer / On demand / Recorded August 19, 2026 / 58:19 / 9 chapters

Watch: https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/

Neo4j co-founder Emil Eifrem and Atlan's Prukalpa Sankar, hosted by Austin Kronz, on where graph databases fit in the context layer: ontologies, GraphRAG, agent memory, and when to move data at all.

## What you'll see

### 01 / How the graph database got its name

Watch 8:42-18:12: https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=522

Emil on building Neo4j from consulting work where every domain model came out as a graph, how the category was named, and the performance-bound use cases graph databases won first.

### 02 / Reverse-engineering an ontology

Watch 18:12-26:22: https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=1092

AI now drafts a graph model from a Postgres or Snowflake schema. Prukalpa explains why ontologies were always too costly to keep current, and how a connected data graph lets Atlan generate one for a human to review.

### 03 / Ontology, knowledge graph, context graph

Watch 26:22-42:27: https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=1582

Emil separates the terms and the property graph from RDF. He then walks through why top-10 semantic search falls short, and how relationships fix retrieval the way links fixed web search.

### 04 / Memory, skills and where they disagree

Watch 42:27-58:19: https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=2547

Agent memory as a graph workload, advice for builders, and the open question: run a virtual graph over warehouse data, or move it into a native graph for deep, real-time traversal.

## Speakers

- Austin Kronz, Director of Data Strategy, Atlan (host)
- Emil Eifrem, CEO & Co-founder, Neo4j
- Prukalpa Sankar, Co-founder, Atlan

## Chapters

1. [0:00 Why Graph Again](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=0)
2. [8:42 Two Graph Decades](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=522)
3. [13:15 Where Graph Won](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=795)
4. [18:12 AI Helps Graph](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=1092)
5. [21:26 Reverse-Engineering Ontology](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=1286)
6. [26:22 Defining The Terms](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=1582)
7. [35:14 Graph RAG](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=2114)
8. [42:27 Memory And Skills](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=2547)
9. [49:16 Where They Disagree](https://atlan.com/wtf-context-layer/how-do-graph-databases-and-the-context-layer-fit-together-recording/?t=2956)

## Related videos

- [From ontology to context layer (EP 04)](https://atlan.com/wtf-context-layer/from-ontology-to-context-layer-recording/) (62 min)
- [What is a context graph?](https://atlan.com/know/enterprise-context-layer/videos/what-is-a-context-graph/) (2 min)
- [GDD 2026: context graphs, the next $1T opportunity](https://atlan.com/great-data-debate-2026/context-graphs/) (43 min)
- [WTF is the Context Layer? (EP 01)](https://atlan.com/wtf-context-layer/what-is-context-layer-recording/) (59 min)

## Transcript

### 0:00 Why Graph Again

**Austin Kronz**

[0:03] All right. Welcome, everyone. People will be trickling in, but let's, let's get this show started. I am super excited about today's episode. We are already on episode five of the WTF is the Context Layer series, and I think this one's been highly anticipated. I was just posting on LinkedIn earlier graph, at least in my personal experience, has gone through a couple different waves of hype. Back when I was at Gartner, all of the analytics vendors were adding natural language query and augmented analytics, and, you know, every single question we would get is like, "Are they using a graph?" Or like, "Hey, is this built on a knowledge graph?"

[0:37] And then COVID came, and all of a sudden supply chain use cases for graph analysis were all the rage, and the ones that actually had a graph foundation were able to navigate supplier issues upstream and downstream manufacturing. And now it feels like with AI yet again, every conversation comes back to graph. So I'm really excited to be joined today by Emil Eifrem, who's the the founder and CEO of Neo4j, whose company's really become synonymous, I think, with graph. I think a lot of times people just ask us, "Hey, like, is it Neo4j?" Or something like that. And Prukalpa, who's the co-founder of Atlan. So thank you both for joining.

[1:15] We're gonna get into the discussion soon, but as with every episode, I try to ground us on why are we here, what are we talking about. And so you've seen these slides. There's a lot of buzz and hype and different words that people bring up whenever they hear things like context, or we start talking about agentic AI, whether it's context means semantic layer, or context is the knowledge graph, or context is the ontology and, you know, insert whatever buzzword you choose at that point in time. Everyone has a slightly different perspective. What we're gonna answer today is a, a couple key questions, which is just how has graph changed over time?

[1:49] Graph is not new, and so how does this fit in? Where is it the right use case? Where is it not? We're gonna talk about why now. So there's obviously been kind of this resurgence or just surge in h-hype around graph, and so why is everyone talking about it within AI? And then is graph database, is it the foundation? Is it the entire context layer? Is it a component? So we're gonna leave the episode today answering these key questions.

[2:14] And before we get to the end, rather than waiting for the last thirty seconds, I have to tell you about Context 26, which is gonna be Atlan's Context Conference, really just the industry conference for all things context happening at the end of October. So please scan the QR code. We'll send a link in the chat, and we hope to see you at the Context Conference live in October. I talk about buzzwords. You've seen these slides. Hopefully, we're getting familiar with them at this point in the series.

[2:39] But rather than getting right into the, you know, key components or what is or is not a semantic layer, what is or is not an ontology, I'd just like to ground on what does it take to make an agent successful and answer questions accurately. Fundamentally, we like to think of context as knowledge, expertise, and norms. Knowledge is just what is the map of the business. What do things mean in our organization? Expertise, how does things actually get done? This is the procedural knowhow within your organization. And then norms, which are just how is the agent expected to perform? What is it allowed to do? What is it allowed to see? The policies, guardrails, et cetera.

[3:16] In a real question we are taking this from like a typical customer support center at a telco company. Let's say Dana, a customer, calls in and asks a relatively straightforward question, which is, "Hey, I have this forty dollar roaming charge. I think it should be refundable. My service was down." Even within this question, there's so much context that needs to be delivered for an agent, let alone a human, to be able to answer this. First of all, who is Dana? Who is this person calling? Well, what is a roaming charge? Does this actually apply to Dana? We're saying refundable and not refundable.

[3:50] That implies we have some type of rules or procedures that tell us what, what is refundable and what isn't. What is the service that they have? You know, what is the... How is that related to to the customer and to their plan. And ultimately if I want a refund, how do I actually issue this? You know, so I have to integrate with my actual operational and transactional systems as well. Behind this, all of the buzzwords we saw in the first slide might exist, and I share this intentionally to be a little bit overwhelming, but you could probably map any one of these key terms to a part of that question.

[4:23] If I wanna understand who the customer is and is it refundable, I'm gonna need an ontology of the business that tells me what things mean, what is true, what are the rules. I'll need to understand, hey, is this a standard case or some type of edge case? Why wasn't this handled in the typical refund process? And so this emergence of context graphs have become a really interesting way of learning from what the actual decision processes and traces of an agent actually are. Skills might tell you that procedural playbook of what I should do, how I should execute the refund. Semantics might tell me what information within my structured data I need to go find.

[4:56] What are the actual metrics and dimensions? The catalog tells me not just what those dimensions and metrics are, but are they the ones that have the green check mark and are trusted and verified. SQL intelligence could help me understand what questions have been asked before of this data. And ultimately, the memory of the agent is where we can hold durable kind of context over time, not just, you know, giving it the one-time bootstrap, "Here's what we do," but as the agent interacts with more and more users, we should be accumulating memory and understanding preferences and things like that.

[5:26] So all that to be said, how we think about the context platform overall, there are a few main components. At Atlan we talk about AI-ready data, semantics and ontology, and these agent skills, which has become really the, I think, de facto standard for any type of procedural information that we feed to an agent. AI-ready data, starting from the foundations of connecting or mining those systems of data, systems of knowledge. This could be your databases, data warehouses, BI tools, your drives, anything that needs to pull in context and pull in information. Making sure that it's well-described has clear descriptions, README files.

[6:07] We're pulling from things like the past SQL queries to understand what questions are actually being asked. There's a lot of context you can learn just from the existing systems that are out there today. If you have really great you know, documentation and AI-ready data, we can start to bootstrap things like semantics. If you have great semantics on top of your data, you can start to build out an ontology of the business beyond just the data ecosystem.

[6:30] And then if you add in the agent skills layer and the procedural aspects, you know, this is how the agent ultimately has all the information about what your business is, how it operates, where the data is, what the data means, and how it can navigate that to ultimately return some type of result. And how you display that to your agent or deliver it to your agent, whether that's through MCP or programmatically through APIs or things like that, like, all the delivery mechanisms should exist regardless of the type of agent that you're building. And before I turn it over to Prukalpa and Emil, I'll say probably the...

[7:00] I don't know if you would describe it as like the holy grail of agent building, but traces and what the agent actually is doing in production once you've gone through this initial bootstrapping phase becomes everything that you'll need. As long as you have the evals that you're trying to achieve, the traces and what the agent actually is doing, the tools it's calling, the context it's using, the answers it's giving, all of this can start to be you know, a feedback loop back into the agent so we can actually improve it more dynamically as it runs.

[7:31] So I'll pause here, and it's probably a good time, Prukalpa, to, to bring you in and just give some, some thoughts on this. And then Emil, we've given our POV, so I, I want you to come ready with are we, are we on point, are we wrong, or is it a classic improv "yes, and..."

**Emil Eifrem**

[7:51] Amazing. Well, first of all, great, great to be here. You know, happy to share my point of view, but Prukalpa I think, I think you're up first. As, as the host, I think you're up first.

**Prukalpa Sankar**

[8:02] Yeah, I mean, I think, Austin, you covered my point of view quite well, so I actually think we should get this debate started and, and go to Emil's point of view, and then let's keep going from there.

**Austin Kronz**

[8:12] Awesome. Let's do it. Emil, no, no pressure here. What I guess initial thoughts and reactions and my, my overarching question is where does graph fit in when it comes to AI? But it might be helpful just to ground us on, you've been working in the graph space and really pioneering the space for a long time. How has... How have things changed since the day you started with Neo4j versus where we're at today?

**Emil Eifrem**

[8:40] Yeah.

### 8:42 Two Graph Decades

**Emil Eifrem**

[8:42] I think that's absolutely correct. I've been doing this for since the age of dinosaurs or something like this. You know, it's been almost two decades now since we, since we started the company, so lots of waves of technology. But our point of view has been consistent from day one, which is some version of the world shows up in paths and hierarchies and trees and networks and journeys, right? And yes, we have for decades, even longer than we've been around, we've been using the relational database, and the tabular abstraction is phenomenal for many things, right? But not for everything.

[9:25] And the observation we did when we worked as, you know you know, consultants building enterprise systems for big companies, was that step one in our process was always understand the application, the domain model, what people wanted us to build. And we got into a room with domain experts, SMEs, subject matter experts, who would be experts at insurance or pensions or retail or something like this, but who had no idea what third normal form was or ER modeling or anything like this, right? And we would just ask them to just draw your world on the whiteboard, right? And almost never did they end up drawing tables, right?

[10:07] Maybe if we got like an accountant in there, like draw a payroll system, maybe that would have been a table, right? But it was like, "I have a shopping cart, and inside of that I have an order item which connects to like a product which sits in a product hierarchy," right? Or whatever the thing might be, right? And so we realized that you take a look at that and it's like, it's back to like circles connected through, through lines, and there's this impedance mismatch between that view of the world and the underlying relational database for some data. Not all data, but for some data.

[10:44] And we said, "You know, there's gotta be a better way of doing this." And, you know, we were young enough and naive enough to say, "You know what? Shouldn't we just build this?" Like, we started looking around trying to see is there a way of, of just minimizing this, this mismatch, this cognitive mismatch between what was on the whiteboard and what's actually represented in the database. Couldn't find anything, and that's when we said, "Let's, let's just build it." And here I am two decades later still building it.

**Prukalpa Sankar**

[11:13] Emil, out of out of curiosity, at this time, this concept of a graph database didn't exist at all.

**Emil Eifrem**

[11:18] Yeah.

**Prukalpa Sankar**

[11:18] Like, there wasn't any...

**Emil Eifrem**

[11:20] No, so we, we coined the term. We took the word, like of course the concept of graph has been around since the 1700s, so Leonhard Euler and all that kind of stuff, right? And of course database existed but we put the word graph and database together for the, for the first time ever. And it was not the first thing we, we, we tried, right? We first tried a network oriented database and that didn't really work. And then we tried NetBase. It's like a network plus a database. It's a NetBase. So actually the first talk I ever did publicly, it's called Neo and NetBase or something like this, and that didn't work either.

[11:57] And then I was hanging out with a, with a friend of mine, mine who, who went to business school at Harvard, and he was talking about this unknown site that only he and his friends were, were using - And on the landing page of that site, they said, "We are a utility for the social graph." And it was like, man, graph. I've been avoiding the use of the word graph just because when you talk to most human beings about graph, they think an X and a Y. It's like it's a chart, right?

**Prukalpa Sankar**

[12:27] Yeah.

**Emil Eifrem**

[12:27] That's what people think. So I avoided that. But as a math geek, I kind of thought of it as a graph, right? Or a network or a graph, right? But then this dude, whatever his name was, my friend's friend Mark or something like this who built this - Great friend... This site. Yeah. Yeah. He called it utility for the social graph for this consumer offering, a student consumer offering. Of course, the name of this site was like the facebook.com. It was like, okay, if he can do it for like this consumer offering, I can do it for my ultra-geeky developer kind of centric thing.

[12:59] So then we tried graph and database, and it just took off. It just resonated with people, right? And so that was the kind of the OG category naming story.

**Prukalpa Sankar**

[13:12] Got it. Very cool.

### 13:15 Where Graph Won

**Prukalpa Sankar**

[13:16] And maybe I have a question from, from that time because I don't know, actually the first data science application I ever built was on a graph database. This was like, what? Probably like twenty twelve, twenty thirteen, like around then. Like it was like, you know, the. And I remember the idea was always, it was always fascinating. Like, you know, like you're right. Like, you know, almost everything in the world has relationships and if you're able to model relationships like, and your data is just structured through these relationships like it, it, it logically makes sense. It looks cool. It demos beautifully. But, but somehow it's never... It's been, it's been niche, niche ecosystems like pre-AI.

[14:01] Let's talk, just talk pre-AI. Like niche ecosystems that have picked, picked graph as the core application database. I'm curious, when you started, was this your point of view? Meaning like did you believe that there are some niche use cases where these make niche, niche is like the wrong word, but like it's been some use cases that it makes, makes sense. Other use cases we will continue to model data in tabular formats. What were your learnings through this journey building Neo4j pre-AI?

**Emil Eifrem**

[14:30] Yeah. So I'll have two kind of layers to my answer here. The first one is we always had this view around polyglot persistence. In other words, in other words, we had lived in a universe where the answer was always relational database. The answer was Oracle or Sybase or Informix or Db2. It was a vendor choice, not a type of database choice, right? The one size fits all database. We thought the one thing we were like adamant about was that this era is over forever. It'll never be just one type of database ever again, right? But that didn't... We real, real legitimately meant that. It didn't mean that we thought everything was gonna move to graph.

[15:16] But we thought there was a certain set of use cases where graph was superior. So that's kind of my first level answer. For the next level, a little bit double click on the nuance here is that maybe at some high level you can, you can say that there's two buckets of, of benefits of using a graph database. One shows up at runtime, right? So this is things like query performance and scalability and, and, and things like that, right? Okay, if you have deeply connected data, you're able to traverse it much, much, much faster than you can in any other type of database, right? Those tends to be like very objective.

[15:49] You can measure them in milliseconds and numbers of cores and, you know, stuff like that, right? So very, yeah, very objective. Then the other one is kind of how I started, like this impedance mismatch where it's like going from my domain model to the data structures exposed by my underlying data infrastructure and like minimizing friction there, right? And one of the things that I used to do, and in fact people here on the, the webinar, you can go into Google image search right now and then... In fact, the two of you should do it.

[16:24] Don't, don't close down the webinar, please, but go into Chrome and then you search in like Google Images and you search for domain model. Domain model, right? And then what you'll do, just scroll down the list. Keep scrolling. What you're seeing right now is page after page after page after page of graphs. You go to the Wikipedia page for domain model, it's a big ass graph, right? And so we know most domain models, to your earlier point, Prukalpa, are graphs, right? Most of them today are not stored in Neo4j or any of our kind of graph database friends. So what's the mismatch here?

[17:02] Well, it comes back to what I said around the quantifiable nature of performance. So the earlier use cases that we won for the first, call it ten, fifteen, twenty years, right? So early for a while, right? Were the ones where we were truly antibiotics, right? So what I mean by that, the pain is so acute you have to solve it. You have to be able to deep traverse, right, at, in real time to solve a really important business problem like fraud detection, right? Or finding like a customer journey thing and doing that not in minutes or hours, but in subsecond, millisecond response time type of thing, right?

[17:40] And for those, those were the first use cases that ended up going with, with graph databases. But what we've been doing year by year, you know, day by day, year by year, we've been reducing the friction of how do you model data in a graph? How do you get in there? And so every year there's more and more of those use cases. We're like performance, yes, that's good. But really I just use it because it's easier to think of my data as a graph, right? And that's fundamentally a activation energy versus product surface -type equation, right?

### 18:12 AI Helps Graph

**Emil Eifrem**

[18:12] And every time we, you know, we reduce the friction in the product surface, and there's an AI story here that is amazing that I'm dying to talk about, right? So that the same activation energy will spill over in more use cases. So that's the nuanced answer to that to that question.

**Austin Kronz**

[18:29] Yeah. I, I think you might be alluding to it a little bit, but what has AI done to make graph more accessible? And then the flip side of that question would be how does graph then help AI?

**Emil Eifrem**

[18:40] Yeah. So let's talk about how, how AI helps graph before we talk about graphs help AI. If you peel away kind of all the, the noise in the system once someone is curious about a graph database for their particular application, there's two pieces of friction, right? Primary ones. The first one is how do I model my data as a graph? And the second one is how do I query? Because I know I'm not gonna use like a SQL because it's a new type of, of, of, of data database which requires a new type of query language. Turns out both of those get, if not eliminated, significantly reduced, like the effort to do that with AI.

[19:23] So today you can log on to, Aura is the name of our cloud service, and you can point it to your Postgres database or your Snowflake or... Well, let's start with like Postgres, right? And it'll go in, it'll find the tables, it'll look at your data model, it'll convert that into a graph. All the, the popular database data models are what's called isomorphic. That means that you can take data in one of them and transform to the other without losing data. So that's true for the relational model to property graph. So that happens automatically today.

[19:58] You're just gonna get a graph model, which is really cool, and then you can say I wanna tweak it a little bit," and this and that. But even cooler is that you can point it to your Snowflake or your Databricks, right? Which are column family-ish, so they don't have foreign keys. But even with that, AI then helps and says I actually think it's gonna be connected to this one." And it's one of those things where it gets you eighty percent with the models a year ago, probably ninety percent today, and it'll probably never get to a hundred percent for all use cases, right?

[20:28] But very, very close, and it gets you out of this blank sheet of paper where you have to like start to model your data from scratch. So that's kind of the one piece, which is modeling your data. And AI, thank you AI for that one. And then of course, the second one is kind of obvious, right, which is our query language is called Cypher or GQL. It's the second standard ever for databases. The only formal sibling to SQL that has been formally blessed by the, the ISO SQL committee. So SQL and GQL. And to speak it, of course now you can just speak English to it, right?

[21:04] Then you have some kind of a conversational whatever text to SQL, the text to GQL or text to Cypher, you know, type, type thing, right? So all of a sudden the two major kind of barriers to adoption for graph databases are just, they just look completely different today compared to even twelve to eighteen months ago.

**Austin Kronz**

[21:24] That's really helpful. Thanks.

### 21:26 Reverse-Engineering Ontology

**Austin Kronz**

[21:26] So Prukalpa, I think some of what Emil was saying on the pointing to data in like Snowflake and, and Databricks, for example, and people wanting to map that, I think we've seen similar opportunities with AI essentially giving a better map of the data estate, but then also broadening that aperture or widening that aperture to more of like how can we build an ontology for the entire business and not just an ontology to navigate the data estate. Curious your thoughts on that. There's a lot of questions in the chat too about, "Hey, I have my org data in Snowflake," or some... I saw another question saying, "Well, what about Snowflake?"

[22:05] So there's a lot of question about kind of enterprise data in these cloud providers.

**Prukalpa Sankar**

[22:10] Yeah.

**Austin Kronz**

[22:11] Prukalpa, just thoughts on that.

**Prukalpa Sankar**

[22:13] Yeah. I, I would agree with sort of what Emil said, but maybe in a slightly... Like, I think in some ways, Emil, what you've seen with data modeling and, you know, the, the access there, I think we have seen that from a business modeling perspective, and in many ways the domain model or the business model which is really what the ontology in many ways the, the ontology - I was gonna...

**Emil Eifrem**

[22:34] Here come the O word. I feel the O word coming up here.

**Prukalpa Sankar**

[22:36] Yeah. The onta - the ontology has to... We have to like, we have to go to the ontology and the knowledge graph soon. But the biggest challenge, like ontology has existed for many years. It has existed for like decades as a business problem. And ontologists, like there have been careers that have been built around this. The challenge with ontology, which is, the way I like to think about it, is it's a representation of your business, right? Like it's a business... It's like a business representation of the concepts of your business and how your business connects. The challenge with it is it's always been really hard to build and maintain.

[23:12] And so again, people would do it for these one-off use cases or, you know, it has to be an important enough business problem to go invest. In fact, when Palantir... This is one of the reasons why Palantir's ontology, though when they use the word ontology, it's a mix of ontology and data modeling that comes down together, but it's one of the reasons why Palantir always has deployed application by application, not like it's... They've There's never like a full-blown company-wide implementation of, of Palantir, right?

[23:42] And what we have seen is actually if you are able to now take this data graph of a company, so you're able to connect Snowflake and Databricks, but also where does this come from, from your systems of record? Where does it go from your business applications and your BI? You start stitching this together through like lineage an end-to-end lineage, and then you actually build harnesses on top of this to start saying, "Can I now go reverse construct what my business actually looks like and means?" Reverse construct - Semantics and semantic models and how they connect to each other. Take that and reverse construct the ontology.

[24:23] We are seeing incredible success of being able to reverse engineer an ontology. Actually, as of, as of this week, I have results from, like, one of our first official surveys on our ontology creation, and we had ninety-three percent that we surveyed basically said, "I can just use this as is," like, without changes.

**Emil Eifrem**

[24:42] That's amazing...

**Prukalpa Sankar**

[24:43] And that is all AI, AI-generated and then passed to the human for human on the loop. And the, the a a large part of this, I think from a challenge perspective we have seen is it's not about create. Like, you and I can throw, like, tables into Cloud Code today and be like, "Can you create an ontology?" And it's gonna create something that looks beautiful but it's not gonna be accurate. And so a lot of the work has been actually taking a lot of data quality principles from the you know, pre-AI world and bringing it to what we call context quality, and context quality in a pipeline, so you can actually drive accuracy, yeah.

**Emil Eifrem**

[25:21] I think that makes a lot of sense. I'm blown away by the ninety-three percent. That's, that's amazing. What we've seen is it's, it's kind of the classic AI thing of bottom up produced by AI meets top down either some kind of more prescriptive design or just human in the loop type review kind Yeah... Kind of thing, right? If ninety-three percent can use it completely, just drop it in, that's, that's very cool. My guess, my guess would've been more like fifty, sixty percent. But that's, that's...

**Prukalpa Sankar**

[25:59] Yeah, I think that's where the... What's been powerful is because of the data graph that connects into business systems and business applications, there's a lot of reverse engineering that, that goes into it to be able to, like, push up the accuracy. Which is maybe... This is maybe a good point to, like, come deeper into, right? Because I see a lot of questions in the, in the chat about ontology, knowledge graph, graph database and context graph.

### 26:22 Defining The Terms

**Prukalpa Sankar**

[26:29] I think we should spend some time conceptually on these topics, right? Like, which is, like, what is the like, what is the ontology? What is the knowledge graph? Is every know - like, does every knowledge graph need to be a graph database or not? I'll, I'll let you start, Emil. Like, you've spent a ton of time with them. I can, I can also dig in from there.

**Emil Eifrem**

[26:48] Yes. I've spent my life on this.

**Prukalpa Sankar**

[26:50] Yeah. Yeah.

**Emil Eifrem**

[26:51] So That is what... Yeah. Look, I think the, the terminology thing, right, like I guess going back to where I started, right? Like, the, the power of using graph database as a term instead of NetBase. NetBase just didn't work. No one was interested. Graph database, it just clicked, resonated with, with, with the market, right? So I think that is important. I do have some kind of terminology fatigue right now because exactly to your point, like everyone is just throwing these terms around meaning similar, but subtly or maybe very starkly different things. There's definitely... You know, there used to be cloud washing back in the days.

[27:34] I feel like we have some version of ontology washing going on you know, as, as, as well, right? Where it's like... So, so there's just very crowded, but maybe the most important thing is focus on kind of the substance behind the words, right? And I actually completely agree with your, your description of ontology, right, which you said something like it's a way to make sense of your business, the key concepts and entities in your, in your business and how they relate. And I usually kind of add a prefix. I, I call it the business-facing ontology, right?

[28:09] So that we describe it in a way, like your, your colleagues and employees, like, how do they talk about the, the, the business? It turns out that agents think in the same way that the business thinks. They don't think cust_f_name. No. They think, "I need the first name of the customer." You know, that kind of thing, right? So the business-facing ontology describes that, that, that piece, right? And there's other ontologies too, and I think some of them are, are important, but we can get back to that that later. Just kind of trying to go through the, the list of terms that you, that you took out, right?

[28:44] And then a knowledge graph is fundamentally taking those concepts, I have customers, I have insurance plans, I have pensions, I have shopping carts, right? And taking those in that meta level, the schema level, right, that abstraction, a class level if you're a programmer, that kind of thing, and adding the instances, right? So these are adding the object if you're a programmer, or the rows would be the equivalent, right? Like the, the up here, the ontologies, the tables, and then the rows are the instances, right? Like, so adding that into it, and then you get the knowledge graph. You can take that, and you can represent that in various technologies.

[29:25] I just mentioned before that, like these database, the, the popular databases, database types today are all isomorphic which means that you can take any data, and you can store it in any type of database. You can store it in Mongo or Postgres or Oracle or DynamoDB or Neo4j, right? And a graph database then is a database, a classic OLTP, could be OLAP, but we will get there as well, but a classic transactional type database, right, that can store your data, that you can write applications to, that has a query language. But it rather than exposing a relational data model with rows and columns, it exposes one with nodes and relationships between nodes.

[30:10] What we've popularized is called the property graph model. There's another type of graph representation called RDF, Resource Description Framework. Typically, they're called triple stores or, or quad stores, right? But so that's what a, what a, what a graph database is. And then lastly, you mentioned the word context graph, which is like, okay, WTF is the context layer, I'm the graph guy. It's like us getting together, having a kid, and it spits out the context graph, right? And we can argue again with the appropriate of the name, maybe a more accurate name would've been something like decision trace graph or, or something like this, right?

[30:52] But this was popularized by a blog post by Foundation Capital in December of, of last year. And it's a really strong blog post talking about the, the power of systems of record that store the present, what's true right now in my business, and the data warehouses that stores the past, what's my history, right? But where's the why in all this? If there's a customer in my CRM, a $50,000 customer, that's in my CRM, my system of record, and I have the history in my Snowflake or Databricks or something like this, BigQuery, right? But what's the why behind? Why is it 50,000? That's actually a discount. Why do we apply all this discount?

[31:34] There's some kind of a decision chain that made that happen, and in the old world with wetware, like, or in human beings, right, then there's like a phone call to sales VP that said, "Yes, I, I approve this discount because I'm breaking into this new vertical," or whatever it might be, right? Well, if our goal is to automate more and more business process, being able to empower agents to do more and more of those, right, then having the why is really important. And what's the why? It's the decision traces that the agents leave behind, and that is what, you know, Jai and Ashu, they, they coined the term context graph for.

[32:19] So that's my best shot at disambiguating the, these terms, but feel free to chime in and, and, and disagree.

**Prukalpa Sankar**

[32:28] Yeah. There, there are two places where I think the context graph, and then maybe the knowledge graph I'd love to, like, dig in on, right? I'll start with the the knowledge graph. And so from what, what you said, and it's, like the way I like to think about this is let's go back to that question. Dana calls and says, "I want a refund." And to be able to answer that, you need to know, like... Firstly you just need to know, like, oh, Dana is a customer. Customers are connected to refunds. Refunds are connected to networks.

[33:03] Networks are, like, I just need to know the conceptual mapping of this to be able to reason to and problem solve something. And then there's actually a physical manifestation of this, which is I need to know Dana is a customer, which is a high loyalty customer, who just recently had a network outage. Like, there's a physical manifestation of this. A lot of that data might be stored in lots of different places, right? So it might be in a CRM, it might be a... So like there's all these layers of, of multiple data sources that exist. What.

[33:38] And then there's actually the physical manifestation of if all of this data is stored in one graph database, like, that's the physical manifestation of when a graph database becomes the traversal paths. But a knowledge graph, it sounds like, is one layer above that where you can, you can actually build a knowledge graph without necessarily needing to manifest your data in a graph database. Is that - Yeah... Is that how you see it?

**Emil Eifrem**

[34:05] I, I complete - I completely agree with that. Right now you can make it in memory for, for example, right? Or you can, you can store it on disk and just drop it on, in S3 buckets and, and it's all a matter of that's when you get into the classic consultant it depends answer.

**Prukalpa Sankar**

[34:20] Yeah.

**Emil Eifrem**

[34:21] Right?

**Prukalpa Sankar**

[34:21] Yeah.

**Emil Eifrem**

[34:21] Now, what I will say as the, the founder of Neo4j with this shirt, our intent certainly is for Neo4j to be the easiest path for you to store your knowledge graph, certainly at some amount of scale, right? Like, if you want, if you have a non-trivial, if you have 1,000 nodes and this and that, it actually is pretty convenient. You get, you get all these visualization features and stuff like that, which could be very, very helpful, right?

**Prukalpa Sankar**

[34:46] Mm-hmm.

**Emil Eifrem**

[34:47] But, you know, you get beyond that, then there's stuff that is very hard to implement even in this vibe coding universe, right? And our goal is to make our platform the easiest possible way to make the, in your terms, the physical manifestation of that, of that knowledge graph.

**Prukalpa Sankar**

[35:05] Yeah. Yeah. And so maybe let's spend some time on that, which is like, I think there was a question on, like, what is... Why is graph important in AI?

**Emil Eifrem**

[35:12] Yeah. I feel like we didn't...

### 35:14 Graph RAG

**Emil Eifrem**

[35:14] I only answered Yeah... How has AI helped me, not Yeah... How is graph kind of you know, enabling new and cool things in AI.

**Prukalpa Sankar**

[35:26] But what is it? What, what, like - Right?

**Austin Kronz**

[35:32] I'll, I'll try to give some, some, some background, maybe some structure to help you rather than just tell us all the things about AI.

**Emil Eifrem**

[35:38] Well, I'm, I'm happy to just riff, by the way, but, but go ahead, Austin.

**Austin Kronz**

[35:41] Well, I was gonna start with, I was rewatching your presentation from a year ago at the World's Fair conference where you were talking about... It was your first, like, graph RAG kind of conversation - Right... Where you were talking about the evolution search and then, okay, yes, we have RAG, It was actually two years ago. Two years ago. There we go.

**Emil Eifrem**

[35:58] Yeah.

**Austin Kronz**

[36:00] Walk us through maybe that point, 'cause I think that's right where, like, agents, basic RAG structure started to come into play.

**Emil Eifrem**

[36:05] Yeah.

**Austin Kronz**

[36:05] And now we're in a much more sophisticated world, so maybe walk us from there Yeah... Just the overall context and memory that - Love it.

**Emil Eifrem**

[36:13] Love it...

**Austin Kronz**

[36:13] That you're - Yes.

**Emil Eifrem**

[36:13] Good, good structure. Thank you, Austin. You I'm, I'm... You have a good structure brain.

**Austin Kronz**

[36:17] I contributed something. There we go.

**Emil Eifrem**

[36:17] Someone says you worked at Gartner or something like this. So, so let, let me give you an answer in three parts And I'll pause between two and three just so that we... I, I don't monologue for, for, for too long. So first of all, on a kind of more philosophical level m-maybe, right? I think there's something really intrinsic in this way of expressing data that is very knowledge centric. There's a reason it's called knowledge graph, right? And if you think about what knowledge actually is, I think knowledge is how do you learn a new concept, and you learn that by associating it, associating it to previously known concepts.

[36:56] You all here on this webinar are trying to figure out w-who is this guy, right? And as you hear me speak, you're pattern matching to other things, and you hear me talk about databases, you need to think about other database people. You hear my Swedish accent, and you think ABBA and IKEA, and you look at me and you're thinking Brad Pitt and Tom Cruise, and like, you're associating like, like this, right? And so that is by relating me to previously known concept, you understand new things, right? And that is showing up, up and down the stack, right?

[37:26] And so retrieval, which you referred to, Austin, and that is my, my second, the second piece of my answer. I'm gonna talk about retrieval and graph, right? Retrieval was the first one. But memory, turns out, is also very graph oriented. A very hot term right now is graph engineering, kind of as the plus, plus of loop engineering, right? And up and down... And context graph we just mentioned. So up and down the stack, graph and AI seems to be this really, like, intimate fit, right? So that's kinda the first one. More concretely, the second one is scoped to a single application or a single agent.

[38:03] And then my third, the third level of my answer is gonna be what about enterprise wide? Does graph have a role to fit in an enterprise wide thing, right? And how does that relate to the con-context layer? So let's, let's s-save that one for a little bit later and start about the, the atom of a single application. So it turns out that retrieval, everyone ended up defaulting to vector databases for a v-variety of, of, of reasons. And vector databases are good. Vector search is powerful because you can do semantic search, not just keyword search.

[38:34] But it turns out that for many applications, getting the top 10 documents back from your retrieval path using semantic search was insufficient, right? And if you think about it, the use cases that we're trying to solve for here is something like you have some kind of an agent. It needs to get data typically out of unstr - some kind of combination of structured but very much unstructured data sources. So let's use the classic support use case. I think that's the one that I used in the, in the talk two years ago, I, I, I believe, right? So then you have, like, your, your, your support articles, right?

[39:11] You might have tens of thousands or hundreds of thousands of them, and they're written by human beings 'cause it's been around for a while, right? Who've written all these answers over the years. And then you have an agent, and you have someone chatting saying, "My Wi-Fi is down," right? "I'm connecting through my cellphone hotspot," or something like this. Otherwise, how can I say that my Wi-Fi is down? Right? And, and they say, "Hey, my, my LEDs are flashing yellow. What's going on?" Right?

[39:37] And then the agent has to find out of 100,000 docs, find the top 10, 10 docs, right, that are most likely to answer the question, hand them off to the LLM to summarize, right? And then when I say 10, it could be five, it could be 15 or 20, but it's not 10,000. Even with long context windows, it's not 10,000, right? So let's call it top 10. It turns out that just using semantic search for that gives you some amount of accuracy.

[40:03] But if you think about that use case or that what we're trying to solve for here, we've actually done a massive case study of this before, which is, Austin, you mentioned web search and stuff like that, and it's the it's, it's Google, right? Which it's exactly the same thing. I type in some kind of intent as an end user, give me the top 10 blue links, right? And for those of you who are around, many of the h-here in this call won't remember, but there was a, there was a universe before Google. We had AltaVista and Yahoo and Excite and Hotbot and all these d-different things, right?

[40:35] And the problem was typically whatever you searched for, you got too many answers, and the right answer was, like, on page 93, right? That was the problem. You got too many answers.

**Austin Kronz**

[40:45] No, I had, I had never heard of the AltaVista effect until Yeah.

**Emil Eifrem**

[40:49] It was the AltaVista effect. That's exactly, right? And so Google, how did Google solve that so that we always got the right answer in the first top 10 blue links? It's by using PageRank, which is a graph algorithm where they link the documents together, and you have different weights depending how influential your web-website is and so on and so forth, right? And so it goes to say that if you apply the same principle to retrieval for agents, you should get much higher accuracy. So that's the fundamental thesis, and it's called GraphRAG. It gives you this higher accuracy. It actually gives you faster time to develop because vector search is completely opaque.

[41:30] You only know that these two things are 0.7 similar or 0.3 similar. With a graph, you see that it's an apple and an orange. They're similar because of their fruitness, right? So you have explicit data structures, not just implicit neural search. And then the third piece is it gives you explainability and auditability, right? So those three things are really powerful benefits when you work inside of an enterprise with the scope of a single application. If you think about, call it 95% of the usage, that's a non-scientific figure, but the vast, vast majority of what we see today in terms of AI and graphs, it's using it for retrieval with GraphRAG.

**Austin Kronz**

[42:13] Emil, that's really - That's my second.

**Emil Eifrem**

[42:14] And then there's an enterprise-wide version of this that we can talk about as, as well, but l-let, let, let me pause right there.

**Austin Kronz**

[42:20] Yeah, that's really helpful. And I will say you must have given that talk a lot because I think that was verbatim part of that presentation, It was really not.

### 42:27 Memory And Skills

**Austin Kronz**

[42:28] Yeah, it's very good. Yeah we only have a a few minutes left and I know you wanna talk about memory, so if I could just add to that use case.

[42:35] So I built this great graph rag support agent that can help with my Wi-Fi router issue, but now we've obviously had it run for some time and we want it to do more. So we've given the agent more tools, we've given access to more systems. People start to ask for certain things and now there's patterns emerging. So maybe how does graph now start to talk or handle things like memory and get into the context graph kind of situation?

**Emil Eifrem**

[42:59] Yeah. So we mentioned this before turns out that memory is an intrinsically graph centric workload and lots of people have independently come to this conclusion who don't work at Neo4j, don't wear a Neo4j shirt, right? I tend to look at the world like, man, there's lots of graphs out there. But like for example, people don't know this but like MCP shipped with an an an, memory implementation in the initial MCP spec, right? And this is hard to say, it's an in-memory memory implementation. So it's an in RAM AI agentic memory implementation, and it's a toy. It's 500 lines of Python code, right? But it's a graph, right?

[43:37] And there's a ton of startups that are building agentic memory on top of, of Neo4j right now. Folks like Cognee or Zep and Mem0 and, and, and so on and, and so forth. Lots of our customers are doing this with those components offered by, by these startups or doing it themselves. And what ends up happening is that you leave the agentic traces in the graph and say, "Okay, I walked this path to make a decision," right? And then typically what ends up happening after that is that you have a skill distillation after as a background process running that distills out, okay, these were the key learnings in here. That's not always how it's done.

[44:21] Sometimes you compute it as a score on in the graph, right? But the, the more common one over the last, call it six, nine months as skills have taken off, has been to distill that as a background process into a skill. And what's really cool is that you can then ground that distilled skill back to the memory elements. So as your memory is evolving dynamically, you're, that's, you can detect that the skill is stale, right? And that I think is a really really important feature of, of, of memory.

**Prukalpa Sankar**

[44:56] Yeah.

**Austin Kronz**

[44:56] That's great. Well, I know we're, I know we're at time and so I'll, I'll pose a question to each of you. After everyone leaves this, this episode and they first of all take a deep breath and think, "Wow, I can't believe how awesome that was and how much I learned." When they actually go back to their, when they go back to their desk, their laptop, wherever they might be working from, what, how would you say here's the first thing you need to either think differently about how you're approaching AI or here's what you can do the rest of the week to kinda get started to improve the agents that you're building?

**Emil Eifrem**

[45:27] Yeah. Prukalpa, I, I've talked... Do you wanna go first and then happy to go after 'cause I've talked a lot. Yeah.

**Prukalpa Sankar**

[45:34] Yeah. I'd say mine would be I feel like our world is getting really stuck up in terminology because humans actually can... Like, it's actually very, in, in many ways you can, you can, it's, it's a easier, less, less abstract problem to solve to say, let me figure out how to build a semantic layer or let me figure out how to build... Like, these are like, you can attach yourself to it, you can build capabilities around it, and you can say, "Let me go do it." And you can spend quite some time and we can all feel happy about doing these things.

[46:06] I think the challenge is that the harder problem is how do we actually start having our businesses actually get value from AI? And right now I think actually I, I, it would really suck to be a real practitioner I think in like real life 'cause like every vendor is like termin - like, you know, terminology washing like everything. And so my core note is to, to people is like let's just like be focused on the problem. The reality is that technology is going to change. Like let's talk about retrieval. My, my sense is that all versions of retrieval that happen today are going to change dramatically in the next 12 months, right?

[46:43] Like every harness retrieves differently. Claude code itself retrieves skills 49% of the time, whereas Codex retrieves skills like 99% of the time, which is insane given that skills was like an anthropic construct. You know, skills retri - like skills retrieval is an open problem. Should you retrieve via graph? Should you retrieve via keyword? There are trade-offs in all of this. All of these challenges I think we're in early stages of technology evolution. They're going to change over the next, next couple of years. I think in this time focus on a business problem and find the best solution to the business problem and then work backward with all the other concepts and terminology.

[47:23] I think that would be my one, one advice on, on driving value with AI.

**Emil Eifrem**

[47:28] Yeah.

**Prukalpa Sankar**

[47:29] And the second one is build yourself personally. So if you have not built yourself personally, build yourself. You have to build yourself personally.

**Emil Eifrem**

[47:37] Which is a lot easier these days with all these amazing AI tools. Yeah, I completely agree with that. What I was gonna say is we didn't have a chance to talk about the enterprise wide, like the where graphs I see like a really exciting use case for it. So I'll, I'll choose the self-serving one of there's a great blog post written by Jesus Barrasa who spends every day working with the top customers in the world on implementing graphs and AI.

[48:12] So it's completely from a real world pragmatic and it talks about this knowledge layer and again, completely echoing what you said, Prukalpa, like terminology aside, I think the, the concepts are really important, like the three pillars that I think is needed for anyone wanting to build out this glue between your Disparate, messy enterprise data landscape or large organization kind of data ecosystem, and agents reliably at scale, right? I think this is then... If we had more time, I would have loved to to compare this picture to the picture you guys shown at the front, because I think there's lots of similarities, but some differences, and what are they?

[49:01] And like to kind of compare and contrast, right? But this - it's a great blog post that you know, obviously is from a Neo4j point of view, right? Because it's shaped by the, the customer conversations that, that we've had.

### 49:16 Where They Disagree

**Emil Eifrem**

[49:16] But it certainly isn't Neo4j centric. It, it goes beyond specific implementation. So I don't know if we can send a, a link to this. Can I chat? I don't know if I can.

**Prukalpa Sankar**

[49:25] Yeah, you can.

**Emil Eifrem**

[49:26] Okay. So I'm gonna, I'm gonna put this blog post in here.

**Prukalpa Sankar**

[49:32] Yeah. I think maybe like I think the place where we'll converge, I think we'll converge on the concepts of what context like what, what AI and what AI needs for context. I think the place where we might diverge is what does it need to be physically manifested in? Like I... Like, my thesis on this is I'm convinced AI needs relationships. Like graph, graph theory, AI needs 100%, it'll make AI better. Do we need to manifest all of this in a graph database? And in fact, you and I have spoken about this around, like some of the things around graph engines and where the world...

[50:12] Like what, what could happen, and like are there different manif - Because moving data by itself is friction, and there's, data has gravity.

**Emil Eifrem**

[50:19] Yes.

**Prukalpa Sankar**

[50:20] And so I think that might be the place where I think there, there might, like we might differ on like what is the right implementation from a, from a a physical manifestation perspective.

**Emil Eifrem**

[50:31] Which is why this little box here is so important. So this virtual graph box means - Yeah... You can run the entire Neo4j product portfolio on top of your Snowflake or on top of your Databricks, right? And so with zero-copy architecture, no need to move anything, right?

**Prukalpa Sankar**

[50:50] Yeah.

**Emil Eifrem**

[50:50] Which is just really cool. Yeah. I mean, and then the... I think what this one comes down to is how import... I, I, I think that question what it comes down to, how important Yeah... Kind of low latency multi-hop traversals in, in some kind of orchestrated step-by-step business automation process, right?

**Prukalpa Sankar**

[51:16] Yeah.

**Emil Eifrem**

[51:16] How important is it to be able to go deep in across your entire data, data landscape in real-time, right?

**Prukalpa Sankar**

[51:23] Yeah.

**Emil Eifrem**

[51:23] I think that's what - Yeah... What it comes down to. When is that important? When is that not, not, not important?

**Prukalpa Sankar**

[51:28] Yeah. Yeah. Have you been track... I'm curious, Emil, you've been, have you been tracking some of the, like there's there's some development on Iceberg, on top of Iceberg and like can we have graph engines on top of Iceberg? What is your sense of where this is going to go? Where is the technology going to go in terms of graph traversal in the future?

**Emil Eifrem**

[51:45] Yeah. Yeah.

**Prukalpa Sankar**

[51:46] And what are you, and what are you excited by and also what are you tracking?

**Emil Eifrem**

[51:49] I'm really excited about this one, right? And so I... When you and I talked a few months ago, six months ago or something like this I said I love the theory of it, but the, the implementation isn't quite there yet. We've been hard at work at this one, and I don't think it's perfect yet or anything like this, right? But we are building out this virtual graph box that I talked about, right? And it's in, in early access right now. So it's available, it's running. You can get to Aura, you can just point it to your Snowflake, bam, you're up and running. Zero copy, right?

[52:24] And there's a few principles that we think are correct, and we haven't seen anyone do, like, these things, you know, properly. One is full ecosystem integrated. So I think it needs to have the entire breadth of all the stuff that you want out of a graph database today. All the connectivity, all the visualization, all the programmatic drivers, everything. Like all the AI-assisted tooling and so on and so forth, right? So that's kinda one piece. And then this zero copy architecture, that's really important. So like our approach here is push down predicates, right? So that means you type your, your query, typically in English, gets translated to Cipher or GQL, right?

[53:04] And then that gets pushed down into your data warehouse, right? So it actually is on petabyte scale on real live data, right? So that's very cool. That's the second piece. But then you also want this slider, and this slider we're hard at work on right now, so we don't have that right now, where you can start all the way over in zero copy architecture land, and then you can slide it over. I wanna materialize some of these views for low latency and performance, right?

**Prukalpa Sankar**

[53:32] Yeah.

**Emil Eifrem**

[53:32] This thing, I wanna be able to jump 10, 20 hops in milliseconds. I, I... And then it pre-materializes that into a graph, like a fully native graph database under the hood, right? It could also be in memory, like ultimately it doesn't matter to you, right? And, and I think those three things, no one has done well so far. We have the the first two, the third one we're we're, we're working on right now.

**Prukalpa Sankar**

[53:57] Is it working, Emil? Like what is your sense? Like virtualization, data virtualization has been, again, one of those things that people, in theory, people love, but on practice it's really challenging to scale. Like what is your sense on where we are in terms of technology breakthrough?

**Emil Eifrem**

[54:13] Yeah. So it is certainly working for some of the use cases, but it's, it's back to like a broader theme that we've talked, you and I have talked about many times, and we've talked about here on this call, which is there's no one size fits all. There's no silver bullet for, for everything. Certainly you won't be able to run this on top of your Snowflake and that'll work for everything. My deep fraud detection in real time that turns fraud detection into fraud prevention because it works in sub-millisecond 'cause I'm a credit card company. No, no, no, you shouldn't use this virtual graph thing.

[54:47] But if you're okay with a couple of seconds, then okay, this works really well for most queries. Not all, most queries, right? So it's about finding that, and I think that's one of the exciting things over the next - Call it six to nine to twelve months is finding out exactly where are the soft spots of this one, where do you need to move to the kind of materialized one, and where can you leave it in the zero-copy architecture.

**Austin Kronz**

[55:11] Emil, is the, is the challenging part of that just we... It's too hard to anticipate which types of questions we'll need, which route up front?

**Emil Eifrem**

[55:21] Yes, because, like, you end up in this situation, right, where you're solving a business problem, right? And that's what you know. But how do you translate that into, am I gonna do a multivariate multi-hop question in SQL or in GQL? It's like it's very hard to go from that to exactly what type of query loads will, will that actually use. And that's again why I think this slider is important, for ultimately we should fix that under the hood for you. And probably maybe three years from now automatically, but at least for the foreseeable near-term future, it would be you slide it manually over. Okay, this piece I wanna, I wanna pre-materialize, right?

[56:01] 'Cause I'm, I'm a little bit worried about too much magic happening under the hood, like too, too, too much of that, right? So I think that's fundamentally what, what it is about. Look, it took us decades as an industry to understand what's the distinction between OLTP and OLAP, right? And then data volumes exploded so much that it all changed everything about that, right? And so, so it, it, it takes a while for this thing, I think, to to stabilize and become internalized in, in, in people's minds.

**Austin Kronz**

[56:30] Gotcha. Well, I, I know we're way over time, and I'm pleasantly surprised that most people have, have stayed, so if not, we do have a recording of this and people will be able to watch. But I, I guess I, I can't thank you both enough. I mean, I've really enjoyed this conversation, and we could probably talk for another two hours about these things. Maybe at some point we'll have a, a recurring guest, Emil, come on and just give a status update on the graph space.

**Emil Eifrem**

[56:53] Would love to.

**Austin Kronz**

[56:55] It at this point, it would probably have to be every other week. Just day-to-day. I am excited - Well, and I also feel bad, like I, I, I've been unable to monitor.

**Emil Eifrem**

[57:03] I just see that there are chat requests coming in. I feel bad. There seems to be a lot of questions that we probably left unanswered, but yeah, maybe that's the driver to, to force you to invite me back.

**Austin Kronz**

[57:16] Yeah, yeah. We'll start to collect these questions. I think thematically we've addressed a lot of them, but there's a couple specific ones for, for Neo4j. But yeah, I... And our next episode, by the way, will be with Jaya from Foundation Capital, so we'll be talking all things context graphs and I'll be sure to tell her everything you said if she doesn't watch this, so no prep for it, but - Amazing... I'm excited to keep this conversation going. Thank you both for joining.

[57:39] Just to recap, it sounds like ground this in real problems and, you know, start to build yourself and run into these challenges and, you know, some of these solutions will start to be the next step in making the agent work. I think the, the story Emil, you've given about kind of like the customer support agent, I'm sure there's multiple iterations of that the companies will go through from just basic human-assisted agents to quite the spectrum of fully autonomous voice agents that are in real time providing refunds. Like, there's, there's quite the spectrum in between there. So I really appreciate the examples, the stories, and, and just the conversation.

[58:12] So thank you both, and we'll, we'll talk soon. It's a wrap.

**Emil Eifrem**

[58:16] Thanks, folks. Wrap.

**Austin Kronz**

[58:18] Thank you.

## Key takeaways

- Knowledge graphs do not need graph databases. Postgres, Mongo and DynamoDB can all hold one without losing anything.
- An ontology is the schema. Add the instances and you have a knowledge graph.
- Agents do not ask for cust_f_name. They ask for the customer's first name, so your ontology has to speak that way.
- Your systems of record store what is true now. Your warehouse stores the past. Neither stores why.
- The context graph would be better named a decision trace graph. What it holds is why a decision was made.
- For twenty years graph only won where the pain was unavoidable, like catching fraud in under a millisecond.
- Link a distilled skill back to the memory it came from, and you can detect the moment it goes stale.
- Claude Code retrieves skills 49% of the time. Codex, 99%. Skill retrieval is still an open problem.

## Blog article: How Do Graph Databases and the Context Layer Fit Together?

Graph has had three waves of attention. First the Gartner years, when every analytics vendor shipping natural language query got asked whether it ran on a knowledge graph. Then COVID, when the companies with a graph foundation could trace a supplier problem upstream and downstream while everyone else guessed. Now AI, and every conversation comes back to graph again.

Emil Eifrem has built through all three. He coined the term "graph database" two decades ago and runs Neo4j. Prukalpa Sankar opened with the challenge: modelling the world as relationships makes obvious sense, it demos beautifully, and it has stayed niche for twenty years. They agreed on the diagnosis and split on one question: do those relationships have to be physically moved into a graph database for an agent to use them?

### Q: Graph databases have been around for twenty years. Why is everyone talking about them now?

Two things made graph hard to adopt, and both changed inside the last 12 to 18 months.

- **Modelling.** Getting data into a graph meant starting from a blank sheet. Now you point Neo4j's cloud service at a Postgres database and it reads the tables and converts the model into a graph on its own. That works because the popular database models are isomorphic, meaning you can move data between them without losing anything. Warehouses have no foreign keys, so the conversion is harder there; Eifrem puts the accuracy at roughly 80% with the models of a year ago and 90% today.
- **Query language.** Cypher, now standardised as GQL, is the only formal sibling SQL has ever had, and learning it used to be a real cost. Speaking English at it removes that cost.

"All of a sudden the two major barriers to adoption for graph databases, they just look completely different today compared to even 12 to 18 months ago."

Neo4j's position was always that the one-size-fits-all database era was over, not that everything would become a graph. Graph won where the pain left no choice: fraud detection that has to traverse deep in under a millisecond, or customer journey work where minutes were not an answer. Eifrem calls those the antibiotics use cases. Everything else stayed in tables, even though almost every domain model anyone draws on a whiteboard is already a graph.

### Q: Ontology, knowledge graph, graph database, context graph. Which is which?

"I do have some kind of terminology fatigue right now. There used to be cloud washing back in the days. I feel like we have some version of ontology washing going on." - Emil Eifrem

- **Ontology.** The concepts in your business and how they relate, described the way your colleagues talk about the business. Eifrem calls this a business-facing ontology; his design rule: agents do not ask for cust_f_name, they ask for the customer's first name.
- **Knowledge graph.** The ontology is the schema. Add the instances and you have a knowledge graph. The ontology is the tables, the instances are the rows.
- **Graph database.** A transactional database that exposes nodes and relationships instead of rows and columns. Neo4j popularised the property graph model. The alternative representation is RDF, usually called a triple store.
- **Context graph.** Named by Foundation Capital last December. Your systems of record hold what is true right now and your warehouse holds the past. Neither holds why. A $50,000 customer sits in the CRM at a discount, and the reason was a phone call to a sales VP that no system ever recorded. Eifrem: "A more accurate name would have been something like decision trace graph."

Does a knowledge graph need a graph database underneath it? It does not. Because the models are isomorphic, a knowledge graph can sit in Postgres, Mongo or DynamoDB without losing anything. Eifrem's claim is narrower than the category noise suggests: Neo4j wants to be the easiest place to store one at scale, not the only place one can exist.

Prukalpa's addition: the expensive part of an ontology was never the concept, it was the upkeep, which is why Palantir deploys application by application and never company-wide. Connect your warehouses, trace lineage end to end through your systems of record and BI, and you can reverse-construct the semantics and then the ontology from them. Her caution: throwing tables at a model produces something that looks beautiful and is not accurate, so the real work is applying pre-AI data quality discipline to what Atlan calls context quality.

### Q: What is graph actually doing for AI today?

Almost all of it is retrieval: Eifrem put the share of what Neo4j sees at around 95%. An agent answering a support question has to pick roughly ten documents out of a hundred thousand and hand them to the model. Semantic search alone gets you part of the way. The same problem was solved once before at internet scale: before Google there was AltaVista, and the right answer sat on page 93. PageRank fixed it by linking documents together and weighting them, which is a graph algorithm. Apply that principle to agent retrieval and accuracy goes up.

Two side effects matter as much as accuracy. Development gets faster, because vector space is opaque and only tells you two things are 0.7 similar, where a graph tells you an apple and an orange are related through fruit. And you get auditability, which is why banks and regulators care.

Memory is the second workload. The memory implementation shipped in the original MCP spec is 500 lines of Python running in RAM, a toy by Eifrem's description, and it is a graph. Startups building agent memory on Neo4j include Cognee, Zep and Mem0. The technique worth stealing: agent traces go into the graph, a background process distils them into a skill, and the skill is grounded back to the memory it came from. "As your memory is evolving dynamically, you can detect that the skill is stale."

### Q: Does my data have to move into a graph database?

This is where they split. Prukalpa: "I'm convinced AI needs relationships. Graph theory, AI needs 100%. It'll make AI better. Do we need to manifest all of this in a graph database?"

Eifrem said yes, then described an architecture that makes the answer less binary. Neo4j's virtual graph runs the product portfolio on top of your Snowflake or Databricks with no copy of the data. A query written in English becomes Cypher or GQL and gets pushed down into the warehouse as predicates, which is how it holds up at petabyte scale. It is in early access now.

What does not exist yet is the slider: start with no copy and slide toward materialising the parts that need speed, so a 10 or 20 hop traversal returns in milliseconds from a native graph underneath. His three principles are full ecosystem integration, no copy, and the slider. "We have the first two, the third one we're working on right now."

The limit: sub-millisecond fraud detection, the case that turns detection into prevention, should not run on a virtual graph. If a couple of seconds is acceptable it works for most queries (most, not all). The unsolved part is knowing in advance which is which. You start from a business problem, not from a query plan, and Eifrem is wary of a system that guesses on your behalf; it took the industry decades to settle the line between OLTP and OLAP. Prukalpa's counter stands unresolved: moving data is friction, and data has gravity.

### Closing advice

Both landed on the same advice, and it was not about graphs. Every vendor is washing the same terms, and every current approach to retrieval is about to change. Prukalpa's example: Claude Code retrieves skills 49% of the time and Codex 99%, a fifty-point gap on a construct Anthropic invented. Start from a business problem, solve that, then work backward to the concepts and the words. Then go build something yourself.

## Next session

As listed on the page: **Thu, Sep 17, 2026 / 12:30 PM ET - Can a Context Graph Alone Make AI Reliable?** Jaya Gupta of Foundation Capital, who named the context graph, joins Austin to work through what a context graph must hold and where it stops. [Episode page](https://atlan.com/wtf-context-layer/context-graph-vs-context-layer-for-ai-reliability/)