Knowing Before Doing

You know, we've talked a lot on this podcast and outside of this podcast about knowledge management and how important it is. And I think what we've come to realize is that while we're excited about it, as I know you are excited about it, it's, it's a tough sell, right? It requires like a major mental model shift. And that's like in a moment where mental models for everything are starting to crumble all around us. So Maybe to kick us off, could you get us excited, like really pumped up about knowledge management and why graph DB is like such a critical piece of the puzzle?

Yeah, I think we should think broadly than that. think if you look at it, there's always an evolution in the software industry of where things are going and how new systems are being built. When we were building user... Yeah.

So, so broader than all the knowledge in the world.

See, main point is, historically we built these software systems that were primarily UI experiences for humans to put data in and get data out, and humans made all the decisions. with the evolution of AI and autonomous agents and ability for agentic systems to make great reasoning decisions if they had all the context is actually fundamentally changing what applications would look like going forward. And if autonomous agents and intelligent systems have to be built, you have to move away from historically we thought about collecting data, making data available to making knowledge available so they can become much smarter.

smarter and make intelligent decisions. I think fundamentally, historically knowledge management was also thought about, I will create a knowledge base with articles that a human can search and stuff like that. But that's not ⁓ where we are in the world now.

So I think the real question is for AI systems to become more intelligent and make autonomous decisions, how do you represent your organizational's data into knowledge that actually can be consumed by these systems and so that they become much more intelligent? And that is the fundamental shift that is happening. And I think I am excited about it because three years back, maybe we were only people talking about it and you guys were talking about it.

we see Gartner is talking about it, most and most customers are talking about it. I always assume whenever Gartner talks about something, they're predicting what's happening today more than future, right? Like it's like more people are interested in these AI systems. if you just look at the data, the amount of failures, right? Or 80 plus percent AI projects still fail in enterprises because they are not ready for

Finally! Yes! Mm-hmm.

these systems and most of that is because their data is not structured in the right way for agentic system. And so this is where I actually think Josh, I am excited about this evolution of next generation software systems that are going to be powered by AI, agentic reasoning, like through the large language models becoming more of a reasoning engine than just a natural language.

is actually great. And then if we can convert our data into knowledge to power those, and that will be the best map in building these systems. think that's why I think I'm excited, but I'm sure like the world is going to learn more and more. That's the only path to success going forward.

Yeah. Yeah, and I think your excitement is probably only eclipsed by mine for Neo4j, which is crazy. I sometimes feel more excited than you guys are about GraphDBs, which is pretty hard to believe because you guys are pretty excited. You created a whole system, the leading system for GraphDBs. just to put it in context,

Hehehehe. Hehehehe. You

The whole world is like, agentic AI, which I think is just going to disappear as a term, it's just going to be software again. But what happens when you hire an employee on the first day? Do they do stuff? or do they begin to know stuff? Right? On day one, they need to know stuff before they do stuff. You're not like, hi, this is the first day of brain surgery and here's your scalpel. Start carving away and next month we'll take a class on brain surgery. Right? It's like no one would do that. Right? So you begin with like,

Yeah. Yeah, that's correct.

First, we need these things to know stuff. And then once they know stuff and they know the right stuff, doing stuff's a piece of cake. The use cases can help form like

what knowledge you need to collect. and I think a lot of people don't understand this, that you don't have to start with these systems and collect all the information in your organization in one shot. You can do this low fidelity incrementally and you can do this over time. And the way you can drive priority of what knowledge to gather is by use cases. use cases to establish what knowledge you should assemble together. But then you go from the use case to the knowledge collection. And this is where I go to GraphDB, which I think you had the same problem we have. Like I see your world in my world as you're the no world. And I created an agent orchestration platform. We're the do world.

And you're right, I think the thing that becomes a challenge for many organizations is, is the knowledge means do I need to bring like this massive project about building one single knowledge layer, which they convert all my enterprise data? No, you're absolutely right. It does depend on what is the use case you're running. How do you build the knowledge around it? And then how do you provide more and more context around it so that these systems can make better decisions. And the graph database from a format and from the construct perspective, I think the biggest thing it brings to table is knowledge is never bounded by specific information because the information keeps growing and you dynamic to grow.

Exactly.

that information in different shapes and formats, right? if you just take simple things, your customers, your products, and the relationship between customer and a product, there are so many different kinds of relationships that you can have. You may have bought the product, you may have just viewed the product, you may have it in the cart, you may have it. reviewed it, you may have returned it, may have... lot of these things and how these relationships get formed between even two simple entities, like graphs are a great way to represent that and you can keep growing around it. What happens if that product now is in different markets and what the behavior on the market... I think building ever-growing knowledge... System is much easier in graphs than anything else. And so that's the one thing. And second, we're saying starting with use case that is, that you think about what value you want to add and add knowledge and build knowledge around it makes a lot of sense. But then you want to grow it and add more use cases on the same large knowledge.

base that you're creating for these systems. I think that's an important aspect. and then when you have the agent, which is actually going to make some decisions and do some activity, it's important to provide it with the relevant context that it needs happen is it has all the

Yeah. So yeah, we call that feature reduction you the wide knowledge of the world, right? But you need to reduce that down to the relevant context because too much knowledge can also be just as misleading to an agent as too little knowledge.

Yeah. Yes. Exactly. Remember in the machine learning world, which was the AI world that we loved calling machine learning and now everybody is going back and forth with terms. I will keep the terminology aside. But in machine learning and inferencing there, we always had feature stores. The goal of the store was to give the right set of features that were relevant for that particular. In the new world, if you map it back to the agentic systems, it's more of the context world. Like what is the context the agent needs to make decision and what context you want to provide to it, which is most relevant. Now, if the agent is supposed to go ahead and give, it's a support agent helping people with support activities on a product. ⁓ You want to give it what's relevant, who is the user or customer, what they bought, what is all the information about the product, anything else that is relevant, but giving it like all supply chain and where the product comes from and everything. Yeah. That is not helpful. One is cost and second is you will get more hallucinations because now really.

Yeah, like a million tokens of context and someone's like, how are you today? Fine.

Hahaha.

Overfitting, absolutely, yes.

You can't reason over too much information that is not relevant.

Yeah, it's like you start on your first day, you're going to answer some basic questions at the front door. And we start with the meaning of life. Like what? This is why I think AGI is the wrong direction for a lot of companies. think OGI is the right direction, organizational AGI. I think graph isn't about wide, it's about boundaries. It's about narrowing down the scope.

Exactly right, exactly right.

So that these things can be accurate, right? We're not in the world of more anymore. Now we're in the world of less. How do we bring this down and scope this down? Not get wider data, not get more knowledge in the world. It's how do I get the knowledge that is just the knowledge needed to complete this task successfully? Not too much and not too little, which

This is where people have a really hard time. And when I think about graph DBs, it was always been really helpful for me to think about like this complexity continuum, like data. What is data? Data is like a number, right? then you have information, which evolves. Like it's more than data. now the number is a date, Now we get from information to knowledge. Like a date becomes a birthday. And so now we have knowledge. It's still data. it's a number, it's a date, it's a birthday. And then we get to like wisdom, you're too young to drink, you're old enough to drive, you can vote. this is like the evolution of information. And so as you want agents to do more tasks, you can't feed them the number. You have to feed them the wisdom.

to actually complete the task. so Neo4j is like this layer that takes information and turns it into knowledge, right? Because it builds the context around what it is, wider than just it's a birthday. Now we can go to mapping. They can drink, they can't drink, they can vote, they're a customer, they're not a customer, they want to be a customer. All of these things are super, super relevant, if not mandatory for an agent to now produce any conversation of value. And tables have super limited context.

Yes.

whereas in graph, it's so loose that someone could just throw it in there. what I love about graph is you don't need to know the data you have to collect it. And you you can collect data. You're not even aware you wanted to collect in the first place, but you have a place to put it that now you can sort through it and know what you have. is like a whole new world. Sorry, I know I'm going on, but it's like, it's so important.

No, think Rob, I think you mean See, I think the main point is, historically systems for information collection were all about data collection. They were basically collecting data points, and a point is in a row and a column, a cell is a point. And then how do you focus on connecting with other things? In graphs, it's natural because we focus on relationships more than the data points. And the relationship is a customer buying something

is the relationship of buying and buying was from a customer to the product with the date and what they bought, all that, right? So any kind of a focus on relationship actually converts that data points into information. And then as you grow it more and more, I think it becomes more powerful. And I think I love this whole... transformation from information to knowledge where you can bring all these disparate data ⁓ elements and put that together in a knowledge graph where you have knowledge represented through relationships and all. And then I think your next step in the journey is intelligence, which is mostly orchestrating intelligence around it, making decisions on top of that knowledge and all. And then wisdom makes a lot of sense. And wisdom for me is ⁓ basically how do you track all the organizational activities, memory, context, so that it becomes a self-learning system. If an agent or agentic system forgets everything every time it did, it's like a goldfish. Like it will basically repeat the whole thing and it will never improve. The best way of like building a

self-improving system and a wiser system is you are able to go ahead and also track what it did last time, what went well and not and not just what the agent did but also what humans did. We can't build agentic systems assuming the whole world has ended on one day and next day the world is newly started and agents will figure it out. They have to learn from historically how things were done. Like if you are in claims processing, you want to know how humans made the past decisions on the specific claims decisions and what to learn from it. And then in future, when an agent makes that claims decision, you need to be able to record the decision.

You need to be able to audit the decision. You need to be able to say, what would human have done? And if there is an issue with that, it needs to become a self-learning system. And so for wisdom, it's not just information and knowledge that you have, but it's this next step of, I'm collecting what decisions are there. Decision traces are becoming collected. And then how do you improve that decision-making process? And that's how you build a continuously learning system. I think you have this in your book too where this journey from information to knowledge to intelligence to wisdom and I back to like okay technology wise I think graphs seem like a great place where you can bring this knowledge and the additional data required for wisdom. I don't think graph databases will be where the wisdom completely will run because you need the data and then you need the self-learning

Yes.

Yes. Yeah, it's the meta layer Like whether it's data or knowledge or wisdom, it's our cerebral cortex, right? The thing that sits above all of the pieces and the the storage that says, where do I go get this?

Yes. I know I love that Rob because this is exactly what we believe in is like there are three big parts to the puzzle in this right. One is ontologies, metadata. What I mean by that is what's the definition of the system and what is, where is what. Like it's also a semantic map. I don't like semantic layers because semantic layers were these BI terminology for defining a business definition of a metric. But semantic map is how does your organization, coming back to organizational AGI, what is where, what systems are where, what decisions are made by which systems, and within the system, what's the metadata that's available? So if you use Snowflake, you use Databricks, you use like a SaaS system like Salesforce, whatever.

So what are these systems? How are they interrelated? What decisions will be made in what? So that's one part of the stuff that you can build in the knowledge layer into the graph database. The second is the actual data. So the relationship between customer to product to like channel to whatever, that could be the data. But that data could be in the graph database directly natively stored for performance reasons and all because it will be much.

and all, but we can create virtual graphs now, this allows you to have virtual data, which is your data can stay where it is, but we give you a virtual graph on top of it, and then the last part is memory and context, like memory and context makes this continuous learning loop available, so bring ontologies, data, and memory together, and you have now the backboard.

for a self-learning intelligence agent that you can build for across your organization.

Right. Yeah. And we get a lot of questions now about agent registration services, right? It's now people are having agent sprawl, right? They're like, I've got so many agents. What do we offer that is an agent registry? it's like boiling a super complicated question down to like something very, very simple.

Yeah. Yes.

that isn't simple. agent registry sounds so simple, but it's so complicated. ⁓ And graph, it's really like, do you mean graph database? as if it's some sort of table with a bunch of stars beside it on this agent does this and this agent does that. But as you think about agent sprawl, and you think about

orchestrating agents across your organization, which is absolutely key because as you move up the hierarchy of tasks to more complex tasks, need you need these agents to be able to cross silos, right? They've got to cross systems, they've got to cross silos. You need some abstraction layer, some cerebral cortex across your organization that helps an agent go find where these things are. And what's nice is

Yes.

you stop caring where the data is. You don't care if it's in five different places, redundantly. It doesn't matter because as long as the graph knows where to get it, you're good. what I find interesting is people find the concept of graph DBs complex. I don't.

Yeah. You're good.

It makes perfect sense to me. it's so much less complicated than trying to manage all these disparate data systems. It's so much easier a concept to get your head around than understanding 20 different places that you store data. Like, it's in Salesforce, it's in Oracle. That is an unmanageable system. Whereas understanding how a graph works,

Yeah, you might have to take a couple weeks and take a class and it is a new way of thinking about data. But once you've got it, you've got it and it's simple now. Now all your data becomes a simple thing.

This is making me think too that like one thing that maybe isn't discussed enough is cost, right? Like I was just looking at a newsletter from Cassie Kozerkoff who's been on this show and I think would enjoy this conversation. And she had pointed out that the cost of AI is still exceeding the cost of employees. And that actually came from Brian Kotanzaro who's been on this podcast at Nvidia. And he's saying that their compute costs are far beyond employee costs. You know, at Nvidia that might never change, right? But inside a regular organization, a GraphDB and good knowledge management really lets you spend less money on tokens. You don't have to have agents spinning in circles or like suffering from this goldfish problem. Like it actually is probably one of the key foundational pieces to reining in costs of agentic systems, correct?

Yeah, I think that is one thing true because if you can manage context that you're giving to the agent, then you're sending less information to systems that are going to take all the token possible, all the context that you have and try to make decisions, come back and the more loops and reasoning you go to, that is interesting. The other thing that I'm also hearing a lot from customers we work with is this. truth layer they need in the agentic systems and agents where you know the right answer for some questions is predefined and you don't need to go think through too many things to go figure it out. And so then the context is pretty short. The answer is like, okay, this is what we know how to get to and do it. There are deterministic answers and there are non deterministic answers where you want to do a lot of reasoning, send more context and do more free flow problem solving. So I think figure out what is it that is governed already known answer. So you can reduce the token to whatever really least context you can provide to get the answer. Versus you can send a lot of context to go figure out. how to go ahead and get answers. ⁓ I think it's important to think through those things, Josh. So you're right.

I think otherwise the cost of overall agentic systems will be way more than what we underlying people-based costs for. I think currently the thesis is the cost benefits of these systems are going to be way past what we have today. So it will be interesting to manage that part. And the other thing, as Josh, you were mentioning,

you could create the same issue that we have had today of siloing systems and data, right? you could have a system where in like the whole organization starts with. agents everywhere, they have their own information that they run on and they come up with different workflows, decisions and answers because they don't interact with each other. And going back to your concept of organizational AGI, I think the main concept there needs to come together. It's the knowledge and the memory has to be organizational level. so that everybody references the same artifacts. Data can live wherever, but if till the time you have a graph that tells you what data is where and what you should always reference back to, then you will make the right decisions. Otherwise, the customer support agent versus the agent that is making decisions on what to recommend you next to buy or versus others, they will all independently make different decisions that may not be the right thing. So I actually think.

Yeah, this is maybe a great time, Josh. manage agent memory using Neo4j as like an underpin. we're working on a book with, the head of NASA's knowledge management system, So we put his book in here. Um, which is lean knowledge management. And Josh will walk you through like how we feature reduce.

I'm super excited about this one. I've not seen this thing and I think there's nothing more important for a product guy to see a demo that somebody else has built on top of the technology. So, I'm excited to learn more like

Yeah, go for it, Josh.

I'm sorry.

you guys have done. That's awesome.

All right, yeah, so this is our knowledge model of Lean Knowledge Management. The process of building it was really quite exhilarating. I think as a writer and editor, I actually really take to this stuff and enjoy working with these tools because I just fed it, the book chapter by chapter, and then it breaks it down into these tags, which are like the core ideas in the books. And then the nodes, here, our summaries of things that he talks about. So I mean, this, this, will be really useful to us as we work with Roger, because we're looking at his book and kind of applying his ideas to the agentic era, his book actually was instrumental in shaping our vision of knowledge management. So it all kind of makes sense. the other thing about his book is like, you know, he was, he was brought into NASA after the Columbia disaster, because that came on the heels of the Challenger disaster, which were both obviously terrible. NASA like really wanted to get knowledge management right because in both cases it was a failure of knowledge management. And so Roger's solution was really to strip it all down. And a lot of it is very human. It's about relationships between people, but then just see right here, it's about relationships between ideas and the context. so, yeah, you could, guess call it context management, right?

it really is context management. what we did is we took all the manual work that Roger did, like he used humans to manage all of this and we replaced it with AI. So now anyone could have NASA's knowledge management system, but not have to hire the team from NASA to run it.

it's

we have a similar knowledge model that we built for our own book. And it's actually attached to ⁓ an agent that you can access through the QR code in the book. But what we realized is you open that up and you're kind of just looking at another chat GPT style window. It's just sitting there waiting for you to start the conversation, which, we've been calling it use case zero, but this idea that, you know, these things if trained well and if the knowledge is sound, they're really, really effective teachers, right? So, so what if instead of just staring at you with a blank screen, its job was to get to know you to figure out in this case, like, what do you know about knowledge management? Why does knowledge management matter to your role? how would knowing more about knowledge management further your career? finding that information and then using this knowledge model, the idea would be that eventually, you know, a person would learn everything represented here. But by using this assessment first, you kind of figure out like what's going to hook them, what's going to mean the most of them. And then you're really just kind of creating a personalized path through all this information. It's almost like the, traveling salesman dilemma? Like finding the optimal path.

Yeah, you make it. Imagine you take this map. let's say your goal is to become an expert. That means you need to light up all these cards. Right. So the first step we do is we create a digital twin, a learning twin of this. We ask you some questions. We figure out what you know. We light up what you know. Then we light up what your objective is, and then we see what you don't know. And then traveling salesman, we create a GPS path of all the things you need to know by using the graph and creating relationships. And then we take you on a GPS journey, learning the things you need to know, lighting up each of the cards with an overall objective to light up all the cards. And what I love about this is it's not static. It's always learning. Like you said, this has a feedback loop. as new cards arrive and get added to your route. you're not doing a curriculum that's predetermined. You're on a GPS picking up new information as it's being added along the way. And the last thing is like each note that you see is a unique canonical idea. So if Roger updates an idea,

It doesn't add another node to the graph. It updates the current node on that idea because using LLM, we can see that ideas are similar or the same setting drift aside, which we've handled. also keep a canonical temporal record. use Neo4j's temporal service so that we can see the evolution of the idea over time. that if, if the idea is like, you know, where does Josh live? And it's like, he recently moved, you know, to Sheboygan from Denver. The agent is able to say, not just, where does Josh live? Sheboygan. It's able to say, well, last week he was in Denver, but he just moved to Sheboygan. So it not just has, like you said, the context, but it's got that temporal depth of how did that idea evolve over time? So that we can, so agents now have width and depth as you compress that, like you said, give it the right context, right? What does that compression look like? Well, depth matters too, the history of that event. So what we're looking at now is like what I think the new way you manage data, right? It's not a table, it's this blob.

What I love about this is I don't want Copilot to summarize a meeting for me. give me the transcript, right? And I will feed it to all my experts. And because this expert is bounded by expertise, right? It's only about knowledge management. doesn't talk about the meaning of life. as you feed that, will read through it and only pull into it which canonical ideas match. So if we didn't talk about knowledge management in our call, nothing will be added to the graph. If we talked about it, only that will be added to the graph. And now you have thousands of these graphs and experts in your company. Like if you're Patagonia, you have one on every single product. Right? now every conversation, all of these will mine it for keeping their knowledge up to date. So you have you don't have one system trying to keep all knowledge up to date. You have a bunch of independent agent systems that are each responsible to keep their knowledge up to date and no centralization, which only could be done with with graph.

I won't call it a blog. I think it is a set of blogs that are interconnected and you know what you do and where you go from here, I guess. They're all linked, right? Like the main point is.

Yeah, yes. yes.

you're not like just one big and this is the challenge I have with vectors and vector based systems. If everything is in vector space blob of information and you're doing similarity searches, you don't understand the interconnectedness of it. Because here you are taking concepts, they're interconnected and you're basically based on what you know, you can figure out what you want to, what you don't know and how they're interrelated. So that decision making requires the

connectivity tissue or relationship between these data points.

Yeah, I always think, I think of vector as bad relationships, like really dumb relationships, like obvious, know, synonyms and words that, but the problem is like ideas, ideas are carried in words, but words are not in themselves ideas. And so if you're trying to link ideas, you can't use semantics. It's like, it's just luck. You know, the example I like to give is, If I wrote down the story of the three little pigs, if I just pasted that in here right now, and then I went and I queried and I said, tell me a kid's story, it would not come up. And the reason is because the word kids is not in there, it's about pigs. The word story is not in there. Any VectorDB does not know that that's a kid's story. So it's useless. Yeah.

can I jump in? It also is terrible to learn more about pigs. Imagine telling more about pigs. And there are three little pigs.

Right, exactly. Tell me about pigs. they build houses

with straw and bricks. It's terrible. And I don't understand why people are obsessing over semantics. And there is no other solution. Like whether Neo4j or graphs is the perfect solution doesn't matter because there's nothing else. There's no other way to solve this, in my opinion. I haven't seen it. If there is, me.

Ha ha! Josh.

Yeah, so that knowledge model is connected to what we're currently calling the learning machine. I'm on a journey right now towards becoming a senior systems architect. So down here, I have my my lean knowledgement area of expertise that I want to get started in. ⁓ So it gives me kind of an outline of the book and of the practice and of the discipline. I read that and then I'm ready to go. And then it starts loading topics. There's actually quite a few of these, but I can go through and I just rank like where I think my knowledge level is on a lot of this stuff.

So this is the point A, like what do you know? We're not gonna, that way we don't start with stuff you already know and then you get bored and you drop out.

Yep.

you kind of rate your knowledge and then it uses that to start creating, your own personalized learning journey.

So you don't have like a, you don't have a ⁓ curriculum. It's building a curriculum just for you right now. based on the graph.

what's cool about this is like, I mean, obviously, you know, this particular knowledge model and instance on learning machine could help us build interest and excitement about knowledge management, right? you know, we were talking about organizational AGI, like this is sort of a pathway to and through that because as you start building out more and more experts, knowledge models within your organization, you know, if every employee has their own growth hub, that's like keeping them up to speed on everything they need to know about their organization and about, how their role is changing and how their role could grow and where there are opportunities within the organization, how they can serve other employees better and customers. Like there's so many different things that this thing could hone in on and teach.

Amazing. I think one of our customers who uses Neo4j for employee knowledge graph is Walmart actually. They have like more than two million employees. And one of the use cases for them is you have all these people everywhere and they want to have growth paths. You start somewhere in the organization. You want to know how do I become a manager here or? supply chain into a different part of logistics or any of these things. So they need to know career paths and opportunities and all that. This is a great way to give completely personalized paths from, want to be there, how do I get there? Then what paths do I do? How do I train? What do I know? So I think the whole-

Exactly Mm-hmm. Yes.

employee knowledge management and knowledge graphs can be completely transformed by this dynamic learning curves that you can put. Another one of our customers is Qualls and Brady. do software from the law. have a of laws. It's like one of the places where they have so much unstructured documents. And think doing similarity or semantic searches is never going to work. they do like unstructured data to graph and then they try to figure out like you guys are doing about how these are interrelated. If you have this kind of a problem, how do you do it? So I think these like, you know, custom paths that you can take dynamically based on concepts actually is really great way to get value out of. a lot of unstructured data. We see agentic systems lot around structured information. That's where it has been like most decisions were made on structured data in past because that was the only way we knew how to process stuff, right? But unstructured data, graphs play a critical role in representing them in a way that you can actually make sense out of it. And this is a great example of how you have converted

unstructured document into a graph which can now give you more dynamic decision-making power. It's amazing.

And if you think of it, we've like flipped learning upside down. There's no curriculum. Nobody pre-creates a curriculum. it's not cookie cutter. No two people get the same exact learning. Everyone gets the shortest path. Everyone gets the path to what they want to learn and as quickly as they can. And it's constantly dynamic as new information is changing right underneath. They're not missing out and falling behind because the curriculum was made six months ago. It's like textbooks, know, like the worst case example. And yeah, it's only enabled through graph. It's only, there's no other way.

Yeah. I don't think. ⁓ Also, I come from a large scale ⁓ big data systems in past. And I think I was on BigQuery. I ran product for BigQuery for a long time. It was great for storing massive amounts of data. But you can't do something like this in that kind of a system because storing large data for aggregations is different than an intelligent system that is trying to make real time decisions and flows and stuff like that.

This is another great point here, is the one example I was talking about Walmart and then they use it for employee knowledge graph. Imagine that kind of a system. Now you have all these employees, all these career paths and things. What you really want is whoever owns that particular job or that particular to own what expectations are for the job, what are the trainings and materials available for that job, and there can be thousands of this across the organization. How do you build organizational AGI? If you need a knowledge graph for organization, every individual...

Yes.

in the organization needs to be empowered to avoid knowledge in a structure that makes sense and what input they need. But once they have it, then you can do dynamic mapping of like, am here, these are my skills, this is where I want to be, how the path will work and all that. So all could be done like that.

huh. Yeah. Yeah, and it's crazy to think that we actually originally built a system to create contexts and teach agents. And it turned out to be just as good, if not better, at teaching people. It didn't matter who it was for. It didn't matter, AI or people, it's irrelevant. So we call this use case zero because if you're the head of AI of an organization,

Option A, you can go around trying to tell people what use cases they should use or what tools they should use. Or you could just implement a system that helps the organization learn about how to use AI, using AI. then you could, and then it's like Maximus builds Maximus, right? Like the robot that builds the robot wins, not the robot that can do a thousand use cases. So if you can have your AI teach AI,

to your employees and how to use AI or any tools, now adopting Neo4j isn't a steep climb because we're gonna take what you know, we're gonna draw a path, you'll be there in a day.

And I absolutely agree with you on this side. And also I think the barrier for learning is going down because a lot of these agentic systems are getting better at teaching you things like you're showing here where AI system built for dynamic learning. But even like in general, if you look at like, know, if you use Claude or you use Gemini, in general learning about like if it's Neo4j, learning about graphs or building with graphs is becoming more and more. easier because the systems are great at teaching you. ⁓ We don't do enough of learning from them. We try to tell them to do stuff. I think using these systems for learning is a great use of the technology.

I think it's use case zero, I think is the thing we're missing. We're so focused on doing. We're so focused on it doing, but knowing is where it's at. The doing becomes easy, right?

I think it's just crazy exciting to think like once you get the knowledge in place, the use cases just flow. you can't even stop coming up with use cases once you get that. And if you get an expert on one product, you just replicate that, put an expert on every other product. They all manage their own supply chain.

think a tool like the Growth Hub too, ⁓ as we were talking earlier about self-learning systems and self-optimizing systems, this could also become an interface where the system is learning from people. If I'm asking questions of the Growth Hub or if I'm sharing information that I picked up somewhere outside of the organization, that can then go back into the system.

Yeah, I think it's important to say that that system facilitates its own learning. You can start with a low fidelity. You can start with a model with two notes in it. And then someone asks a question, it can say, I don't know. And it can go ask a person and it can just create higher fidelity models on its own. You don't have to have a team that's trying to...

Yes.

hydrate the thing with knowledge, it can hydrate itself over time.

EA Sports is one of our customers and they built this semantic map of their environment and they pick customers of snowflake and they use the graph to understand where water is and answer questions. And they were using purely as a map, but then what they realized is not everybody asks the questions in the same way. people call the same, like for example, FIFA 26 game, maybe called by FIFA, Some people will just reference it FIFA. Some people will call it FIFA 26, like different names. And they were like, ⁓ people mean similar stuff and we need to understand these different kinds of things that are happening. And so now they've built a self-learning thing where common things that are asked and the system is unable to figure out, they add that back into the graph saying here is the common terms that are used for these things. But it's like you could do that for any kind of a system, right? You can say, okay, I don't know how to answer this question. Now I'm going to add additional information to get better at answering questions or decisions that I couldn't make the decision. Human needs to come in and make a decision and teach me how did you make the decision that I should capture, whether it was in like an email or a Slack or some other interface. Interfaces don't matter now. The decision making and the traces for how the decisions were made. whether it comes from agents or humans, and if you can put it back into the graph, then you can use that for self-improvement. So that's really perfect.

Yeah. Yeah, so this is my last point I'll make. This is just a really valuable pattern that I found. We're voice first platform, which means like, if you can do voice, you can do anything and low latency is absolutely essential. Everything breaks down once you add voice. If you haven't thought about it voice first, it's like mobile first, but worse. It's really hard to get voice. The way we use graph there is what you said.

What do you put in the graph and what do you leave on the underlying foundation like in its original place? We use graph almost like a caching engine so that we can lower latency. So we move data from the bottom and we put it into the graph dynamically based on requests. And so we sort of use the graph database as a cache system to improve latency on voice systems. So anyway, a little trick out there for people trying to implement voice.

because yeah. And I think this is where earlier I was talking about virtual graphs versus native graphs. And this is what I mean by it as like if you want real time low latency use case, you use the graph database as the store system of store system of knowledge to store it.

versus if you are okay with long running jobs and because some agents will be long running and then you don't have to move data. So I think you're absolutely right. It's a great example of if you want super fast low latency responses then you should absolutely store it in the native graph storage. You can store it with virtualization and all.

Yeah. Yep. And you don't have to place it there. You can just use it as a cache. You can just cache it as it requests. Awesome, guys. This was, as I thought, amazing conversation. We'll have to have more of them.

Yeah exactly. You don't have to... Great!

Definitely. Yeah. Thanks, Sidhir.

Love it. Thank you.