theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems | Jesus Barrasa, Neo4j | Neo4J GraphSummit NYC 2026

Clips
More from theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems

Jesus Barrasa

Field CTO, Gen AI

Neo4j

play_circle_outline Knowledge Graphs and Ontologies: Structured Retrieval for Grounding LLMs and Agents

play_circle_outline Knowledge layer: curated, governed representation of enterprise knowledge and semantics

play_circle_outline Sovereignty: enterprises must own and control their knowledge and guidance to agents

play_circle_outline LLMs accelerate ontology construction, mapping, and business logic capture

play_circle_outline Best practice: start with a minimum viable ontology and align subsequent use cases

Info

Jesus Barrasa, Neo4j | Neo4J GraphSummit NYC 2026

Jesus Barrasa

Field CTO, Gen AI Neo4j

search

John Furrier

>> Palo Alto Studio Connection, Silicon Valley and Wall Street. I'm John Furrier, co-hosting theCUBE here with Dave Vellante, my co-host. Well, I'm John Furrier, your host of theCUBE. We are here in New York City for Neo4j Graph Talk. We were in San Francisco a month or two ago. We talked to the leaders there, and here's the story here. Graph databases are making it happen. Neo4j is on a tear with great momentum as graphs and knowledge graphs and ontologies become the center stage conversation of the industry as AI moves into more of an integrated data model for low latency, highly accurate, trustworthy content. Jesús Barrasa here is the Field CTO at Neo4j. He's got all the data. He's a Mixture of Experts as part of our series, pun intended. Jesus, great to see you. Thanks for coming on theCUBE here at your event.

>> It's a pleasure. Thank you very much for having me. Right.

John Furrier

>> And Emil came into the New York Stock Exchange at our studio there, our new NYSE Wired brand, which is kind of like the intersection of tech and money. And when you see the momentum, and I saw some of the stats you guys had on an amazing last quarter, bigger than all of last year. So good job on the business performance. But absolutely, the driver of that is the fact that what's gone mainstream is that it's becoming well known in the enterprise and in large-scale data sets where graphs combined with other data are becoming the standard way to architect the future AI platforms because there's so much context. This knowledge graph is key. We're seeing it with Palantir, he's throwing a bunch of haymakers. I'm talking about ontologies, which have been around for a long time, but with AI, ontologies become important. They are part of the knowledge graph, but databases still are hanging around. You can connect them all together like a brain. This is the top story. Can you believe it?

>> Absolutely. Absolutely. It's unbelievable. But yeah, and now it's kind of well understood and well accepted that this is a perfect match, right? So you really need knowledge graphs to ground the behavior of LLMs. And we see that organizations are maturing in the sense that now the construction of agents becomes a reasonably well understood discipline. So harnesses, guardrails, orchestration, evals. This is kind of a well-understood discipline, but we still see massive differences between organizations and we ask ourselves, so they know how to build agents, they have access to frontier models. What's the difference? Well, the difference is exactly the context. How do they present their data to agents so that they can do meaningful tasks? And that's where we're doing a lot of work.

John Furrier

>> So yeah, that's how I want to get into some of the things that have changed. I know there's been some acquisitions lately. Tools are getting easier, but the knowledge layer in particular has become center stage because of the contextual. And there's a lot of sovereign— there's so many issues that are being tackled and resolved with it. But one of the things that's been validated in the market is that the AGI or general intelligence that the frontier models have cracked the code on, which is basically crawling the internet, have gotten smarter, but they don't crawl the enterprise data. So you have this specialized intelligence emerging. And you're seeing successful companies like Fireworks, open source weighted models are now popular because people are taking the intelligence of the LLMs and the frontier models and tuning, creating them for their own specialism, which is basically their domain. And they work together, right? So there's a whole new fusion of models, approaches, and the specialty model plays well into graphs because Why wouldn't I want to put all my company data in there? Talk about that unique feature.

>> Yeah, totally. So that's, ultimately, models, agents are going to have to access data. And this is the whole idea of tools exposed to agents. But again, how the data is structured really determines the collection of retrieval strategies and how much value can agents get from your data? And then we're seeing that is also an opportunity to capture, because yes, you were talking about ontologies a minute ago, and you have to give agents not only access to your data, but also to your meaning, to your enterprise knowledge. And that's unfortunately not always well captured. It's not always well represented. It's sometimes in people's heads and sometimes in documents that can't be— so the idea of bringing it all together in a controlled, curated, we call it a knowledge layer. It's not only a way of making agents more consistent, more trustable, but it's also a way of investing in the DNA of your organization, right? It's capturing the knowledge, managing it in a way that really is a massive investment for organizations.

John Furrier

>> Yeah, and the knowledge layer, obviously we were talking about that and the role of context has become mainstream. I want you to define that, what a knowledge layer is, because when you think about over the past, let's go back 7 years, okay? We've covered the rise of the data lakes, which came out of the Hadoop, Spark, and now seeing Snowflake and Databricks being successful. That's great for analytics. Yeah. And they ran the table on that, continue to thrive. Anyway. Ontologies have been there, but then there's always a harmonization layer, semantic layer. There's been all these buzzwords.

>> Yeah.

John Furrier

>> What is a knowledge layer? Define the term and how are people looking at this and architecting this in their data platforms?

>> So the knowledge layer is a curated, is a governed representation of the enterprise knowledge. And that's, enterprise knowledge is a large word, but we understand it in a layered fashion. So the knowledge of an organization starts with your data assets. You talk about data lakes, data warehouses. But then there's data product definitions, there is ontologies, and we can talk more about those because this is a hot topic these days. But some formal definitions, a formal representation of the concepts that are relevant, the rules, the policies, the behaviors. And then there's the possibility of modeling also even business processes. So all this is enterprise knowledge, right? And this is about being able to manage it as if it was data. In a way that you can apply software development principles like, can I version my knowledge? Can I query my knowledge? Can I do a diff between today's knowledge and yesterday's? This kind of thing is super important. And that's what we're building into this.

John Furrier

>> The relationships, it's all about knowledge, not about whether it's structured or unstructured. You can catalog

>> it.It's all connected. It's a connected representation that basically captures the knowledge and exposes it in a way that agents and any kind of applications

John Furrier

>> can.Let's get into some of your field CTO expertise because, a lot of people I've heard stories of, rebuilding. Oh yeah, we go down a road and they got to walk it back. There's a lot of debt and/or just mistakes. And then there's companies that have been successful. Take us through what's going on, out in the marketplace with customers.

>> Well, the way organizations approach agents is exactly what you say. So they identify a single problem and they build the knowledge that the agent requires in the agent itself in the form of prompts, in the form of skills. But then what happens? They build agent number 2. They're going to do exactly the same thing. So we're repeating the errors that we made 7 years ago when we were building reports in different platforms and getting inconsistent results. So what we're saying is, okay, let's build thinner agents and let's build more of that knowledge in this layer. But the reality is the way we are today is organizations are, yeah, we're building a lot. The cost of building agent number 3, agent number 4, is the same cost of building agent number 1. So they're not learning. They're not. So that's the reality, unfortunately.

John Furrier

>> I was talking to someone about governance. I want to bring in sovereignty because, people that, okay, we trained, we got agents. Here's the data that they've been guardrailed with or injected. And what happens is like humans, we obey a set of laws, don't run the stop sign. I watch the red light when I'm driving a car. Okay. Laws can be imposed, governance can be imposed. What's happened with agents in the lack of data, they make up their own laws. So this becomes a very big issue. And I want to bring this up because you can't just say this is the situation. It's almost like, hey, there's a revolution going on in the agent world, but they'll make up their own laws. This is actually happening. Absolutely. You're smiling. So what's your position? I was just going to say that it's—

>> I said a minute ago that we're making the same mistakes. The problem is a mistake back then in the BI time. revenue numbers are not aligning if you query them in this report or in this other one. That's one thing. But now the problem is agents are giving us, with a lot of confidence, answers that are sometimes made up. And it's really, really hard. before you'd see the two numbers that aren't aligned, but now how can you tell when an agent tells you so confidently that this is that? And so, critical element, and I don't think we have talked about it yet, but this knowledge layer, this idea of capturing your enterprise knowledge and using it as the context engine for your agents, not only gives you the consistency that we were talking about before, it gives you the explainability. So not only the agent gets an answer, you will be able to tell, and that is the path that I follow. That's the source of my data. These are the elements that I use to produce the answer. So that's—

John Furrier

>> And the conversation we're hearing in the doom and gloom and all the AI noise is trustability. Safety is a big conversation. We hear safety, the AI is going to kill us. That stupid remark by the Anthropic guy, completely debunked, but the press jumped on it. But if you look at the real techies that are doing the work, this is not— it's always been reining in the chaos after you kind of get it. It's always a lot of people working on this. But when you look at robotics and AI, you look at robotics, specifically autonomous vehicles, robots, The safety is physical. And so there's a lot of work going on here. And then on the enterprise side, trust is I don't want the wrong answer because if AI spits out a cash machine ATM or something, there's money involved, right? So there's money here and this one thing is life or death over here, right? So the people are working on this. Talk about the reliability piece, how this fits in with that.

>> One thing is getting a wrong answer when you're interacting conversationally. And another thing is an agent taking an action, opening an account, closing an account, and then the impact of mistakes at that level is significantly higher. So yeah, trust is— and so there's highly regulated industries where you want to give certain freedom to agents, but sometimes they have to operate within very well-defined flows of action for certain tasks. So being able to produce this kind of guardrail is critical. So that's a fundamental characteristic of the knowledge layer.

John Furrier

>> Talk about when you have intelligence, you have the knowledge layer, you have the context. Talk about sovereignty because Sovereign AI has become an infrastructure opportunity and challenge as well as a revenue opportunity. it's not just geography in terms of countries and whatnot, but also an enterprise would look at their environment as sovereign. So sovereignty has moved into the definition of the enterprise because they do have domains. Now they might be multinational.

>> Absolutely.

John Furrier

>> And so domain-specific things are really—

>> Absolutely. And that— and there's this like you said before, there's things that you don't want to delegate to the LLM, even if they're getting better and better, they will never be trained on your enterprise data. And not only because that's not possible, that could be possible, but you want to own that part. So you want to really be sovereign on that front. So be, owning the way in which knowledge and guidance to the agents is provided is your IP, is like I was saying before, is your enterprise's DNA. So that's a—

John Furrier

>> Well, we know what's going on. Graphs are hot. We see ontologies and knowledge layer. We know what it means. It means business value, better AI. What's next? Because implementation is always a big deal. Where does it fit? Are the tools getting better? Take us through what's coming, what's happening next. Absolutely.

>> So the what's great is that yes, you want to have a governed and controlled and own the way in which agents act at execution time. But the great thing is that LLMs are fantastic at construction time. We've talked about you have to build the ontology at the core of the knowledge layer. Well, it turns out that LLMs are fantastic at helping us accelerate and making it really, really a lot easier to construct because this is a thing that has to be built. It's not the kind of thing that, you're going to have. Of course, we have our offering and—

John Furrier

>> Well, in the old days, they did it by hand and you had to manually construct. You're saying the LLMs are dream scenario for that?

>> Totally. we're seeing the construction of ontologies. there's methodologies for building them and It's already been years since the result of LLMs producing ontology and documenting them is, I would say, a few years ago it was indistinguishable from experts. Now they're probably way ahead of what they can do. And the acceleration and the improvements that they introduce is incredible. So yeah, not only the AI is contributing to accelerating the construction and the mapping of the sources to the ontology, to the capturing of the business logic. So it in itself is a big accelerant.

John Furrier

>> Well, here in New York, you have all your partners and you have a lot of practitioner customers. So you guys have been tearing it up on the growth side. Congratulations. What's the best practice? What are you seeing as the successful pro tip? Where does Graphs fit in? How can I get involved, lean in quickly? How do I get this end-to-end more holistically versus, you know, point applications? How do I bring it out?

>> Well, how would I put it? our friends at Gartner call it this kind of minimum viable ontology, but you want to start with, you know, one use case. And when you build use case two, you have to try to align it to number one. So, and that's how you build the knowledge layer. You build it incrementally. It's meant to be across use cases and ideally enterprise-wide, but at least departmental-wide. And so it's, you know, identify use case, realize value, and then build from there. And the construction of the ontology, like I was saying before, is something that LLMs can accelerate significantly.

John Furrier

>> If we were in a whiteboard room and we were— my whole team's here and I'm a customer. What's on the conversation agenda? What's on the whiteboard? Is it architecture? Is it connecting the datasets? What would be the workflow of that meeting?

>> Absolutely. So the first is identifying relevant datasets, and normally that will be disparate and they will be governed independently. So bringing them together, sometimes that's not possible. Data has to stay where it is, but being able to capture the way they relate to each other, how they can be explained in business terms, or how they can be overlaid by an ontology is step number one. So identifying how these map to the ontology and then how they link to each other, how they can be exposed to it.

John Furrier

>> Okay, I might raise my hand and say, whoa, whoa, hold it right there, because I don't want to move a lot of data around. There's been some new capabilities. Speak to this because this is a huge breakthrough.

>> Absolutely. So what we're doing is we're opening the spectrum. So Neo4j is a native graph database, which means we have our own specialized ways of storing data that's built to get the best possible performance when we traverse data and we navigate the graph. But then, like you say, in some cases it doesn't make sense or it's not possible to move the data into the graph, but we still want to have the graph experience. We still want to navigate. We still want to explore connections. So what we're announcing is this concept of a virtual graph. So you can define a graph model on top of typically relational data. And then the query engine takes care of translating your Cypher query, your graph pattern into some SQL in the underlying data stores. So what that gives us is, we don't have to think of it as a separate product. It's more of a capability. And in your graph, in your specific problem, you will identify it. So it's a design exercise. You will define which parts of your graph have to be native, have to be persisted, 'cause you wanna get the best performance, and which other parts might be data that stays what it is and that you query on the fly via this virtual graph.

John Furrier

>> Yeah, and I'll point out, Emil, on my interview yesterday, a founder talked about the ISO standard. You have SQL and now you have Graph Query Language.

>> GQL, of course.

John Furrier

>> Yeah, so talk about that because we all know SQL, which by the way, then it moves into the network. So there's a lot more goodness coming, of course.

>> And it's great. one of the reasons relational went mainstream back, 40, 50 years ago is because there was a standard query language. And with some small variations, you could write your query and have it run in Oracle, have it running in Postgres. So we didn't have that in graphs. And that was a limitation because you always had inevitably that impression if you build something in Cypher, you're kind of married to Neo4j and you have kind of this vendor lock-in. The great thing is now we have a query language standard. Standard. Exactly, which is created by the same ISO standards body that created SQL back in the day. And now it's kind of, we don't own

John Furrier

>> it.What's the learning curve on the graph language?

>> I think,

John Furrier

>> know.Wouldn't, say, AI help there too?

>> mean.Well, now AI doesn't, no one even wants to learn how to write queries. So agents will do it, but it's still in the SQL queries for

John Furrier

>> sure.'Cause you just say what you want and it just. And the agent will run it. Understands

>> intent.Because if you think of it, query language is a small, easy subset of programming, which is something that’s

John Furrier

>> largely—it's like a static query. Because I would have to— I used to do a lot of queries, SQL queries. I'd have to figure out the business logic intent, write the query. Yeah, the queries are getting bigger and bigger. It's structured data. It's a pain in the butt. Everyone knows it. Absolutely. Now you just say what you want and it just does it for you, figures out the

>> queries.Totally, totally. And they're so good at that. And that's one of the typical, I would say the most powerful kind of retrieval strategies to be able to expose your graph ontology, what the shape of your data is, and then an LLM will be able to generate, in our case, the SQL, but sorry, the GQL, the Cypher. But to your point, anyone who's written SQL will have a smooth transition into GQL.

John Furrier

>> Yeah, they'll like it.

>> What you're doing is you don't have to write joins. You don't have to link a table to another table. You can basically express it with a kind of a

John Furrier

>> very—gives them a superpower because they can use their data structure knowledge and basically be more efficient, drive the AI.

>> There's something really, really powerful in GQL. And of course, anything that you could do in relational, you would be able to express it because ultimately, like I say, you translate the joins into relationships, but you can write purely structural queries, which is something that goes beyond what relational databases can do.. And this is so important when you're doing, let's take financial crime. You're looking for fraud and fraud might be a particular shape in your data, a sequence of transactions that happen in a particular order forming like a shape, like a ring. Finding a ring is not an easy task. Think of a SQL query that would find you a

John Furrier

>> ring.It's like finding a needle in a haystack of

>> needles.Exactly. It would be a chain, a variable length

John Furrier

>> set All right, final question. I know you got to go and we're on a crazy schedule. One of the things that's coming out of this era of AI is that things like Graph Query Language, your Neo4j customers and other people doing great work, they have faster time to value, to revenue. And I'm not saying that other work didn't do it, but it was a longer horizon. You build an analytics system, you sell it around, people will do it. You've got a good data platform, people are using applications, kind of the downstream aha factor of doing the ROI was a little bit longer. Yeah, maybe harder. You're seeing people getting real faster success. Talk about that ROI piece because it's not just classic ROI because you're driving significant breakthroughs faster.

>> Yeah, I like to differentiate because, like you say, in the individual use case or individual agents, you can quantify the ROI. But I like to think of ROI now in this new world of the context engine, of the knowledge layer. You really want to quantify ROI in terms of what I was describing before. You want to measure how the construction of Agent 2 and Agent 3 and Agent 4 goes down as you go, because you're building knowledge in the layer and then you're clearly investing in this kind of smart substrate that's capturing your enterprise. So that's one metric that shows ROI. Another one is in what way? one is actually a negative metric. So what's the cost of drift. What happens when two agents return diverging results or act in different ways? What's the cost of reconciling these results? That's something that a knowledge

John Furrier

>> layer—Because they don't have the right context.

John Furrier

>> Exactly.They might come back with different

>> things.So these kinds of new metrics that go in the direction of reusability, which parts of your knowledge, which parts of your ontology are being continuously reused by multiple agents. So these are the metrics

John Furrier

>> that—Well, we have to continue the conversation because what's happening now is the data values compounding versus data gravity, which was a bad thing. And I thought it would never be solved, but in a way we're starting to see some value with the data gravity problem with faster retrieval, intelligence compounds.

>> Absolutely.

John Furrier

>> Thanks for coming on theCUBE, appreciate it.

>> It's been a pleasure.

John Furrier

>> I'm John Furrier here at GraphSummit New York City. theCUBE coverage, we'll be right back after this break.

Jesus Barrasa, Neo4j | Neo4J GraphSummit NYC 2026

search

John Furrier

>> Palo Alto Studio Connection, Silicon Valley and Wall Street. I'm John Furrier, co-hosting theCUBE here with Dave Vellante, my co-host. Well, I'm John Furrier, your host of theCUBE. We are here in New York City for Neo4j Graph Talk. We were in San Francisco a month or two ago. We talked to the leaders there, and here's the story here. Graph databases are making it happen. Neo4j is on a tear with great momentum as graphs and knowledge graphs and ontologies become the center stage conversation of the industry as AI moves into more of an integrated data model for low latency, highly accurate, trustworthy content. Jesús Barrasa here is the Field CTO at Neo4j. He's got all the data. He's a Mixture of Experts as part of our series, pun intended. Jesus, great to see you. Thanks for coming on theCUBE here at your event.

>> It's a pleasure. Thank you very much for having me. Right.

John Furrier

>> And Emil came into the New York Stock Exchange at our studio there, our new NYSE Wired brand, which is kind of like the intersection of tech and money. And when you see the momentum, and I saw some of the stats you guys had on an amazing last quarter, bigger than all of last year. So good job on the business performance. But absolutely, the driver of that is the fact that what's gone mainstream is that it's becoming well known in the enterprise and in large-scale data sets where graphs combined with other data are becoming the standard way to architect the future AI platforms because there's so much context. This knowledge graph is key. We're seeing it with Palantir, he's throwing a bunch of haymakers. I'm talking about ontologies, which have been around for a long time, but with AI, ontologies become important. They are part of the knowledge graph, but databases still are hanging around. You can connect them all together like a brain. This is the top story. Can you believe it?

>> Absolutely. Absolutely. It's unbelievable. But yeah, and now it's kind of well understood and well accepted that this is a perfect match, right? So you really need knowledge graphs to ground the behavior of LLMs. And we see that organizations are maturing in the sense that now the construction of agents becomes a reasonably well understood discipline. So harnesses, guardrails, orchestration, evals. This is kind of a well-understood discipline, but we still see massive differences between organizations and we ask ourselves, so they know how to build agents, they have access to frontier models. What's the difference? Well, the difference is exactly the context. How do they present their data to agents so that they can do meaningful tasks? And that's where we're doing a lot of work.

John Furrier

>> So yeah, that's how I want to get into some of the things that have changed. I know there's been some acquisitions lately. Tools are getting easier, but the knowledge layer in particular has become center stage because of the contextual. And there's a lot of sovereign— there's so many issues that are being tackled and resolved with it. But one of the things that's been validated in the market is that the AGI or general intelligence that the frontier models have cracked the code on, which is basically crawling the internet, have gotten smarter, but they don't crawl the enterprise data. So you have this specialized intelligence emerging. And you're seeing successful companies like Fireworks, open source weighted models are now popular because people are taking the intelligence of the LLMs and the frontier models and tuning, creating them for their own specialism, which is basically their domain. And they work together, right? So there's a whole new fusion of models, approaches, and the specialty model plays well into graphs because Why wouldn't I want to put all my company data in there? Talk about that unique feature.

>> Yeah, totally. So that's, ultimately, models, agents are going to have to access data. And this is the whole idea of tools exposed to agents. But again, how the data is structured really determines the collection of retrieval strategies and how much value can agents get from your data? And then we're seeing that is also an opportunity to capture, because yes, you were talking about ontologies a minute ago, and you have to give agents not only access to your data, but also to your meaning, to your enterprise knowledge. And that's unfortunately not always well captured. It's not always well represented. It's sometimes in people's heads and sometimes in documents that can't be— so the idea of bringing it all together in a controlled, curated, we call it a knowledge layer. It's not only a way of making agents more consistent, more trustable, but it's also a way of investing in the DNA of your organization, right? It's capturing the knowledge, managing it in a way that really is a massive investment for organizations.

John Furrier

>> Yeah, and the knowledge layer, obviously we were talking about that and the role of context has become mainstream. I want you to define that, what a knowledge layer is, because when you think about over the past, let's go back 7 years, okay? We've covered the rise of the data lakes, which came out of the Hadoop, Spark, and now seeing Snowflake and Databricks being successful. That's great for analytics. Yeah. And they ran the table on that, continue to thrive. Anyway. Ontologies have been there, but then there's always a harmonization layer, semantic layer. There's been all these buzzwords.

>> Yeah.

John Furrier

>> What is a knowledge layer? Define the term and how are people looking at this and architecting this in their data platforms?

>> So the knowledge layer is a curated, is a governed representation of the enterprise knowledge. And that's, enterprise knowledge is a large word, but we understand it in a layered fashion. So the knowledge of an organization starts with your data assets. You talk about data lakes, data warehouses. But then there's data product definitions, there is ontologies, and we can talk more about those because this is a hot topic these days. But some formal definitions, a formal representation of the concepts that are relevant, the rules, the policies, the behaviors. And then there's the possibility of modeling also even business processes. So all this is enterprise knowledge, right? And this is about being able to manage it as if it was data. In a way that you can apply software development principles like, can I version my knowledge? Can I query my knowledge? Can I do a diff between today's knowledge and yesterday's? This kind of thing is super important. And that's what we're building into this.

John Furrier

>> The relationships, it's all about knowledge, not about whether it's structured or unstructured. You can catalog

>> it.It's all connected. It's a connected representation that basically captures the knowledge and exposes it in a way that agents and any kind of applications

John Furrier

>> can.Let's get into some of your field CTO expertise because, a lot of people I've heard stories of, rebuilding. Oh yeah, we go down a road and they got to walk it back. There's a lot of debt and/or just mistakes. And then there's companies that have been successful. Take us through what's going on, out in the marketplace with customers.

>> Well, the way organizations approach agents is exactly what you say. So they identify a single problem and they build the knowledge that the agent requires in the agent itself in the form of prompts, in the form of skills. But then what happens? They build agent number 2. They're going to do exactly the same thing. So we're repeating the errors that we made 7 years ago when we were building reports in different platforms and getting inconsistent results. So what we're saying is, okay, let's build thinner agents and let's build more of that knowledge in this layer. But the reality is the way we are today is organizations are, yeah, we're building a lot. The cost of building agent number 3, agent number 4, is the same cost of building agent number 1. So they're not learning. They're not. So that's the reality, unfortunately.

John Furrier

>> I was talking to someone about governance. I want to bring in sovereignty because, people that, okay, we trained, we got agents. Here's the data that they've been guardrailed with or injected. And what happens is like humans, we obey a set of laws, don't run the stop sign. I watch the red light when I'm driving a car. Okay. Laws can be imposed, governance can be imposed. What's happened with agents in the lack of data, they make up their own laws. So this becomes a very big issue. And I want to bring this up because you can't just say this is the situation. It's almost like, hey, there's a revolution going on in the agent world, but they'll make up their own laws. This is actually happening. Absolutely. You're smiling. So what's your position? I was just going to say that it's—

>> I said a minute ago that we're making the same mistakes. The problem is a mistake back then in the BI time. revenue numbers are not aligning if you query them in this report or in this other one. That's one thing. But now the problem is agents are giving us, with a lot of confidence, answers that are sometimes made up. And it's really, really hard. before you'd see the two numbers that aren't aligned, but now how can you tell when an agent tells you so confidently that this is that? And so, critical element, and I don't think we have talked about it yet, but this knowledge layer, this idea of capturing your enterprise knowledge and using it as the context engine for your agents, not only gives you the consistency that we were talking about before, it gives you the explainability. So not only the agent gets an answer, you will be able to tell, and that is the path that I follow. That's the source of my data. These are the elements that I use to produce the answer. So that's—

John Furrier

>> And the conversation we're hearing in the doom and gloom and all the AI noise is trustability. Safety is a big conversation. We hear safety, the AI is going to kill us. That stupid remark by the Anthropic guy, completely debunked, but the press jumped on it. But if you look at the real techies that are doing the work, this is not— it's always been reining in the chaos after you kind of get it. It's always a lot of people working on this. But when you look at robotics and AI, you look at robotics, specifically autonomous vehicles, robots, The safety is physical. And so there's a lot of work going on here. And then on the enterprise side, trust is I don't want the wrong answer because if AI spits out a cash machine ATM or something, there's money involved, right? So there's money here and this one thing is life or death over here, right? So the people are working on this. Talk about the reliability piece, how this fits in with that.

>> One thing is getting a wrong answer when you're interacting conversationally. And another thing is an agent taking an action, opening an account, closing an account, and then the impact of mistakes at that level is significantly higher. So yeah, trust is— and so there's highly regulated industries where you want to give certain freedom to agents, but sometimes they have to operate within very well-defined flows of action for certain tasks. So being able to produce this kind of guardrail is critical. So that's a fundamental characteristic of the knowledge layer.

John Furrier

>> Talk about when you have intelligence, you have the knowledge layer, you have the context. Talk about sovereignty because Sovereign AI has become an infrastructure opportunity and challenge as well as a revenue opportunity. it's not just geography in terms of countries and whatnot, but also an enterprise would look at their environment as sovereign. So sovereignty has moved into the definition of the enterprise because they do have domains. Now they might be multinational.

>> Absolutely.

John Furrier

>> And so domain-specific things are really—

>> Absolutely. And that— and there's this like you said before, there's things that you don't want to delegate to the LLM, even if they're getting better and better, they will never be trained on your enterprise data. And not only because that's not possible, that could be possible, but you want to own that part. So you want to really be sovereign on that front. So be, owning the way in which knowledge and guidance to the agents is provided is your IP, is like I was saying before, is your enterprise's DNA. So that's a—

John Furrier

>> Well, we know what's going on. Graphs are hot. We see ontologies and knowledge layer. We know what it means. It means business value, better AI. What's next? Because implementation is always a big deal. Where does it fit? Are the tools getting better? Take us through what's coming, what's happening next. Absolutely.

>> So the what's great is that yes, you want to have a governed and controlled and own the way in which agents act at execution time. But the great thing is that LLMs are fantastic at construction time. We've talked about you have to build the ontology at the core of the knowledge layer. Well, it turns out that LLMs are fantastic at helping us accelerate and making it really, really a lot easier to construct because this is a thing that has to be built. It's not the kind of thing that, you're going to have. Of course, we have our offering and—

John Furrier

>> Well, in the old days, they did it by hand and you had to manually construct. You're saying the LLMs are dream scenario for that?

>> Totally. we're seeing the construction of ontologies. there's methodologies for building them and It's already been years since the result of LLMs producing ontology and documenting them is, I would say, a few years ago it was indistinguishable from experts. Now they're probably way ahead of what they can do. And the acceleration and the improvements that they introduce is incredible. So yeah, not only the AI is contributing to accelerating the construction and the mapping of the sources to the ontology, to the capturing of the business logic. So it in itself is a big accelerant.

John Furrier

>> Well, here in New York, you have all your partners and you have a lot of practitioner customers. So you guys have been tearing it up on the growth side. Congratulations. What's the best practice? What are you seeing as the successful pro tip? Where does Graphs fit in? How can I get involved, lean in quickly? How do I get this end-to-end more holistically versus, you know, point applications? How do I bring it out?

>> Well, how would I put it? our friends at Gartner call it this kind of minimum viable ontology, but you want to start with, you know, one use case. And when you build use case two, you have to try to align it to number one. So, and that's how you build the knowledge layer. You build it incrementally. It's meant to be across use cases and ideally enterprise-wide, but at least departmental-wide. And so it's, you know, identify use case, realize value, and then build from there. And the construction of the ontology, like I was saying before, is something that LLMs can accelerate significantly.

John Furrier

>> If we were in a whiteboard room and we were— my whole team's here and I'm a customer. What's on the conversation agenda? What's on the whiteboard? Is it architecture? Is it connecting the datasets? What would be the workflow of that meeting?

>> Absolutely. So the first is identifying relevant datasets, and normally that will be disparate and they will be governed independently. So bringing them together, sometimes that's not possible. Data has to stay where it is, but being able to capture the way they relate to each other, how they can be explained in business terms, or how they can be overlaid by an ontology is step number one. So identifying how these map to the ontology and then how they link to each other, how they can be exposed to it.

John Furrier

>> Okay, I might raise my hand and say, whoa, whoa, hold it right there, because I don't want to move a lot of data around. There's been some new capabilities. Speak to this because this is a huge breakthrough.

>> Absolutely. So what we're doing is we're opening the spectrum. So Neo4j is a native graph database, which means we have our own specialized ways of storing data that's built to get the best possible performance when we traverse data and we navigate the graph. But then, like you say, in some cases it doesn't make sense or it's not possible to move the data into the graph, but we still want to have the graph experience. We still want to navigate. We still want to explore connections. So what we're announcing is this concept of a virtual graph. So you can define a graph model on top of typically relational data. And then the query engine takes care of translating your Cypher query, your graph pattern into some SQL in the underlying data stores. So what that gives us is, we don't have to think of it as a separate product. It's more of a capability. And in your graph, in your specific problem, you will identify it. So it's a design exercise. You will define which parts of your graph have to be native, have to be persisted, 'cause you wanna get the best performance, and which other parts might be data that stays what it is and that you query on the fly via this virtual graph.

John Furrier

>> Yeah, and I'll point out, Emil, on my interview yesterday, a founder talked about the ISO standard. You have SQL and now you have Graph Query Language.

>> GQL, of course.

John Furrier

>> Yeah, so talk about that because we all know SQL, which by the way, then it moves into the network. So there's a lot more goodness coming, of course.

>> And it's great. one of the reasons relational went mainstream back, 40, 50 years ago is because there was a standard query language. And with some small variations, you could write your query and have it run in Oracle, have it running in Postgres. So we didn't have that in graphs. And that was a limitation because you always had inevitably that impression if you build something in Cypher, you're kind of married to Neo4j and you have kind of this vendor lock-in. The great thing is now we have a query language standard. Standard. Exactly, which is created by the same ISO standards body that created SQL back in the day. And now it's kind of, we don't own

John Furrier

>> it.What's the learning curve on the graph language?

>> I think,

John Furrier

>> know.Wouldn't, say, AI help there too?

>> mean.Well, now AI doesn't, no one even wants to learn how to write queries. So agents will do it, but it's still in the SQL queries for

John Furrier

>> sure.'Cause you just say what you want and it just. And the agent will run it. Understands

>> intent.Because if you think of it, query language is a small, easy subset of programming, which is something that’s

John Furrier

>> largely—it's like a static query. Because I would have to— I used to do a lot of queries, SQL queries. I'd have to figure out the business logic intent, write the query. Yeah, the queries are getting bigger and bigger. It's structured data. It's a pain in the butt. Everyone knows it. Absolutely. Now you just say what you want and it just does it for you, figures out the

>> queries.Totally, totally. And they're so good at that. And that's one of the typical, I would say the most powerful kind of retrieval strategies to be able to expose your graph ontology, what the shape of your data is, and then an LLM will be able to generate, in our case, the SQL, but sorry, the GQL, the Cypher. But to your point, anyone who's written SQL will have a smooth transition into GQL.

John Furrier

>> Yeah, they'll like it.

>> What you're doing is you don't have to write joins. You don't have to link a table to another table. You can basically express it with a kind of a

John Furrier

>> very—gives them a superpower because they can use their data structure knowledge and basically be more efficient, drive the AI.

>> There's something really, really powerful in GQL. And of course, anything that you could do in relational, you would be able to express it because ultimately, like I say, you translate the joins into relationships, but you can write purely structural queries, which is something that goes beyond what relational databases can do.. And this is so important when you're doing, let's take financial crime. You're looking for fraud and fraud might be a particular shape in your data, a sequence of transactions that happen in a particular order forming like a shape, like a ring. Finding a ring is not an easy task. Think of a SQL query that would find you a

John Furrier

>> ring.It's like finding a needle in a haystack of

>> needles.Exactly. It would be a chain, a variable length

John Furrier

>> set All right, final question. I know you got to go and we're on a crazy schedule. One of the things that's coming out of this era of AI is that things like Graph Query Language, your Neo4j customers and other people doing great work, they have faster time to value, to revenue. And I'm not saying that other work didn't do it, but it was a longer horizon. You build an analytics system, you sell it around, people will do it. You've got a good data platform, people are using applications, kind of the downstream aha factor of doing the ROI was a little bit longer. Yeah, maybe harder. You're seeing people getting real faster success. Talk about that ROI piece because it's not just classic ROI because you're driving significant breakthroughs faster.

>> Yeah, I like to differentiate because, like you say, in the individual use case or individual agents, you can quantify the ROI. But I like to think of ROI now in this new world of the context engine, of the knowledge layer. You really want to quantify ROI in terms of what I was describing before. You want to measure how the construction of Agent 2 and Agent 3 and Agent 4 goes down as you go, because you're building knowledge in the layer and then you're clearly investing in this kind of smart substrate that's capturing your enterprise. So that's one metric that shows ROI. Another one is in what way? one is actually a negative metric. So what's the cost of drift. What happens when two agents return diverging results or act in different ways? What's the cost of reconciling these results? That's something that a knowledge

John Furrier

>> layer—Because they don't have the right context.

John Furrier

>> Exactly.They might come back with different

>> things.So these kinds of new metrics that go in the direction of reusability, which parts of your knowledge, which parts of your ontology are being continuously reused by multiple agents. So these are the metrics

John Furrier

>> that—Well, we have to continue the conversation because what's happening now is the data values compounding versus data gravity, which was a bad thing. And I thought it would never be solved, but in a way we're starting to see some value with the data gravity problem with faster retrieval, intelligence compounds.

>> Absolutely.

John Furrier

>> Thanks for coming on theCUBE, appreciate it.

>> It's been a pleasure.

John Furrier

>> I'm John Furrier here at GraphSummit New York City. theCUBE coverage, we'll be right back after this break.