Latent Space: The AI Engineer Podcast
Original podcast
Watch the full show on YouTube: https://www.youtube.com/watch?v=yyuVR-ML9X8
9,394 words · 2 speakers
Okay, we're in the remote studio with Emil Eifrem, CEO of New4j. Welcome.
Great to be here.
Emil, I've been waiting for this for a while. You were one of our top speakers at the first WELTSFAR. And then we did the full GraphRAG track with the rest of your team last year. We're back this year focusing on GraphRAG. How do you introduce New4j today?
It depends on the audience, right? Like, I think we're most well-known as a database, right? As a graph database specifically, right? But it's a broader platform than just a database these days. And I tend to start with, you know, we transform data into knowledge, right? So it's a platform to do that. And then, of course, leads down the path of what do you mean with knowledge? Because that's kind of an ill-defined term. And I talk about how, actually, it's about extracting the signal out of the noise and express that in a way that is a knowledge-dense way, and the graph is one of them. And at the core of it, of course, is the database. But then, you know, there's many other things in part of the platform as well now, these days.
You guys have been around for a bit. You're used by basically everyone, including Transport for London. It should be fun.
It's a very graph thing. But you'll see when you get there, the tube network is a graph.
Oh, oh, yeah, of course. Yeah, well, you know, depending how graph-pilled you are, everything is a graph, right?
This is true.
And I've been down that rabbit hole as well myself. Yeah, when I was, so when I learned to code 10 years ago, I did a coding boot camp. And there was a workshop at some conference I attended that introduced me to Cypher and New4j. And I think that's how a lot of people maybe first come across a New4j. We wanted to talk about, you know, what's happened since and what is graph intelligence just generally, right? Like, what is the, I guess, the rest of the system that you've been building?
Yeah, so let's first talk about kind of the why behind it, right? And so, you know, if you come in at it from like an AI engineer's perspective, right? You mentioned the word graphrag before, and that tends to be a popular way of describing retrieval that the R path you include a knowledge graph, right? You know, and there's plenty of reasons to do that, right? The ones that I hear most loudly from from users is higher accuracy, because you have a very rich representation of your data. And then, actually surprisingly to a lot of people, but improve developer productivity. And there's a built in assumption there, which is you have the graph, and we can talk about that.
But when you have the graph and if you compare that to vector space, it's very opaque vector space. If you search and find the top K documents, you don't know why. It's like point seven in some cosine Euclidean space kind of thing, right? Compared to in the graph, it's explicit and you can even visually inspect it and look at it. And I have an apple and an orange and they're related because of their fruitness, right? Whereas like an apple and I don't know, a tennis ball might be point seven in Euclidean space, right? Because they're both round or it's because they're green, you don't know, right? So that's kind of the second thing. And then the third reason that we hear very loudly is around explainability.
People love the fact that they can actually audit why I chose these top K documents compared to just again opaque vector space.
Yeah, I don't hear anything about query speed, which I guess it's it's it's part of it. But always think about graphs in terms of like, well, okay, the reason you want to do this is because you can you can walk a graph, you could traverse a graph, and that's probably better than doing a bunch of queries and joins. Is that an old school way of thinking about it? Or is that actually just another way of saying the same thing that you just said?
Yeah, I think it's probably built into the accuracy thing, right? Because frequently you can kind of cover a lot of ground, like you can traverse and touch a lot of documents or notes by virtue of doing it really fast, right? I guess it's an interesting observation. I guess we hear less of it and even I hear less of it.
Yeah, you never said speed.
Yeah, exactly, right? Like in kind of thinking about it from an AI engineer perspective, right? AI-ish type use cases. I guess we're also used to kind of the L L eating up so much latency anyway, that it's maybe kind of rarely pops up for that reason. But it's like a fundamental reason why we can get the higher accuracy, I think. So I think that's probably why it relates.
Yeah, yeah, I mean, if you have speed, you can just throw more time at it to get more accuracy.
Exactly.
Yeah, okay, cool. And then I think the other question that comes up a lot is what happened to vector databases in your mind? You know, as a, as a neutral sort of database CEO? How come that has been a less, I guess, how should I call it? Persistent or independent category?
Yeah, durable.
Everyone has vector indexes now, but like, I think it's fair to say vector databases as a standalone category are over.
Yeah, I don't know. Maybe that's overstating it. I've been, so several years ago, I was very kind of on the record saying that I don't believe this is a durable database category, right? At least not as a database category. Maybe it feels much more like search, right? That is kind of my, my statement a couple of, of years ago. I guess I've been surprised that there's still, I think, some kind of long tail thing going on where we still see a lot of experimentation where people try with vector databases early on, right? And then at the, like a super high end, then like some of the vector databases are still better than the vector search features of other databases. But like, you call me a neutral part, I'm not neutral here, like, because we also have vector search as part of, of Neo4j.
And it's not as good as the dedicated vector databases. Exactly, right? But like every quarter, every year, kind of the line moves up, right? And so there's less and less oxygen for them, you know, I obviously. Watched with with pleasure, you know, your your conversation with Simon a couple of weeks ago as we're recording this from from TurboPuffer and he described it as a search platform, I think, or search, yeah, search tool or something like this, right? I think that's generally where people are going right now who used to be a vector vector databases. And I think just the oxygen, you know, between everyone else adding it as a feature, they're like the good enough ends up being good enough for most situations.
Yeah, got it. I think I think that's true too. And I think something that everyone should disclose or disclaim is under what size and what complexity of data or cardinality or whatever, right? Are you like truly excelling, right? Where where your solution is leaps and bounds above everyone else's because you are architected for like in in a in a specific way. At small size, who cares? Just throw it in whatever. But like at scale, it really starts to matter.
Yeah, I agree. And like the way that it fits in for us is so you have call it your rag corpus, right? And you have some kind of pipeline to get that in a state where you can query it and get it kind of out and ultimately to the L L M, right? And then we populate the graph based on that ingestion pipeline and embeddings in our, you know, vector search index, right? But and then at query time, we typically tend to use it to find the starting points in in the graph, right? And then we traverse from there. So in the classic kind of customer support type use case, swyx, you know, just got a new laptop and the permissions don't work.
And so you go to on to the Apple, you know, support site and you type in something, then, you know, from that natural language, right? There's typically a vector search typically combined with some kind of B M twenty five type search as well, right? And that ends up finding some documents, right? Call it a hundred documents or something like that. And then you traverse from there to get the full context. And then you end up saying, well, okay, it's not just whether these documents were found by the vector search, but also turns out that they were written by this author who's highly ranked, maybe through a page rank or maybe just very simple like stars or or some kind of signal like that. And and you get to the top K, you know, something like this, right?
And so it's not like graph or vector search. It's like vector search in combination with traversing the graph. That's the typical kind of pattern that we see.
Yeah, and like the engineering is actually really hard here because there's so it's just trade off, trade off, trade off. Like you can do anything if you have unlimited budget, but you don't. And so.
I agree. It's I I do think there's a general trend, though, like broadly, setting aside Neo4j, like trying to extract more signal out of the ingestion pipeline to make the kind of downstream querying. Yeah, well, you could call it reprocess, but just extract more signal like in the when you add things into your uh like vector search or whatever it might be, right? And the vector databases, you tend to call that kind of metadata, right? But it really it's structured data, right? And we're part of that broader trend. And you could say that graph is like a very rich type of structured data. And I think that generally tends to be the right way to think about it.
Like the more work you can do kind of upstream, the easier it becomes at runtime or query time.
Since you mentioned the Simon episode, uh that was a really fun one. He's a very charismatic guy. I'm curious if you have any like technical, like, you know, any pushbacks, anything sounded weird to you. I can ask you about like the sort of blob S three centric view of the world that he has, which a lot of database CEOs, including Neon, uh, you know, betting heavily on. Probably you don't have a strong opinion there, but I just want to let you respond, whatever you want.
No, I think broadly, it's it was this really strong articulation. Now, this was like years ago that I listened to it because it was like three weeks ago or something like this.
Yeah, yeah.
Right? So it feels like forever.
Yeah, yeah. Maybe you can perfectly remember, yeah.
No, I can't perfectly remember it, but generally it was like a very strong articulation, what sounded like very just pragmatic and savvy trade off and and choices, right? And like, of course, as a database geek, I enjoyed the conversation around compare and swap, right? And even as you and I were DMing around, it's like raft versus two face commits and stuff like that. I just kind of loved all all that because I just remember for for us, right? I used to do compare and swap like on a CPU level way back in the days, right? And then it was a big unlock for us when it because we're on the JVM. When it got exposed through the JVM, it allowed us to do kind of, you know.
Basically lock free concurrency, so optimistic concurrency or optimistic locking in the database. Right? And it's interesting to see like how he 15 years later can do the same thing, but just based on, based on S3. It seems like a really good set of trade offs for like the use cases that, that he's targeting, which is of course very like very different from what, what we're targeting.
Yeah, cool. Uh, let's talk about some of the use cases, right? Like I, I think one of the surprising things last year was I think the Pfizer talk, which is kind of cool and, and I just, you know, you have lost you so many customers here. Just who are the sort of AI forward customers that you, that people might be surprised are using graph databases or using O4J for something?
Yeah. So lots of things to talk about there. Like that's one of the biggest things that have changed, certainly since the first talk that I gave, which is now two years ago. It was, uh, June of 2024, I think, or maybe May.
I put you on the landing, yeah, the landing page, uh, yeah, down here.
Yeah, yeah, yeah, yeah. So and a huge one of this, of course, is that people now have put it into production. It was such early days, but back, back in those, those times. You, you mentioned Pfizer. We see a lot of adoption inside of life sciences, right? And so this is broadly kind of scientific intelligence that researchers at these big life science companies use on a daily basis. This is access to not just internal peer research, but patents, like externals published, you know, academic papers, you know, those kinds of things, right? Nowhere nor this is one of the like public case studies we have here, over 60 million documents, you know,
billions of notes and, and relationships, use lots of kind of savvy NER, NER. So that's named entity recognition and entity resolution, which is such an under discussed area right now in, in AI engineering, by the way, which I don't understand what, why it is, but, but that's like key for them to make sense of all, all that data, right? And if you think about like a life science company, right? Like extremely PhD heavy, right? And this is like a hundred percent on the critical path for them in order to like improve their productivity and, and output. So that, that's an example. We have lots and lots of recent uptake, just in 2026, in banking.
An example here is like, so thirty percent of our AI conversations these days, like in 2026 so far, has been with like global banks, which is pretty, pretty amazing.
Yeah.
One example, which I don't know if we have on our website, is like a massive mortgage lender company. And what they're doing is they have a ton of, let's call it bankers, they call them agents, which makes it very confusing, but human beings that they hire. Yeah, yeah, exactly, human agents, right? And, and they are kind of mid twenties, low twenties kind of demographic age wise, right? And like their normal tenure is super low, it's like less than a year. And so a huge part of that game is to ramp them quickly. And as they do outreach to their customers, how can you get kind of the bottom quartile and move that up, up, up the stack, right?
And so they built this huge system that looked at all prior, like kind of the, the best case path and what actually converted in the past and helped them pull that all together. And they actually talked about it publicly and didn't mention Neo4j, but that it increased conversion rates by, by twenty percent. And so that all happened, uh, you know, last year.
How much money is that if you convert it to money?
Yeah, I don't, I don't know, way more than they pay us.
And but the really cool thing is, and now what they're starting to do this year is they're starting to now kind of automate that, right? So prior to that, it was just kind of serving up the draft to the bankers so that they can send the text message or the email or something like this. And now, of course, they're kind of removing the human in the loop and they just send it out in an automated fashion, right? And that's very cool to see how quickly people are starting to put these things in production in customer facing ways. When we reviewed our kind of customer portfolio last summer, almost no one had customer facing things in production. But that has shifted very, very dramatically in the last, call it, three months.
When you say three months, is it, so there, there's this thesis that I've been investigating, right? Something happened is in December twenty twenty five, where a lot of curves infected and all that. Are you seeing that too?
We are seeing that. I cannot believe that it's related to Opus four, five, that that seems like a like a separate, separate thing.
But GPT as well, but uh, no, no, like every chart in both databases. So obviously I see a lot of these industry wide stats and numbers. I mean, angel investor in like thirty companies. And you know, obviously through through cognition and and E I E, I see a bunch of stuff. Every compute chart is like this, every database chart is like this, and obviously every coding agent chart is like this. Only like, yeah, something's going on.
Something is going on, right? And to us, like, I'm not sure if it's like purely the model quality. But yeah, we're seeing it too. And and a big shift is what I just mentioned, right, which is, you know, it used to be just draft me the messages. Now it is kind of send me the messages, right? And so that complete automation in a customer facing way. It's now gone into some kind of tipping point around trust, right, where they where they're doing that. Another example of this is if, so that's kind of high level, kind of what the companies are doing. But if you go down to the micro level and like a single developer, a single application, which was kind of the scope of my graph rag talk two years ago, right? Like that was kind of the um, the the boundary.
And if you think about that, right, like, how do people actually write the genetic kind of graph applications right right now? Okay, so so the graph is a tool, kind of vector database might be a tool, you know, that kind of thing, right? And then you have some kind of English coming in, some natural language coming in, maybe, right? And then it used to be that what the recommendation was. Take the most, the kind of the hotspot of the type of questions you might get. Again, if it's a like the customer support portal is just this most obvious example, right? But we can choose plenty others, right? So if it's Swiss, then, okay, Swiss goes to Apple and he asks some questions. Take kind of the hotspot of those questions. Express that as a function or a tool, right?
In Cypher. And then use generic text to cipher as the default kind of backstop if that doesn't work. And then what customers ended up doing was like, okay, I'm going to do this. And then they sat down and they looked at the log of everything that kind of had a fallback to text to cipher. The stuff that didn't work, they would extract into a separate function or tool call. So that is kind of the the general way that people were doing things, right? And you saw similar with other databases and and agentic applications about a year ago. And then in the last three to six months, what has changed is that it used to be lead with the specialized functions, fall back to the generic. And now that is flipped.
So now it's like, okay, just start with generic text to cipher. Right? And then when that fails, you extract the edge cases into the specialized functions. Right? I think it's just across the stack, there's a number of things that have happened like that that I think caused it to to flip, call it, you know, three to six months.
Because it can single shot most things now as well.
Yeah, you know, this this trigger is a common talk track that I have as well around LM coding. You know how?
One of the reasons I did the workshop with Cypher. And then I didn't, I didn't really use it other than that, mostly because it's a DSL. And I'm like, do I want to learn a DSL? But now DSLs, you know, a good reason is they are optimized for their use case and they are so concise. They handle so many things correctly. But then the downside is you have to learn them. Now you don't have to learn them. You can just. And and yours happens to be a DSL that has a ton of training data. So it's like you you made the cutoff where you've been around long enough, you survive through ups and downs. And now, you know, people actually can freely use you and obviously optimize if they if they need to. But other than that, you know, you can mostly one shot these things, which is super nice.
I agree. A couple of more thoughts. One is, we had the benefit of becoming a complete actual ISO blessed standard, right? So it started out as OpenSifer actually back in 2015, which after so many back and forths and all kinds of, you know, standards wars and whatever, right? Or not even wars, but standards bureaucracy ended up becoming GQL, right? Which is the first sibling language to SQL. And I actually think that helps as a signal for the kind of LLM training data, right? So that's one thing. Now, having said that, internally, so we have a bunch of kind of internal text to cipher things that we use
across the product portfolio, like a old school kind of Copilot type thing. If you go into Neo4j, into our browser, where you can type your cipher queries, right? Then, of course, you can use a Copilot to translate that. And you can run agents on top of us. And then, so we need that as a primitive in our, in our platform. We actually still fine tune that, that one. And so whenever we default to Gemini, and we still do like some fine tuning and even some post-processing.
When you say fine tune, are you saying fine tune a custom model to produce, you know, your text to cipher? Or you're fine tuning the playground and the output?
No, no, no. We're fine tuning an actual model.
Okay. It wasn't clear. Because you can't, I don't think you can fine tune a Gemini model, right? You can't fine tune an Android model.
This is where like, we probably use some of the, one of the derived ones internally. I actually don't know, know, know which one. But we then even have a post-processing step, where we do some, like, real just imperative code, like reg exp type stuff sometimes, to like, switch some arrows around. You know how like in Cypher, you can describe it in relationships in different directions and, and stuff like that, right? And so it actually is a little bit messier than, you know, it's not that the models out of the box are good enough for all situations right now. I certainly hope like, what if some bitter pill kind of thing, right? That over time, it's going to be good for even 99% of all situations. But it's Quite there yet.
I mean, I, I, I think, you know, that's where, that's where like experts will come in, having a good ecosystem will come in and, uh, you know, that, that will still be the domain of human experts, at least for now.
And I want to come back to like, um, use cases and cool things that people are doing, right? Do you think that there's just a ton of work, obviously in like traditional recommendation systems and fraud detection and all that? I did start a L M Rexus track last year where, uh, it looks like L M's are eating Rexus. And I thi- I think there's, there's interesting usage of, of graph databases there as well. Apparently all of YouTube, um, you know, the, the YouTube Rexus is L M based and they.
Is it really?
They obviously, yeah.
That's cool.
They, they re- they tokenize every video, every video and put it in a code book. And then they train a L M on it to, and then feed in your, your context, just like a regular L M and ask it to predict the tokens of the next videos you should watch. It's crazy.
That, that is pretty cool. Actually, I had no idea.
The Rexus people I know, Eugene, who's, uh, Eugene Yan, who's like, you know, big figure in the Rexus world and, and all that is very bullish about this. Apparently it's, it, it, that's also powering the new X algorithm. That's also powering Pinterest. It's like all the rage in, in their world and it's kind of cool. You know, it's definitely feels uncomfortable. I definitely have some weird recommendations in my algorithm that like normal systems would never recommend. But whatever, right? Like it's a new world and everyone's trying to get signal. And I'm sure if, if anyone A B test their stuff, it's YouTube. So, so yeah, basically like, I guess what are the new workloads or use cases that you're seeing that you want to encourage people to check out?
Yeah. So there's plenty of experimentation going on, which I love, right? Like again, you know, for the last 10 years, we've been very focused on the global 2000, right? I mentioned several examples there, life sciences, financial services, and I can keep going on and on and on about that. But we've also a little bit gone back to our roots in the last, kind of call it year and two or two. With like, we have a startup program right now and our, in our cloud service, which is called Aura. You know, has a form factor and a price point that works for startups, right? And so that's like really, really phenomenal. And of course, a very popular one here is Suggestic memory. And so there, there's a lot of people who want to do kind of memory on graphs.
People don't talk about this, but like actually the initial M C P release includes like a tiny little in-memory.
Graph database.
This is a hard thing to say.
200 lines of code.
Yeah, I thought it was 300 lines of Python.
Yeah, yes, something like that, right? And so it's a toy, it's tiny, right? And it's an in-memory implementation, right? But it's graph shaped, right? Which is, which is cool, right? Of course, I love that. And so there's, there's just a lot of people who kind of naturally do that. And then, of course, there was all this discussion around context graphs that happened in the last, you know, kind of three, three months. And so we see plenty of people doing things like that, which is also, I think, a great use case for graphs.
Yeah, okay, so memory is a whole topic. I don't know if we'll have the, the time to cover that. My, my quick sense, two cents on it is like, in theory, graph databases are fantastic for memory. In practice, it might be overkill. Most people's memory doesn't go that far. And I don't think like, we have figured out the structure, the true structure of memory that, that like really, really works over a super long period of time. And probably it's like, yeah, it probably fits in a, a single file. Like, like I don't put, I don't put out that many tokens, you know? But context graphs, yes, right? Like, so, you know, this is where like, what I always say is I don't care how long your LLM context is. We, we took, you know, three years to go from 100K context to 1 billion context in every frontier model.
But we're not going to a billion, you're not going to a trillion with context graphs, context lines. What is your take on the context graph discussion? I mean, it's really blown up. We had a, we had a short pod with the authors about it. I, I think they're kind of leaving it open to interpretation. I think a lot of people will build context graph systems and we'll figure out what it is. But what are your early takes?
Yeah. So my view on it is that in my head, it completed the quadrant of the types of data sources that are required to reach what I've been talking about as kind of escape velocity for agents in production. And so what I mean by that is, I think it's exactly four types of data sources. And I would love to hear your take on it, right? If you can identify a fifth or a sixth one. But I think there's exactly four data sources that are required. And I don't think it's as easy as you have to have all four of them, but like the more, the merrier on some level. And the first data source for agents, I think, is operational data storage. Right? And so this is the like the system of records and I think of them as systems of record for the present. Right? So this is like, okay, how many customers do I have right now?
Or what's the value of this particular customer right now? You know, that kind of thing, right? And and I think in the conversation, we flip between calling the application on top of the like operational database. We call that the system of record. So Salesforce is the system of record. That's one way we talk about it. The other way is like the actual database is the system of record, right? But no matter what, I think that's kind of the operational databases in the first is the kind of the first quadrant. The second quadrant to me is the cloud data warehouses, right? So this to me is people say that they're not systems of record. I actually think they are. They're a system of record of the past. Right? So if operational is a system of record of the present, then this is the system of record of the past. Right? And so
how much revenue did we get from the Lat Am region in Q3? You know, that kind of thing, right? And then like the the third quadrant to me is
So that's OLAP.
Yeah, that's OLAP, right? So OLTP and OLAP for like. Yeah, yeah, yeah. You you said DSL before, which is probably a data term to domain specific language, right? Like, but
No, I think it's like a programming. Yeah, programming term. Yeah.
Yeah, yeah, yeah. Um. And then the third one is agentic memory. Right? And so or maybe like agentic state, like system of record for agentic state, maybe short term, long term state, something like that. And then the fourth one is the context graph, right? And so what is it then? So this is the why behind we made like uh the particular values in one quadrant, one and two, right? And okay, so you know, the classic example is the, you know, I I sold into this customer at this price point. That's a 20% discount off of list price. And our policies say that we're only allowed to discount by 10%, right?
Okay, so the why is, well, I wanted to break into this vertical or into this geo. And I got an approval from my sales VP that was on the phone over Slack by email. It's not recorded anywhere. And those decision traces is what they call it, right? End up constituting a graph that they call the context graph. And if generally we're in the kind of space right now, trying to shift decision making from yeah, kind of human brains into agentic brains, right? It used to be from web to software. I don't even know what to call kind of the L L M's now, right? Into latent space, maybe, right? Um, then, you know, then having access to that institutional knowledge of how things
actually happen, the actual decisions in big organizations feels really valuable. And so those are the four quadrants. And then I can talk about kind of more context graph specific stuff. But first of all, do you agree with the four? Do you see a fifth or a sixth?
I feel like the, the, the three out of the four is obvious. Sorry, I strongly agree with. And then the, the fourth one is agentic memory, actually, where I'm like, that's a little weaker. That's a little less established. That's a little smaller. It's like the, the one, two and four are very strong, very large categories where I know exactly how to architect it and everything. The third one is like the, uh, I don't know, something, something memory. And I feel like there could be more. And when I would think about two by two, right? All that O L T P is great. That's like a dimension of how wide you're querying, what volume of transactions you're doing. The other dimension should be ideally, the other axis should be orthogonal. And I don't necessarily know what that axis is.
Uh, and so it doesn't exactly fit a normal two by two, which usually means that maybe there's a third dimension that's kind of being sort of mixed into the, into the equation here. This agentic memory, let's call it, is probably mostly personal, maybe some organizational, whereas context graphs is fully organizational. Um, uh, and yeah, so, so that's my, that's my initial reactions, but I'm happy to just only talk about context graphs, unless, unless you have more sort of.
No, but I, I, it was really interesting to hear that. I think like agentic memory is some kind of, I want to understand what happened in the past for that individual. I think it's going to be an important source for retrieval for many use cases, but maybe not all. And.
Yeah. Yeah. So, so, so maybe. Okay, maybe one, one sort of, I'll put this in my own words, is agent memory is, is sort of the stuff that you've done with the agent. And then the context graph is the stuff that you've done with everyone else. Because I think actually there's a lot of work by all the agent companies on querying their own past trajectories. And memorizing knowledge and self-improvement from, from there, that really has nothing to do with the context graph. It is just, the agent should get better as I use it, right? It's like, yeah.
I think that's right.
Now, on context graph specifically, right? So I think it makes a lot of sense to somehow encode that institutional knowledge, right? In some digital form, right? And it's back to the PhD level intern that you get that wake up every day and they don't know the past, you know, that kind of thing, right? And so, so that, that makes sense. I guess the trick is, like, how do you actually instrument your organization to get there? I think we can all see this kind of future state where, okay, I have my agents in production. Like my example from before, like, I have some kind of energetic process that reaches out to my customer and offer them mortgage discount or, or something like that, right?
And if they do that, they should be instrumented and record all of their decision-making throughout that. Use that as a source for improving themselves going forward. And you can kind of sense the compounding effect of the flywheel, right? Okay, that's great, once we're there, but we're not there now. We don't have that in any digital form. Most typically, it's that sales rep calling someone up from a car, asking for a discount, getting a yes, then selling the deal and at best it's recorded in Salesforce, right? And that's kind of how it happens today, right? Like, so how then do we bootstrap the context graph? So that has been almost all the conversations that I've had with big enterprise customers.
With startups, the bootstrapping of the context graph is by virtue of getting adoption of their product, right? And so that's then not the problem. Then the, the problem there is like, how do I even get adoption of my product, right? But inside the, kind of the enterprise context, no pun intended, that ends up being like, how do I even start this instrumentation? So I get enough decision trails that I can bootstrap the process. That ends up being the, the interesting discussion.
Total valuable startups to you. Like you, you deal with like 80 of the Fortune 100, you, you target to the 2000s. Startups, you know, free tier, whatever, like they're not that, they're not worth that much.
Yeah. I mean, maybe I'll take the, the kind of founder CEO kind of point of view on this, right? Like, like a decade ago, right? We looked at our revenue and it was like a third, a third, a third. And like a billion and above was a third. And then there's like some kind of a mid-market kind of thing, right? And then a third was startups, right? And we just saw all the underlying metrics of the, of the billion and above segment was just so much better. And then we looked at all database companies at scale, also known as Oracle, but I have a DB2 as well and stuff like that. And 80 plus percent of their revenue was from the global 2000. So clearly that is where database companies monetize, right?
And so we kind of added all these things together and we said, okay, 100% what we need to do is lean in on the enterprise. And that was the right business decision. My CEO hat, love it, was super successful. That's why I can sit here today, all that good stuff, right? My founder hat was a little bit sad, right? Because startup people are my people, right? And, and they represent the future and all of that kind of stuff, right? And so now that we have this new generation of AI native startups happening, right? We're like, oh, now this is really important for us to be built into those architectures, right? And not necessarily maybe from generating tons and tons of ARR. I will always make more money from Bank of America as a kind of generic example, not saying anything specific of Bank of America.
But except we do have 20 of the 20 biggest banks in North America are customers. So you can derive from that what you want, right? So we have all of them, right? But I'm always going to make more money from the enterprise segment. But I think it's really important to just be part of the zeitgeist. And from that perspective, like getting the next generation of startups built on the FJ is, is really crucial and important.
I presumably startups are easier to onboard because they have less context than the larger companies. So I guess what have you prescribed so far in terms of like, you know, whichever segment you want. Honestly, both are interesting to me. What are the best practices so far? Like, you know, how do they even get started?
It depends on which altitude you operate at, right? Like, if it's a, if it's a single startup, it's not just there's one product, but the product is the company. So that's then everything, right? And that's very different if you look inside of the enterprise context, right? Because then we engage in two levels, right? One is the scope of a single application, a single project, right? And the other one is more enterprise-wide. This, let me talk about the last one for a moment, because this is a big change that has happened since certainly since the two years ago, the the graph rag talk. A clear pattern that we're seeing happening is we tend to call it the knowledge layer, but we bump into a lot of enterprises. And the problem is, okay,
every single data source is going to have some kind of an MCP endpoint here, right? Okay, I want to give my agents access to that. So like, what can I do? Either I give my agents access to all of the MCP endpoints and let it figure it out, right? The problem that they run into is that, yes, that works, but like some of the data is going to be conflicting, right? And so we just talked about we have a cloud service, right? Even for me, like when I tried to figure out like how many customers do I have on my cloud service? Like, I go to the actual cloud platform and I ask and we have, let's call it 3,000 customers, right? That means how many are active, have an account with a running database. And then I go to like
the finance system and I have 2,800 customers because those are the ones that were like with a credit card and the, you know, okay, so like, so how do you make sense of that, right? And I think we're learning that an LLM is going to give you an answer without doubt, right? You just have no idea if it's right or wrong, right? And it's very hard to find that out, right? And so what we're talking to a lot of big enterprises about now, right, is you want to own that layer or they want to own that layer, right? Where they consolidate the metadata around where data sits, right, inside of their enterprise. And that gives you the consistency and the trust and the explainability, right? And so what is that metadata that they want to own then?
It's basically the data asset landscape, right? So what are the schemas that sit in your relational database, right? What are the buckets in your S3 and so on and so forth, right? Express that in a graph form, marry it up with a business-facing ontology. What is a customer, right? Like, how does a customer relate to a supplier? And what are the concepts?
That's so hard. You talk to five different people, you get six answers.
That's exactly right. And this has been the key problem that has been holding this back in the past. What is happening now, of course, is I need to solve this to make my agent successful for this particular use case. So that forces them to kind of converge on something that is good enough to work for those agents, right? And then the third piece is kind of the mapping between, between. People talk about semantic layers. People talk about context layers. I like the term knowledge layer. They all mean kind of the similar but distinct things. But this is a very, very popular use case that we have right now.
If you, you were on our website, if you Google kind of leading media company or something like this, um, and Neo4j, you're, you're going to see this and it has like a nice little architecture in green that, that you can scroll down and if you can screen share that, you'll, you'll see it. And so you have like the disparate data silos at the, at the bottom and they, they call it the semantic layer, right? And then they have their agents running on top of that. There's a couple of flavors where you do kind of zero copy. So what the, what the knowledge layer will give you is the map of where I should actually go and query. Or sometimes we inline the data, like partial data into the knowledge layer. So you could just do the queries right in there.
Yeah. What, what is zero copy again?
I want to say Salesforce has coined, or at least popularized this term. This is where it's like, okay, instead of replicating your data in every single, like between Snowflake and this and that, right? Instead, you have like a virtualization type layer where it points to the original data source.
So foreign data wrapper.
Yeah, exactly, exactly, right?
You can tell I'm like very full scratch.
Yeah, yeah, that's right. And so the query path, you end up going to this layer and then you figure out where the data sits. And sometimes it's materialized into that layer. And so you can just query that directly. And so this is, this is a very popular use case, kind of enterprise wide. But I think your original question was like, okay, what are the best practices for, for getting started? We talked about context graphs. There's a, a really neat Python wrapper called U V X, like whatever, create context graph, right? That gives you a context graph out of the box for, I think, 22 different industries. It was just published like a few, a few days ago.
And it stands up a full, full Neo four J with a, with a front end and you can.
This is cool.
It is model and you're gonna love this weeks. It's modeled after, what was it called? Create React app.
Of course, of course.
And so you can have like this interactive, it'll help you with your own data. But you can also choose, you know, out of existing domains. And then.
Twenty two domains. Wow.
Yeah, exactly. Integrated with eight or nine different agent platforms.
Only wanted one and it's the one that's not here.
No, which one?
Social media.
Interesting. Yeah. Yeah, we can add that.
Yeah, yeah, yeah. Social, social graph is social media. This is, I have a view that every SaaS basically eventually becomes, has a, has a social graph inside of the SaaS with the off system. You know what I mean? You want people with teams. You want people who can message each other. You want to send notifications. You want to feed. Elements of social media find their way into every single one of these domains. It's like not even a, a, a vertical domain. It's just a, a, a feature set that I always, you know. I actually looked into doing this as a, as a business before and I, I found that other people have done it. And it, and it didn't work as a business. But basically, you know, drop in social media, uh, social, I guess, network
into my user base as a feature.
Into your end user base or into your employee base?
No, end user.
Yeah, yeah, yeah.
So you know what I mean, like, like, because, because every one of my users, they work in a team, they follow, they have, they want a feed, they want notifications, they want DMs, they want even blocking, whatever, right? They want a homepage. It's all social features that none of these people really would, would build themselves, but probably they want something. Maybe, maybe here, I don't know. Um, but yeah, anyway, this is really cool. Congrats to William. I, I know he's, he's done workshop at E I E's before.
Yeah, he's, he's phenomenal. And so what, what it does is it just helps you get started, right? And it creates some, either synthetic data, it also integrates with like a bunch of SaaS tools, like, uh, I saw you were excited about the, what is it called? The Google Workspace CLI or something like this, right?
Everyone is excited about that. I mean, you see the number of likes on that one.
I know, it is shocking.
Do you know how? Okay. So I got so excited about Cloud Co-Work because I could use it to navigate the GCP dashboard. I was like, I don't want to do, this is so bad.
But so, so it can, can it get you real data or it can generate synthetic data for you?
No, it's fantastic. Yeah.
It, it, it uses, we have an, like an agent memory kind of toolkit, which has either short-term memory. So that's kind of the conversational state type stuff. It has long-term memory. So that's those are all the entities and all the concepts in the domain. And it also has the decision traces, so the context graph. So it can put it all together with the, the graph visualization, kind of U I, and all that kind of stuff, right? So that's a great way to get started.
It's, it's a great idea. I can't believe no one else has done it. I can't believe this is only six days old. Yeah, you should, you should promote this a lot.
And, and you can imagine, it's the same story. Like he, he hacked it up one Sunday afternoon, like this. So I guess five days ago, six days ago, Sunday afternoon, ahead of a context graph meetup that we, that we did and people love it.
Yeah, yeah, yeah. Okay. If, if I have one feedback looking at this, it, it almost does too much. Almost, it's like.
Um, where does it end and where does my app begin? There's, there's a lot here and so I'm already feeling a little bit overwhelmed with this read me. So some focus is valuable, you know, it's one of those things where like open code. You know, the open code CEO Dax was like, look, in an age where any feature you can just vibe coded within days. Actually restraint and focus and like, you know, fit for purpose is, is this the thing? Because yeah, you can add it, but like, does it actually add anything? Or is it just more stuff that just fills up my context window? And I'm just like, okay, what is the job that you do for me and just do it really well, you know? So I do think like this is one of those things.
Back to the kind of Steve Jobs, I'm the editor of the product. Kind of thing. And of course, the most important part of the editor is saying no, like removing things.
You know, that's, that's a quick tour. Obviously, there's a lot more going on in your world that we'll, we'll learn about. Yeah. Any, any parting thoughts outside of your, your official hat, your, your hacker at heart? What else are you excited by? What do you get to super excited?
Well, I mean, we have, it's like this era that we live in right now is simultaneously the most exciting time and the most shocking time. We haven't talked at all about kind of SaaS apocalypse and all of that kind of stuff. But you know, with the other hat as a CEO, I have to pay attention to, to, to things like that. And of course we were kind of front and center in like starting to see the shift of the buy versus build. Right? Because you know, Klarna was one of the first examples of, you know, shutting down.
They both tried it and then also rolled it back.
That, that is the public view, right? They certainly, I'm not going to speak for Klarna, but I, I think there is overstatement on both sides of that, of that probably, but, but clearly there's a shift in that buy versus build. Right? But then for me personally.
For me, I pay 200,000 a year for conference management software that I hate like, you know? Maybe to pay, pay two thousand to, to make one that I like.
That's shocking that you of all people haven't fixed that.
I'm busy running, you know, like printing badges and like freaking figuring out my magician costs and everything, you know, like I, this, this is not like top of my list. And I have a team that isn't as agent native as me. So I cannot just like unilaterally as like, as like a CEO, like just decide, oh, like my whole company is going to do this now. And expect that every single one of my employees will know what to do because no, they need to be trained. And actually, sometimes the, the familiar buggy, slow, whatever system, with all its flaws, actually still is better.
And, and it's, it's back to like, what, what is the value of these things? And a big part of it is understanding processes and being prescriptive about those processes, right? And this takes us some while to iterate there and you could do it if you focused on it. But in the meantime, you're going to pay for the two of you, right? So, so I get it, but, but so that's kind of on the terrifying side or like the shocking side or something like this, right? And then on the other side is just, man, the ability to build. And remember, like I, I'm kind of post-technical, right? Like, so I couldn't write the, the compare and swap stuff is like, that's the kind of stuff that I know, right? But I haven't been a modern real programmer for ten years, right?
And now again, I can like software is malleable again, which is just so phenomenally exciting.
Yeah, but I think one, one failure mode of the post-technical, you know, like manager, which you are, which I am, is that you think you, you, oh, AI can do it. And then you like, you know, you vibe code something, you throw it to your, your employees and then you expect them to just pick it up. No, I saw like, I, you know, I do, I do want to encourage the leaders among us to also just be respectful of uh, the fact that not everything is vibe coded and your employees still have to clean up your mess sometimes if you do this.
Of the real craft, I completely agree, especially like as a database company, like, man, that there's some, some real craft in that.
Yeah, but you guys test very well, you know what I mean? Like the database testing is, is top notch, most software is not tested like this. You know, so yeah, actually, I know because, because you can test so much, then you can vibe code more because it's so, so testable, you know what I mean?
Yes.
So anyway, anyway, thank you, this is a really fun chat. And I'm excited to catch up in person. I think you're coming to, to San Francisco, um, so I'll see you there.
Bye bye my friend, talk soon. Alright. Alright.
Page updated October 26, 2026 · transcript and summary are machine-generated
