Full Context Ep. 2: Neo4j CEO Emil Eifrem on Why Data Isn't Enough and What Comes Next
Full Context is a podcast hosted by Animesh Koratana, CEO of PlayerZero. Each episode, Animesh sits down with founders, operators, and researchers building at the frontier of AI and software. Episode 2 features Emil Eifrem, founder and CEO of Neo4j.
What does it take for agents to actually reach escape velocity in production? Not the demo. Not the proof of concept. Real, compounding, self-improving systems operating inside enterprises at scale.
That's the question at the center of this conversation. Emil has spent over 20 years building Neo4j, the graph database that's become foundational infrastructure for some of the most complex data problems in the world. Animesh has spent the last several years building PlayerZero, an AI production engineering platform whose core technology is an engineering world model that connects code, telemetry, and support context to understand how software actually behaves.
They agree on a lot. The data model matters. The shape of context determines what agents can do. And the institutional memory encoded in decision traces is one of the most undervalued assets in any engineering organization.
They also push each other, specifically on whether explicit graph structures are the right substrate for context graphs, or whether the relationships are fundamentally unobservable until an agent actually walks them.
The full conversation is below. Or you can watch the video here:
Transcript
Animesh Koratana: All right. Well, today on Full Context, we have Emil. Emil is the founder and CEO of Neo4j. Emil, thank you so much for coming. I'm really excited about this conversation today.
Emil Eifrem: It's fantastic to be here. Great to do it.
Animesh Koratana: Awesome. So we have a full docket here, some really interesting topics that we're going to be covering, but before we kind of get into the nuts and bolts of Neo4j, about context graphs and more, could you tell us a little bit about how you got here? Who is Emil? Why did you start Neo4j? Why graphs? And kind of what the story of the company was?
Emil Eifrem: Yeah, sure. Yeah. So, I've been doing this for about 438 years, right? You know, at this point, we raised our Series A back in 2011. But we were working on the technology, you know, even prior to that. And it's the classic thing of some combination of like an itch that we had ourselves that we wanted to scratch, right? Along with some amount of maybe analytical kind of thoughtfulness, right?
And the itch we had was that we were implementing what people today would call multi-tenant SaaS systems that were dealing with very complex data. Of course, this is like 20 years ago. So, you know, it was like milli data or something like that, right? Like in comparison to what we see today, but it was very complex. It was changing all the time, was deeply messy, highly interconnected. And, you know, our startup, we had a 20-person engineering team, half of them spent the majority of the time fighting against the relational database.
And this was a big surprise to me, because even though I was pretty young at the time, I'd just been doing software for my entire life, basically. And in all prior projects, the database had been this accelerator, which, like, took this big gnarly problem of, like, storing the data and making sure that it's there, queryable, like, transactional, and online backups in production. It's like all these big hairy problems, right, that I didn't have to focus on so I could build the application.
But that clearly wasn't true this time. Fast forward to today, I think we have, as an industry, we have a clear understanding and a language for it, but we didn't realize that at the time. We just felt it, but there was this mismatch between the shape of the data and the abstractions exposed by the underlying infrastructure. In other words, some whatever round peg, square hole thing going all over the square and static relational model and this super complex world.
And we were young enough and naive enough to, like, we started looking around for alternative databases saying, like, look, what we need here is exactly like the Oracles or the Informix or whatever Postgreses of the world, but just with a different data model, right? And we couldn't find anything.
And that's where the kind of the youth of the naivete kicked in because then we just said, screw it. Let's just build it, quote, how hard can it be? And here I am 20 years later. Turns out building like a fully transactional database, like from a tech perspective, right, and then building a database company, like both of those two things turned out to be really hard. And then we took on category creation, you know, we coined the term graph database like initially, right? And so there's like an end of one when we said those words, right? And so we just decided to take on a lot of big tasks, but ultimately it was that itch that we wanted to scratch ourselves, right?
And then I said there's also like one more analytical thing, which I'll add that layer to it. That was like very pragmatic and practical, but like the one thing maybe where we were a little bit thoughtful was like, on some level, what is data? And, you know, lots of people operate with data and work with data, but like, don't even think what data is. But like, data is a representation of the physical or sometimes the digital world, right? So let's just focus on the physical world. So we describe the world in digital form so that we can operate on it with computers, right?
And so it goes to say then that if the world is becoming more and more connected, which we all felt that was true, then data describing that real world will become increasingly connected. There's going to be an increasing amount of value in being able to figure out how things fit together.
And so we felt there was some kind of notion that if maybe there's only us in the entire world that are experiencing this right now, but like tomorrow there's going to be more and the next day there's going to be more, right? So we felt that maybe there's some kind of a wind behind our back from that perspective.
Animesh Koratana: Well, actually, like I've experientially felt this many times where graphs tend to feel like the right abstraction to model a lot of the world. And so I guess there's a few questions that come from this. First is, at this point, do you feel like you've scratched the itch?
Emil Eifrem: So I do. But of course, the moment you solve it for that shape, then it's like, you find all these and like the world moves on and datasets become bigger and problems become more multifaceted. So, we solved that particular kind of itch, but there's plenty more out there to scratch.
Animesh Koratana: Well, then I guess on the other side then, like in which cases do you feel like relational is still the right way to go versus a graph database? Maybe help disambiguate those cases. Because in many cases actually, and maybe this is a fallacy in thinking about graph relationships, the relational kind of the foreign key, primary key, that sort of thing tends to feel like a natural extension that could help you model graphs.
Emil Eifrem: I think what we've learned, we used to live in this very kind of unipolar, everything was a relational database. Yes, in the '60s and the '50s, there's the CODASYL model and network databases and some other sort. But in reality, for a trillion years, the relational paradigm has been the dominant one.
And then in the last, call it 15, 20 years, there's been new categories emerging. These new ones, at least the established ones, tend to all be isomorphic, right? Which is a fancy way of saying that you can take data in each and every one of them and transform to the other without any loss of information, right? And transform, therefore transform back as well, right?
So in other words, there's no dataset out there that you cannot model in a relational database. And there's no dataset out there that you cannot model in a graph database. So that's no longer the interesting question. Can you do it? The question is, is it a good fit for you?
And to me, then it comes back to like, what's the shape of the data and the queries that you want to run on it? And so my go-to example is if you have a payroll system, every single row structurally is identical to the other ones. It's like, first name, last name, role, hire date, and salary, right? And the query is like either fetch individual rows or like calculate average salaries of people hired in this and that year. You know, that kind of thing, right? It's extremely tabular.
And if you go out there and you talk to domain experts, people who don't know anything about third normal form and ER modeling or any of the things that we've learned, and you ask them to whiteboard their world, if you work with payroll, you're going to end up drawing tables on the whiteboard, right? But there's a ton of domains where when you ask the experts, unless they've been trained to take the conceptual model and break it out into tabular form, that's not naturally where they go.
They say, I have a shopping cart. In that shopping cart, I have order items, and they refer back to my product, which actually sit in a hierarchy, and it builds up this graph.
And so, when you see that, I think that's a good hint that there's probably low impedance mismatch between that domain and the graph model.
Animesh Koratana: Got it. You know, one of my first experiences with Neo4j was when I was like 12 or 13 years old.
Emil Eifrem: It's so amazing.
Animesh Koratana: Yeah, I mean, I think I ran the desktop community version on my laptop. I was always interested in AI and language modeling and stuff like that. This is many years before LLMs, so we were using very different techniques. But we were basically trying to extract entities out of unstructured data and model it as a knowledge base. And we ended up using Neo4j. It felt like the right tool to use to actually model out these knowledge bases. And then more than that, you guys had the little GUI where you could like move the little dots around, and that was the coolest demo I've ever seen.
Emil Eifrem: So, okay, so two comments on that, right? Like, one, that's amazing that you did that at age 12, first of all. Second of all, man, that graph visualization, I can't tell you how many times that I walk into a customer, big Fortune 500, big banks, and what I see is like their domain models printed out. We have this graph visualization tool called Bloom now, which is like a fancier version of that, right? But even Neo4j Browser, which is the more code-centric one with the query language and stuff like that, right?
People just print that. And I've heard so many times people say, oh, by the way, my boss and my boss's boss has this one in their room. And so there's something there where intuitively people look at the graph model and it makes sense to the business people and it makes sense to the geeks like us.
And that's a really underappreciated property. We call it whiteboard friendliness, right? An underappreciated property, I believe, of the property graph model. No pun intended.
Animesh Koratana: Yep. No, absolutely. Well, so actually, maybe transitioning to a broader topic. Thinking about everything that's happening in the market right now. I think over the last couple of weeks, maybe even months now, we've seen a very different view, perception of most of the SaaS vendors that we've seen out there, right? Salesforce, ServiceNow, kind of being like the two prototypical examples. Where the platform shift, as the world is increasingly looking towards AI, looking towards agents to actually automate and own the work, changes the way that you actually value these kinds of companies.
And with it has come this view that value is essentially going to accrue in two far corners of work. It's going to be the infrastructure layer and kind of the lowest layer that it can possibly accrue to there. And then it's going to accrue to the agents that have the expertise and the experience to actually do this work.
And so maybe actually I'm curious, like, Neo4j aside, what is your view on the stuff that's happening in the market right now? Why do you think it's happening?
Emil Eifrem: Yeah, so many thoughts here and it's such an exciting time, right? You know, it's funny, right? Like I've lived through a few platform shifts, right? And I wasn't really kind of fully aware of the shift from mainframe to client-server, right? Yes, I was technically alive, but I wasn't really kind of too plugged into that. But I obviously gave birth to Oracle and then we had the shift from client-server to web, which gave birth to initially MySQL. And then obviously, Neo4j was born in the shift from back to the cloud. And so, I've seen this happen.
But this is where I think it's a platform shift exactly as you said. It's also the fourth industrial revolution, which cloud wasn't and mobile wasn't, and certainly mainframe-to-client-server wasn't. But some version of steam and then electricity and call it computing. And now, now AI. So just feels much, much bigger right now.
And, you know, Buffett. What's the quote from Buffett? Like, the stock market is a voting machine in the short term and like a weighing machine in the long term. I certainly think there's like some over-pivoting going on right now because the stock market hates that uncertainty, and people just choose to stay on the sidelines as this is playing out. So it probably seems, you know, a little bit kind of over-rotation on some of those things, right?
Having said all that, we had firsthand view into like the early version of this because I think it's almost exactly a year ago that Sebastian Siemiatkowski, who's the CEO of the fintech Klarna, he wrote this long-form post. And he was triggered because a few months earlier he had mentioned to investors that we've thrown out Salesforce and Workday. And yes, we pay Salesforce because of Slack, but not for any other reasons. And we've done that thanks to AI productivity. And that generated all kinds of noise.
The next week, someone asked Mark Benioff on stage at a conference, right? And then he ended up writing this long blog post when he said, yes, this happened. AI was a part of it. But the real reason we were able to pull this off is that we got our data house in order and we consolidated our data into a property graph database called Neo4j.
And it is true, like they threw out 1,200 SaaS tools thanks to this. And so I still think there's something very real here, although probably some kind of overcorrection right now.
Animesh Koratana: Yeah, I guess so. Actually, the last time I talked to Sebastian, he mentioned something similar, where he was thinking about how do we actually centralize kind of the organizational context. And there are so many different kind of layers to peel back here, right?
But one is a lot of what used to live with these systems of record essentially became a moat for these companies over time. But at the same time, I think a lot of enterprises are basically feeling that it becomes a point of leverage that these vendors end up having over them.
And then in an agent economy where agents are actually making more and more decisions, the record keeping of how we got to those decisions and all of those other things end up being essentially held hostage by these systems of record. And so therefore you don't want to use the systems of record anymore and actually kind of abstract and represent the data in a way that is representative and expressive enough to fit the curves of the business.
So, Klarna looks different than a Salesforce, that looks different than a PlayerZero and a Neo4j. And so, the way we would want to represent certain pieces of data as they span across multiple functions in our company, I would want to look different and therefore want to internalize a lot of these things.
The other, this is like the classic build versus buy sort of debate though, right? Maybe this actually transitions a little bit into the context graphs debate, right? But what does that store actually look like? And then how does it evolve over time? Should everybody in the world be spinning up a Neo4j instance? First of all, is it in Neo4j? And maybe you're a little biased there, right? But is there a universal kind of context layer that every engineering team, every company should be investing in? And then, yeah, like, what does that look like? And is the company itself the right person to actually go and build it?
Emil Eifrem: So many thoughts here. I have a comment on one thing, just on the system of record piece, which is like, I think what we're all sensing is like, okay, we had this super coupled thing where we had the single source of truth piece coupled with the UX, right? And everyone was forced to use that UX. And there was some value in that UX because it encoded some version of best practices, right, for that business process. But it was also built for the average marginal next customer, right? Which means was it optimal for your organization? Very likely not.
But I think the foundational piece of it though, like the single source of truth for that data, that is still really valuable, right? And I think the big debate is, okay, so then like the work is going to move somewhere else, right? So does that mean that the profit pool stays with the systems of record? Or does it sit with whatever layer is doing the work, right?
And obviously, like, if there's a lot of value in that doing-the-work piece, and in order to do that as an exhaust, right, like we get the decision traces that build up the context graph and something else ends up being the system of record for that context graph, right? How much of the profit pool flows over there? Probably quite a lot would be my guess. But I don't know what your take is.
Animesh Koratana: Yeah. Well, I mean, I think the systems of — so maybe it's worthwhile to actually kind of define what a context graph is. And then maybe it's worthwhile to talk about how that relates into systems of record.
But my view is, right, systems of record are really well positioned to capture the outcome of certain decisions. And so we have, you know, Salesforce, which holds the outcome of many different personas operating together to lead to a particular deal. And therefore that manifests in a customer record that shows up in Salesforce. But all of the conversation about how that deal was made, right? Animesh and Emil talked, and then after that, then we had our reps talking and our engineers talking and the quarter needed to close. And this is the discount we gave and all of those different things. End up being decision context that is important to understanding why the outcome actually happened, but actually ends up being lost and ends up living in the minds of the people who actually executed it.
And so that was actually the core realization that led to this whole context graph debate. And what I think a context graph is, is basically a fabric of these decision traces, these decision trajectories that lead to certain outcomes. And over time, when you start weaving these things together, you're essentially encoding an institutional memory, right?
That's ultimately what I think a context graph becomes. And I think it's a huge point of leverage for enterprise and for really any team as they kind of grow and accumulate knowledge, both as a function of their teams growing, as a function of the complexity and customer base growing, to be able to encode and remember why the business actually came to be in that way.
And the reason why this is especially important right now is because the amount of work and the amount of decisions that can actually start happening are no longer constrained by the number of people you have in the company anymore. And that's agents. Agents can actually be doing work well, 24 hours a day, 365. You can scale these things in ways that we couldn't really imagine. They're incredibly smart, incredibly agile.
And so we need some way to actually give them decision context so that way we're not sitting here basically being the human MCP for these agents. That's kind of the short of it.
But going back to your question about systems of record, I don't think systems of record are actually well positioned to capture these decision traces.
And I think over time, if we think about how much we pay people versus how much we pay SaaS, we pay people a lot more comparatively. And it's because they have that decision context. And so what I think is going to happen is actually like, you know, I don't think Salesforce is going to lose a tremendous amount of value in like value creation. But what I think is they're going to own a much smaller piece of a much bigger pie. Like there's going to be new vendors, there's going to be new startups that are actually owning the value creation that happens on top of these systems of record. Salesforce will remain a database.
And I think over time, what's going to start chipping away at Salesforce's moat is going to be people basically asking, why do I need Salesforce at all? Because isn't it just a GUI, right, on top of a database?
And so yeah, I think they're just going to own a smaller piece of a much larger pie. And I think that's where kind of like the discounted cash flow piece of it, right, implies a smaller valuation and a market cap. That's my take.
But I think the counter take to this is just like these SaaS companies have distribution, they have tremendous staying power. And what if they actually are able to go and start capturing these decision traces and encode it themselves? I think that's kind of the counterpoint.
Emil Eifrem: Yeah. I think of it similarly.
And what I loved about the context graph, like the initial two blog posts were just amazing. Like Jaya and Ashu's and yours. And to me, it completed the circle. I have this four quadrant thing in my head, which is I think there's exactly four data sources or types of data sources that agents need to reach escape velocity in reality, in production, inside of enterprises.
And context graphs completed that four-quadrant thing for me. And the first one is the operational databases or the systems of record. But I tend to think of them as systems of record for the present. They hold the current state, as you just said eloquently. So that's kind of the first one, right?
The second one is the data platforms or the data warehouses. And I think of them as the system of record of the past, right? Like, how much did we do in sales in the LATAM in Q3 last year kind of thing, right? Not how much is a customer paying me today in this very moment. That's system of record of the present. That's operational database.
And then the third one is kind of agentic memory, right? Which is, maybe system of record for agentic state is the right way.
And then the fourth one is the system of record for decisions. So the context graph. And those are kind of the four sources in my mind. And I don't think it's as easy as you need all four to reach escape velocity, because I think it's use case specific. There's some kind of an accuracy threshold for like good enough per use case, per situation, you know, kind of thing. And I'm sure you can get there with just one of them in some situations.
I do think generally speaking though, the more the merrier. And really for the complex and probably the most valuable ones, you need all four. What do you think of that framework? Does that resonate with you? Is there something that you see that I've missed?
Animesh Koratana: No, I think that's actually really well put. The side effect of this, might I add, is you actually end up seeing a change in the shape of work itself.
I think one interesting tidbit that we're learning, and at PlayerZero, we're an AI production engineer, and we think a lot about what it takes to maintain and operate software after it's left the IDE. This usually touches many different functions. So it touches QA and the pre-production side, but also SRE and support and security and all these different functions.
At the end of the day, decision-making for why we built certain things or how we fixed certain things end up spanning multiple different functions.
And as you start building these different systems, in the four that you described, as you start kind of building and maturing these, what ends up happening is a lot of these functions end up collapsing into one another.
And I think this has been a really interesting thing that we've started kind of noticing, right? Like the line, for example, between SRE and support ends up blurring a lot because the context required to go fix an issue when it's a ticket versus when it's an incident ends up looking very similar.
And then pulling that one level further, in order to do great QA, you need to understand how things broke in the past. And so these are all kind of decision traces that end up representing the threads between all of these different functions.
Emil Eifrem: Yeah. I've been using it like data sources or something like that. But no, I think it's actually really well articulated. And maybe I guess you implicitly answered a question that I had, which is, do you think that there is a universal data system that exists for the entire company, right, across engineering and sales and every single — you're nodding your head, no?
Animesh Koratana: No, I'm thinking not, right?
Emil Eifrem: Because I think, look, so maybe let me take the context graph angle for this. I think we're all sensing some kind of future state. And I think you're living in that future state with some of your customers, right? Where there's like, my agents are up and running and they have access to whatever source data they need, maybe across the four quadrants in our framework, including the decision traces of what's been actually going on in the real world to make these types of decisions, whatever decisions that the agents need to do.
And that's amazing. They've reached escape velocity, all systems go. And it's probably like a self-improving system. Maybe this is the naive view, but like in theory, that's what it should be, right? It should compound over time as a flywheel.
But how do we get there? That's kind of the state, right? And I think there's some kind of a step function-y thing going on here where you chew off, in my mind, and what I've seen happen in the Neo4j kind of customer user base is that you take a very narrow problem, right? And you solve that and sometimes you have enough data without the decision traces to get above the good enough accuracy threshold. And so therefore you can just start bootstrapping, start accumulating decision exhaust and all that good stuff, right?
Sometimes I see people plugging a human in the loop in there and then instrumenting the hell out of it, right? But in a very narrow way and then you branch out from there, right?
But can it then end up being this one big platform backing it? I just, I don't see that happening in any future that involves like non-trivial. Look, who knows? Like people talk about the billion dollar, like the unique one human unicorn startup and stuff like that. Maybe the shape of everything is going to change so much, but certainly looking at the Global 2000 today, I have a very hard time seeing that.
Animesh Koratana: Yeah, no, I completely agree with that. And I think we should actually double-click on the how to build the flywheel piece. Because this is actually really, really important. And it also lends itself to a question that I get asked often, which is, is building context graphs an application layer or infrastructure layer opportunity?
And I think the question within the question there is, at the application layer, you pick a narrow use case where you can actually start instrumenting the decisions required to go and build what later and over time accrues into an infrastructure layer opportunity. But you can't really just start with the infrastructure layer opportunity and expect it to become anything because those decisions are actually not recorded anywhere today. Is that roughly the way you think about it?
Emil Eifrem: Yeah, that's exactly how I think about it. And you have to seed it somehow in most situations. I'm sure there's some kind of long tail going on here where maybe that's not true. But I think for the majority of situations, you have to seed it and that means starting in the application layer, which in and of itself is very hard to know. I feel like all the lines are getting blurrier and blurrier now, right? Agents sitting on top of data platforms, is that the application layer or not? But conceptually, you have to start with that real business problem to solve in order to bootstrap the system.
That's certainly my point of view and what I've seen across our user base. And the first time, just for reference, the first time I saw what we now know as a context graph with like using these decision traces as an important source into the agents, the first time I saw that was around 9 months ago, last summer. So summer of 2025, when like a massive tech platform was building out. They already had Neo4j to store, call it their RAG corpus, right? To express that in graph form using GraphRAG. But then they started building out what they call their agent brain or agentic brain, also on Neo4j, storing again the output, the exhaust from a lot of their kind of agentic traversals, right? And then they started using that. I thought that was very cool, right? Didn't have the terminology for it until December 22nd, 2025, when the context graph post came out.
Animesh Koratana: The day that everything changed.
Emil Eifrem: Yeah, yeah, exactly. So, I think that's kind of what I've been seeing in terms of bootstrapping the flywheel.
Animesh Koratana: So, this actually takes me to another question that I often end up thinking about in many different lights. And maybe you and I disagree here. So, I have to ask, how does a context graph actually get materialized? Is it actually a graph? Is it not a graph? Maybe in the case that you described, like this agent brain, what is Neo4j's role in this, if any? And then how do you see that evolving?
Emil Eifrem: Yeah, look, I tend to love graphs in all shapes and forms. And of course we built a product that is really — there's like the impedance mismatch between kind of a graph data model, something expressed in that way, and the underlying substrate is really low. So, it's very low friction, right?
And so, I think it offers many kind of benefits. But I'm also fully aware of the fact that the default database for most teams today, certainly if they're startups, is Postgres. Like some flavor of Postgres, right? And in the enterprise, it's probably some version of Oracle. And it's back to where we kind of started, which is these are all isomorphic models. So, you can put any kind of graph structure in a key-value store if you want to. It's just a lot of work, right?
And so, I think we're going to see a lot of different ways of doing it. I do think for many teams, the fact that the data model is such a good fit makes it like a natural home for it.
And then the other piece is one of the things that I of course loved in your original blog post was you had a really eloquent treatment around graph traversals. And you talked through like graph embeddings and random walks and directed walks and all kinds of stuff that was just a treat for someone sitting here with a Neo4j shirt. And one of the examples I think you had of structural similarity was Node2Vec, right?
Which we all know is a classic way of doing graph embeddings. But there's other algos too. There's one called FastRP, right? Which actually most of our customers use it at scale. It's typically more performant at scale with equivalent accuracy. For some people, Node2Vec is right. For some people, FastRP is going to be right. In Neo4j, it's one line of code to change between that. And if it's on Postgres, there's a huge amount of more work that you have to do to plug in a different algo. So I think those are some of the benefits of running on a native graph platform.
Animesh Koratana: Totally. Yeah. No. So, actually, there's a slightly different way that we think about this, which is like the graph is like the right mental model for what this thing ends up becoming over time. But the problem is that you can't actually observe the graph until you actually start walking it.
And so, the kind of key idea I wanted to put forth in that blog post was agents are informed walkers over this graph, which means that when you give an agent a problem, it figures out how to stitch together through tool calls and more things, right? It's able to stitch together different pieces of context that allow it to both explore and exploit the context that it's given in a problem-directed way.
And so by virtue of doing that, it ends up walking over a graph that is otherwise not observable. And when many agents do this over time, they end up creating relationships, sometimes explicit, sometimes implicit, between all of the different records that they're walking on top of.
So just to make this a little bit more tangible, right? Let's imagine like an incident comes in and an agent is picking it up and saying, I'm going to go try to diagnose and root cause that incident. Maybe it says, okay, the alert says that this particular service is down. Latency on this checkout endpoint is running a little bit slower than it used to. So I start with the service and then I need to go and say, okay, well, the service seems to be related to this area in the code. And this area in the code, right, is often something that Emil is changing often, right? He made a change recently.
Emil Eifrem: Damn it. I knew it. I was going to be the culprit in all this.
Animesh Koratana: Yeah, but like, okay, well, now there's some relationship that it found between the service and this area in the code. And then, you know, Emil. And once we actually make a change and we suggest some sort of a fix, the scenarios and test cases that actually need to be verified before this thing actually goes back into production and the other customers that it affected. And so this agent, by virtue of actually just owning the escalation and remediation path, ends up stitching together all of these different records. And it's essentially observing that there is a relationship between these things in a problem-directed way.
And in our manifestation of it, actually, it isn't a graph. It's actually because it's unobservable, right? The relationships that connect these distinct entities end up changing based on the problem that you actually want to query against.
And so therefore it becomes very difficult actually in standard data models, or it becomes very difficult to actually define any data model to express this. And so we actually end up falling back to a lot of AI-motivated techniques. And this is where the structural embeddings came in, or there's also graph transformers and stuff like that, or the way these labs are going, right? Actually internalizing these representations back into the model itself, right? Using continuous learning and then all of those kinds of things.
And so in a world where the models actually just keep going the way that they are, continuous learning, maybe this is a ridiculous question. This could be the smartest question I ever asked or the dumbest question I ever asked. Do databases even exist at that point? Or for context graphs, right? In this particular flavor of the problem we're talking about, are databases relevant?
Emil Eifrem: Well, let me just first comment on kind of the thing you said, and then let's talk about kind of the model view on this.
I think that's super interesting, right? So a couple of thoughts on what you said there. It seems like where we agree is that kind of the mental model for this being graphs, that's a good kind of way to think about what these agents are doing.
And then, as you say, they're kind of stitching together in a problem-directed way. They're traversing these various systems, figuring out, like, oh, based on my input here, now I'm going to go over there. And you don't think of that as a graph.
Animesh Koratana: Well, because we don't know the relationships a priori, right? Therefore, can't be modeled until I actually do the thing.
Emil Eifrem: Exactly. And then the output of this, however, is what is the decision trace, right? And that can be described as a graph, though exactly as you said, we may not know all the types ahead of time.
And I think what this bumps into is this universal age-old, you know, kind of schism in the graph world of, call it, top-down modeling versus bottom-up modeling.
And, you know, we represent the property graph world. That is kind of what Neo4j was based on and honestly invented. And then there's this other way of doing things called RDF. And in the RDF world, you tend to want to start with an ontology and describe that ahead of time. And in our world, because we grew up developer first, like the ontology was already expressed in C#, or I was going to say Rust — Rust didn't exist at the time — but whatever, like in Ruby or Java or Python or something like this. It was encoded. The ontology, the schema was encoded in classes in Python or Java or something like this, right? And so there's no need to do that. We could just have this completely bottom-up way that is schema-free.
Now, over time, we built it to be schema-optional because we learned as when you would put it into production, it's actually helpful to be able to say if there's a node that has been labeled as a person, it has to have a social security number or something like that. Because if the database doesn't enforce that integrity, then you have to reimplement it everywhere in imperative code, right? Which is just not a good model for it, right?
And so I think what you're commenting on here is the drawback of a fixed top-down ontology, in that the right approach, I think your view is, is that the ontology should be built bottom-up and discovered over time as a consequence of the agents walking all these different systems.
And both of those things can be described in the property graph, right? Like you can use the top-down ontology and you can use the bottom-up inferred ontology. My personal point of view, and here is probably where we disagree, is that I actually think being able to do both is the right approach. And at least for the foreseeable future, being able to guide the system a little bit. Like, yes, if you have to go all the way out and describe your entire company and how everything works in a top-down way, that never works, right? The world moves too fast and they're always behind and you can never get it consistent. So that never works, right?
But I actually think the other extreme of complete bottom-up too has drawbacks as well. And being able to say some of the things top-down and have them being met and informed bottom-up, I think is probably the right approach for a while. But ultimately, we're agnostic to whichever of these approaches. Does that make sense?
Animesh Koratana: Yeah, yeah, it makes total sense. From an enterprise perspective, I think it actually solves a lot of problems. I think one of the big problems ends up being, how do you secure them? Because by definition, these context graphs end up spanning different relationships across different systems of record and different people and all those different things.
And you're trying to centralize this context, which in theory sounds awesome, but the context you have access to is different than the context I have access to. But this agent somehow will have access to all of it, right? And that needs to be secured. And actually being able to enforce certain security kind of principles there, I think, is important.
There is like a counterpoint here, though, which is, you can think of like the analogy of how we used to think about what AGI would look like 10 years ago, versus how it's actually progressing today. And I think one of the biggest things for me was realizing that this next token prediction task is actually the thing that could scale into AGI over time. It's extremely fluid. It's extremely non-deterministic, but it seems to encode the right task to be able to model very complex relationships.
The reason this analogy is interesting to me is because that wasn't intuitive to me 10 years ago. That next token prediction task being the right way to scale neural networks and what later became LLMs to be able to handle very expressive and reasoning-intensive tasks. Even after ChatGPT came out, it wasn't obvious to me that just actually spending more tokens would necessarily give you exponentially better answers.
The AI-native way of thinking about this generally implies that the model can learn any pattern, right? These relationships can actually be implicitly learned in transformer intermediate representation space in the LLM or in some external model, as opposed to it actually being described.
The moment we as humans try to get our hands into it and try to define any sort of ontology, or maybe ontology is probably the wrong word, but we try to define any sort of schema or record type or anything like that, we end up constraining its expressiveness, right? The same way that if you tried to prescribe what each dimension of embedding actually was meant to represent. If you went and tried to do that, embeddings wouldn't be embeddings.
That's kind of the counterpoint that I often struggle with, where it's like if you throw a graph transformer on top of these observed trajectories or you continually train an LLM and fine-tune it for a particular domain, these things tend to learn very interesting relationships that I could never even imagine modeling in a graph database, in relational, like any sort of a database. It's actually just an externalized form of continual learning.
And if that's the case, then does everything just get eaten by the model?
Emil Eifrem: Yeah. Is that approach, are we like on some wrong side of the bitter lesson type thing going on here?
Animesh Koratana: Yeah. Like, I don't know. I don't know. But that's kind of the counterpoint. Because I think I understand it from an enterprise side and this is something that we see every day. And we've had to take opinionated positions on how do you secure these things as you deploy agents into production when you have thousands of engineers or things like that. And I think you've seen versions of this play out across your customer base too.
But at the pace that these things are moving, platform shift is happening. And when we first started the company, it was before ChatGPT, people would laugh at us when we said you're going to deploy AI into production. And now all of a sudden, you're deploying AI into production. It's no longer even a conversation.
And so like the way people are thinking about these things has changed so much. And I'm wondering if this is one of those things that's going to change too.
Emil Eifrem: Yeah, I think it's a really, really interesting observation and certainly like trying to predict, speaking of next token prediction, the next year or two, like I can't even predict the next weeks what Anthropic is going to launch, you know, coming back to where we started with the stock market and that kind of stuff.
My point of view from like running the company and building the product that we do is to stay orthogonal to that. Like ultimately, yeah, if it has an ontology or not, we should be the best substrate to express kind of graph-shaped data. And I do believe that over the next time unit, hopefully not just quarters, more likely years at least, having some kind of an enterprise world model, which on some level is what we're all building up here.
And we've spent 10, 15 years doing digital twin implementation for our customers, right? And then you add kind of agentic memory and the decision traces to that, and you start getting a pretty robust kind of world model. Maybe not quite the physics-based one or the Minecraft-playing one of the Fei-Fei Li's and the Yann LeCun's of the world, but filling an equivalent function in the enterprise, right? I do feel like that is going to be really valuable to pair up with these models. But over time, who knows where this goes, and maybe our entire layer gets eaten by whatever Claude 6, 7 or something like that.
Animesh Koratana: Fair enough. What's next for you guys at Neo4j?
Emil Eifrem: Plenty of things. One of the areas that I think is underexplored right now is the interplay between call it your classic kind of RAG corpus and your domain data and memory, right? And I feel like these systems are growing up in parallel right now.
And I think here we are on a call, let's say that you and I are coworkers and we kicked off a project and we have a code name for that called Project Trinity, right? Or something like this. Then we also have Google Docs called Project Trinity. And then maybe there's some kind of an agentic logger kind of a thing, a conversation log of this.
We talk about Project Trinity. When you do your agentic retrieval, there should be a Project Trinity concept. And it should be able to link to the conversation, like the agentic memory piece and whatever is coming out of your RAG corpus. That should be interlinked, it feels like, right? And I haven't seen anyone doing that in a good way.
Another piece is, you know, your first project as a 12-year-old around kind of named entity recognition and entity resolution and like on some level out of a bunch of unstructured, mostly text, right? How do you actually extract real entities? So we have this conversation and we talk about William Gates, right? Who works at Microsoft. Okay, well, we need to be able to extract that there's a William Gates, that's a person, and Microsoft is an organization, and connect the two. And then we also call him Bill Gates. And then we need to be able to do the entity resolution that those are actually the same individual that we're referring to, right?
And as I think in these four quadrants, right, more and more of this is going to be unstructured data, of course. And having that as a first-class primitive, like both named entity recognition and entity resolution, NER and ER, I think is crucial.
Animesh Koratana: The outcome here is ultimately knowledge-based construction. Is that right?
Emil Eifrem: Yes. A consistent one across the four quadrants, right? So that we know that we're talking about the same concept, the same entity, the same individual, the same company, that kind of thing.
Animesh Koratana: Very cool. And I genuinely resonate with the term you used, world model, earlier. In fact, what we call the core piece of technology that we built is an engineering world model. And that's exactly right. I think a context graph that is well-tuned allows you to model reality in a very expressive way. And the threshold for greatness there for us looks like, can you ask what if, right? Can you predict in a simulated way what would happen under certain conditions? And that's the goal.
Emil Eifrem: Before you experience the what if of that terrible engineer called Emil who shut down the system in production or whatever the example was from before. Like before you actually experience it in production, you want to be able to simulate it in your world model. Yes, that makes a ton of sense to me.
Animesh Koratana: Exactly. All right. So as we kind of wrap up here, I wanted to kind of like zoom out a little bit. I mean, you've been a founder for how many years now? 20-something?
Emil Eifrem: Yeah, 20 years, something like that. Not quite, but yeah, 20 years.
Animesh Koratana: Yeah. And it takes an incredible amount of kind of grit and passion to really stay at something for that long. And as a really early in life user of Neo4j, first of all, thank you for everything you've built. But as you kind of think about the platform shift that we're in right now, and you think about other founders building in the space, what advice do you have for people building today?
Emil Eifrem: Yeah, I think first of all, a platform shift is a massive opportunity. Massive opportunity for disruptors, right? Like if you look at the last one, the shift to cloud and mobile, that created 40 to 50 companies in the enterprise space. There's like consumer stuff too, but I tend to think of kind of infrastructure, B2B enterprise type stuff. There's 40 to 50 companies that were created that reached a billion of ARR or more in the last platform shift.
I think this platform shift coming back kind of full circle is even bigger because it's not just a technology shift, but it's literally an industrial revolution. So I think there are hundreds of companies that were founded in the last few years or haven't yet been founded that will grow up to be a billion dollars of revenue, not unicorn billion dollar valuation, billion dollar revenue type companies, happening right now.
And whenever I give early stage startup type talks, right, I always say that my first slide is always ignore most advice, including probably all of the stuff you see in my presentation. Because I've always sought out advice. I love hearing advice just to inform myself, but then I ignore most of it, right? And everything is so situational. And my early stage was 15, 20 years ago. Like how much of that applies and it's an end of one. It's only my experience, right?
Having said that, I think the one thing that you cannot over-index on is customer empathy. Like having a deep, deep, deep understanding of the crucial personas for you. Like where do they get their information? What do they do first thing in the morning when they wake up? What do they think of as their friends, their frenemies, their enemies? What are their key challenges? Having a super nuanced understanding, all the colors of that persona, those real life individuals, right? That is the one thing that you can't spend too much time on as a founder.
Animesh Koratana: Love that. Love that. You know, I think about the early days of PlayerZero and I think in the grand scheme of things we're still quite young. Yeah, our customers basically told us what to build. And it was just, yeah, the fact that they would call me at 2:00 AM in the morning and say, hey, I have this idea and I was using your product. Those are the things that actually moved the company forward. I completely agree. And yeah, I hope that never ends.
Emil Eifrem: And then I think the other piece is the persistence of it all and the grit of it all. There's so many ups and there's so many downs and you think you're the absolute top of the world, like you're the hero and you're the zero 7, 8 times per day, right? So just having the staying power to be kind of with it, right? I think would be like the other piece.
Now, how much of that can you listen to someone saying that versus an innate trait? Like, I don't know. But knowing what drives you. Jeff Bezos has this dichotomy of customer-obsessed versus competitively-obsessed companies. Oracle is a classic example of the latter. Larry Ellison wakes up every day thinking about which competitor to kill, kind of thing.
I ultimately, much like I think sounds like you do, I'm obsessed with our customers. What gives me energy is there's 25 projects right now trying to find the cure for cancer using Neo4j. And 99% of all flight tickets in the world are calculated with Neo4j. NASA says that thanks to Neo4j, humanity is going to get to Mars 2 years earlier.
That's the stuff that really inspires me and gives me energy and that staying power. Just knowing what is it that truly drives you, I think would be like the other piece.
Animesh Koratana: And then the kind of other macro question here is, in a year, do you have any kind of hot takes or predictions for what you think is going to play out in the next 12 months?
Emil Eifrem: Well, I'm not going to try to predict the stock market because I'm not qualified in any way. But I do think things will be a little bit more settled down. I think the volatility is just exceptional right now. And I think a lot of this is just a massive uncertainty. It does feel like we're at the absolute elbow of the curve right now of everything changing at the same time.
In terms of the technology, the two areas that I mentioned that are unsurprisingly what we are really keen and exploring right now: some kind of connectivity between agentic memory and RAG, right? Like on a deeper level than just there's some documents, there's some text over here, but you know, how do you tie it together? And that's of course intimately connected to the ER and NER topics that we discussed before.
I also would not be surprised if we see a lot of people go up the stack, like data platforms that add applications, which may just be agents running, right? Something solving direct business problems. Because like the data platforms tend to solve technology problems for people who build things for end users. And I think some of the data platforms are going to go up the stack and start solving problems directly for end users.
And I think that a year from now, that's going to happen. And I'm sure I'm going to be super humiliated when a year from now we do this again and you play this recording and none of it ended up happening. But those would be my on the spot guesses a year from now.
Animesh Koratana: Yeah, totally. I mean, look, I think given the customers you get to work with and the customers we get to work with, I think we get a very different set of context. And so that's why these conversations are interesting.
But yeah, man, without further ado, I really appreciate you making the time for this. This was a genuinely great conversation. We should definitely do it again sometime. And we are going to do a version of this again in a few weeks.
Emil Eifrem: Yes. So, what we're doing in a few weeks is that we are doing a panel on context graphs for Nodes.ai. And Nodes has been our online conference for many, many years, actually before the pandemic even. And it's Neo4j's online developer expo and summit, or something contrived like that, just to be Nodes, because of course we love nodes, right? And now we're doing a completely AI-centric one. And so hopefully we have a chance to link to it. And the keynote for that is going to be a panel discussion around context graphs, including both of us, but other people as well.
Animesh Koratana: Yeah. It's going to be a lot of fun.
Join Us at Nodes.ai: Exploring Context Graphs, From Data to Decisions
The conversation doesn't stop here. Animesh is joining Emil and other guests on the keynote panel at Nodes.ai, Neo4j's annual developer summit, now fully AI-centric.
The session is called Exploring Context Graphs: From Data to Decisions, and it picks up directly from what you just read. How do you actually build the flywheel? What does an enterprise context graph look like in practice? What does it mean for the shape of work inside engineering organizations?
If you're thinking seriously about how your team operates software in production, how agentic debugging changes root cause analysis, or how context graphs become institutional memory for engineering teams, this is worth your time.