This episode examines Imago's platform and the role of knowledge graphs in artificial intelligence driven operational intelligence. Magnus Helander of Imago, co-founder and product lead, joins theCUBE Research to discuss Imago's application of knowledge graphs and hybrid architectures that combine graph databases and vector databases to address portable document format workflows and to enable context engineering, platform memory and agentic processes. Helander explains how they design the hybrid architecture to reduce hallucinations and to deliver near 100% accuracy in warranty resolution workflows while Neo4j provides traceability for agent decisions. Hosts John Furrier and theCUBE guide the conversation on Neo4j's role and practical deployment patterns for enterprises.
Helander recommends starting with concrete use cases, attaching metadata for attribute-based access control, hereafter ABAC, and treating the knowledge layer as a dynamic hybrid layer above existing data platforms. They emphasize metadata models, governance and traceability as factors to consider when deploying graph and vector integrations for enterprise operational intelligence. theCUBE hosts emphasize graphs' role in auditability, context engineering and scalable agentic applications.
Forgot Password
Almost there!
We just sent you a verification email. Please verify your account to gain access to
theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. If you don’t think you received an email check your
spam folder.
Sign in to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open the link to automatically sign into the site.
Register for theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems
Please fill out the information below. You will receive an email with a verification link confirming your registration. Click the link to automatically sign into the site.
You’re almost there!
We just sent you a verification email. Please click the verification button in the email. Once your email address is verified, you will have full access to all event content for theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
Thanks for confirming your account. Now you can access theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems with this email address.
I want my badge and interests to be visible to all attendees.
Checking this box will display your presense on the attendees list, view your profile and allow other attendees to contact you via 1-1 chat. Read the Privacy Policy. At any time, you can choose to disable this preference.
Select your Interests!
add
Upload your photo
Uploading..
OR
Connect via Twitter
Connect via Linkedin
EDIT PASSWORD
Share
Forgot Password
Almost there!
We just sent you a verification email. Please verify your account to gain access to
theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. If you don’t think you received an email check your
spam folder.
Sign in to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open the link to automatically sign into the site.
Sign in to gain access to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems
Please sign in with LinkedIn to continue to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. Signing in with LinkedIn ensures a professional environment.
Are you sure you want to remove access rights for this user?
Details
Manage Access
email address
Community Invitation
Magnus Helander, The Imago Platform | AI Luminaries with Neo4j
This episode examines Imago's platform and the role of knowledge graphs in artificial intelligence driven operational intelligence. Magnus Helander of Imago, co-founder and product lead, joins theCUBE Research to discuss Imago's application of knowledge graphs and hybrid architectures that combine graph databases and vector databases to address portable document format workflows and to enable context engineering, platform memory and agentic processes. Helander explains how they design the hybrid architecture to reduce hallucinations and to deliver near 100% accuracy in warranty resolution workflows while Neo4j provides traceability for agent decisions. Hosts John Furrier and theCUBE guide the conversation on Neo4j's role and practical deployment patterns for enterprises.
Helander recommends starting with concrete use cases, attaching metadata for attribute-based access control, hereafter ABAC, and treating the knowledge layer as a dynamic hybrid layer above existing data platforms. They emphasize metadata models, governance and traceability as factors to consider when deploying graph and vector integrations for enterprise operational intelligence. theCUBE hosts emphasize graphs' role in auditability, context engineering and scalable agentic applications.
Magnus Helander, The Imago Platform | AI Luminaries with Neo4j
Magnus Helander
Co-FounderThe Imago Platform
search
(INTRO)
John Furrier
>> Hello, I'm John Furrier, host of theCUBE here in our Palo Alto studio. Of course, we have our New York City at the NYSE theCUBE Studio. We connect Silicon Valley and Wall Street, all the best tech content as the world evolves into AI. This is the Neo4j AI Luminary Series. We talk to leaders who are making data work, using graphs, using data in a new way that's compatible with the AI infrastructure, the AI tokens, all the things that are going on that's driving a lot of value. Magnus Helander is here, co -founder and product leader at Imago, imago.io is the URL. Thanks for coming on, appreciate it. All the way from Sweden, we're in Palo Alto, California. Good afternoon, good morning here. Thanks for coming on.>> Good morning, thank you very much for having me. Really looking forward to this conversation.
John Furrier
>> Yeah, well. >> Congratulations on being a luminary.
John Furrier
>> And being a luminary, sometimes you take arrows in the back, you've got a lot of grinding, you eat glass, spit out nails, as we say. And graph databases, and Neo4j is really highlighting, what we see in the marketplace. We're seeing, things like all over the mainstream news, you see, Palantir, ontology, everyone thinks ontology is a new thing. Oh, it's not a new thing, but you're starting to see that knowledge graphs, knowledge systems, knowledge layers are connecting this new AI infrastructure slash data layer, but it doesn't change the data game. You still got databases, you still got data lakes. the models have separated, you have this new contextual layer. The people who are architecting this way are seeing significant advances and significant movement in value. Magnus, share what you're working on and how that ties in and how you guys got here and some of the things you're working on. Set the table, set the context.>> Well, the platform, we tried to find a good word for it and I think operational intelligence was the core idea that all the information was spread out into 10, 15 different systems. And a lot of time was spent just trying to get hold of the information. And usually everything ended up in an Excel sheet. And we thought, this is not good. So that was sort of the starting point for the Imago platform. Can we bring all these data sources that are spread out into all these different places into this one thing and then actually do something useful? So that was the starting idea, I think, for the Imago platform. And then we got our first client and they were in the lighting and electrical business. And it turns out that we had to resolve warranty claims for products. And it turns out that that is extremely difficult because every manufacturer have their own policies and there might be additional policies in terms and conditions. And then there's timings and there's just like, It was an N combination problem, and all the data was in PDF documents. So that's when the journey started, and we thought, okay, so how can we work with this to make these PDF documents that contain everything come alive? And that journey started about a year ago. and it was a really interesting learning experience.
John Furrier
>> Painful probably. Yes, it was. Share what happened because we were talking before we came on camera. That one of the things you observed was that it really fit into the AI and almost made it behave, are the words you used. Talk about what happened because that's a scenario that we see in general. It's a great example. You see the models, the frontier models, they can suck in PDFs. So it makes sense that they would be loving that. You're struggling with it. Take us through what happened next.>> Oh, we just couldn't get the thing to 100 % accuracy. And there is no way you can do any kind of system that sort of doesn't deliver 100 % accuracy. These systems, the models, they are non -deterministic by design. That's how they are built. That's how they work. They give you a probability. Which fixture is this? There's 10 of them, and most likely this one. And we're like, no, that's not going to work. Most likely is not good enough for this. And we tried so many ways to extract information, to encode it, put it in our vector databases, slice it and dice the data every which way. and we just couldn't get the thing to answer properly because there were so many factors like in the lighting and electrical, you have wattage, you have lumens, you have all these technical specifications and everything and the models just couldn't deal with it. And sometimes we would get good results with one, two or three projects and we said, okay, good, we got it. And then we scaled up and everything fell apart again. And at some point we just realized that vector databases, it's not going to take us there. And then we started looking for something else. And then we came across graph databases. And we got on the Neo4j Startup Program and got some help to start working with graphs. and suddenly everything just fell into place. Suddenly the model started delivering correct results again and again and again. So it was, that was just, it was like, okay, finally.
John Furrier
>> We figured out how this works. the headache's gone. It's an aspirin and a steroid because there's opportunities to grow. Take us through the context piece because your example highlights kind of a more global problem that people are struggling with and they're solving, which is I have context. You know what it is. It's specific. It's just hard to surface. There's so many different challenges with that.>> How did it all come together? There's really two things. There's a knowledge layer, which is all the data available to the agent. And the knowledge layer, we have everything there. There's graph databases and vector DBs and any kind of data store and lakes and everything. But then you need to pull some of it into the agent. And it only has a limited context window. And then suddenly you get into context engineering. And things get really, really tricky. Because suddenly you also need access control. In a corporate environment, you just can't share everything open. It's not possible to do that. So first you have everything in a knowledge layer available to the agent, and then you need to select some data to get that into the context window. And then you have to also apply access controls to that data. And things get complex very quickly, we noticed. And additionally, one thing is, of course, that you want the systems to be smarter the whole time. So we also added platform memory, so we can track and follow what the agents are doing and to get faster and better results to provide context from previous work. And then suddenly we have the data product and also with additional access control needs. So things get very complex quickly once you start moving into context engineering.
John Furrier
>> I like that word, context engineering. Again, the data shows that people who just throw MCP servers at things will fail because they didn't really think about the semantic foundation and the knowledge layer fills that gap as we just talked about. But as people think about this, there's a lot of builders out there going through the motions and they're really enthusiastic about AI. So they got their data lakes, they want to work with models. Now there's more deterministic workflows with agents, with proprietary data in say this knowledge layer or inside the enterprise. How do you think about this knowledge layer from an architecture standpoint? Is it, do you see it positioned above the data platform? Because most people say, and we're like, I got a data lake, I'm good. Or let's just put a sidecar database and then work on the data lake. Is it above, is it beside? How would you describe for folks out there building to think about the architecture of the knowledge layer with their existing data efforts? Because everyone's got experience pipelining data, working with data lakes, dealing with multiple data sources. That's not a new problem. They're fixing that, but now you have AI in there. How does that knowledge layer sit in the architecture in your view? What worked for you?>> What worked for us is hybrid everything. I think it's very difficult to draw a line between these two things. But I think definitely that the memory layer and the actual instructions end up on top of the data layer, for sure. you would have a number of workflows pushing data into your knowledge layer from the data layer, which has to be fresh. It has to be updated. It's constantly changing. And something has to keep that layer fresh the whole time. And once you have that, you need some way to pull data from it depending on the task. And then you get the agent and you give it some kind of instruction, some job to do. and then it needs to figure out, okay, where are my data sources? And that's when the AI agent then starts the tool use and you build the tools to hold the data in a useful, structured manner with the access controls in place and, of course, also using platform memory. I don't see them as totally isolated. I think they very much connect into each other.
John Furrier
>> People who have Databricks, Snowflake, they don't want to move the data and migrate data. They want to actually just send it to or connect to the context reasoning in the graph. It's like, all right, you don't have to boil the ocean or do menial tasks to make it work.>> Now, I read somewhere the business logic moves into the AI layer. I think that's the best way I can put it, that that's where the actual business logic lives. It gives all the domain knowledge, all the skills, skill sets, how to perform something. And the whole business logic layer, I think, is the word that I would use for the actual processing. And there is a number of tools you can hand out to the agent. You can give it access to databases, file storage, live data, APIs. And then you just need to figure out, okay, how do I solve this task? And then once you have that, you run into another problem. You solve one thing, you get something else. And suddenly you have agents working in the background because they are deep down into Kubernetes network or grinding away somewhere where you don't really have the observability. so once it's done all this it presents a result and says okay this is you know approved or not approved or it's five or it's this model or this is the recommendation and you really have no idea how it arrived at that conclusion because it is just very difficult to see where this happens and again Neo4j has saved us there because it does this, it can trace the agent's work, everything. It creates nodes for every step of this. Like you have an agent and a prompt coming in, then you have a planning, and then it's going to use the tools, and then it has a result, and it makes a decision, and then it forwards it to a human, and the human approves it. It's like all these steps are invisible initially unless you push it into Neo4j and build a graph of the agent's work. So I think that's the only way to get an audit trail and see what actually happened and be able to go back and say. How did we arrive at this decision?
John Furrier
>> It's interesting when I was in college, we learned about compiler design, operating systems. if you look at the computer science and this AI wave the graphs are just nodes and arcs, right? And traversal, right? It's very compatible with the neural network paradigm that really has been around since the 80s, but now with super computing capability, you can actually move super fast. So talk about the value that you're seeing on the results and talk about that compatibility from a computer science standpoint. Like you said, the models behave differently because they're kind of compatible with graphs. They like graphs. They play well on graphs. And they need data, so you got to feed data from other database. Talk about that compatibility alignment. And then what are some of the results you guys have seen?>> Oh, I think something we realized is that these agents are, or actually the models are designed to be helpful. And if it doesn't have data, it will generate it for you because that's the definition of helpful. And then you get hallucinations. And the more context and data you provide to the LLM, the large language model, the less hallucinations you get. And as you say, something happens when you provide context to the model. This thing is connected to this thing, which is related to this thing in this way. and suddenly it just seems like a perfect match i think graph dbs are ai native they are definitely built for the models i'm not an ai engineer and i try to understand why and it's again it's complex but it actually works what we have seen is that we are getting 100 % accuracy now with our warranty resolution system. And it's almost magic, because we have both a vector database and a graph database, because some of the stuff is not. Sometimes you're kind of looking for a number of results and maybe you want 10 of them, but sometimes you're just looking for this model with this specification, and then you need a graph database. But I think the combination of a vector DB and a graph DB is what makes this possible.
John Furrier
>> There's a lot of conversations on that. That's a good point you called out because vector databases are great at retrieval. And that's a discovery mechanism. Graphs are things you can traverse down with context. That's where reasoning shines. So search isn't reasoning. Search is get an answer. In this case, you get hallucinations if you use the models. Sometimes it's just an answer to a query or a list in order of the results. Search is not reasoning. Reasoning is multi-step. So they kind of work together. So you want to have a discovery layer and a reasoning layer, right? That's kind of where this fits. That creates tons of new opportunities. You get dynamic personalization. If you have context and you have relationship maps on a specific thing, it's like going down, opening a door and going down a contextual graph, you can personalize things, autonomous systems work better. It's kind of an infrastructure piece.>> It really is. And we were able to, we have another product also, a product finder where you give it your needs, like for a car. I have three kids and I commute, what can you recommend? And we were able to find the perfect car for you instead of going through the classic check boxes and trying to figure out which car is a good one from 300 alternatives, we were able to build a needs-based product engine. And again, that also would not have been possible without both a graph DB and also a number of advanced search technologies. So for us, it has been absolutely critical and we would not be able to do what we do today if we didn't have a GraphDB on there. And Neo4j has been extremely useful and helpful for us. So for us, this has really been the game changer. I wonder what it was like for Neo4j because first they built this obscure technology a number of years ago. And who needs a GraphDB? Everyone's running SQL. And suddenly they end up in the absolute spotlight of the AI revolution.
John Furrier
>> Yeah, it's like they were way ahead of the curve. But when you look at it, as neural networks become more popular, even the word ontology is essentially a knowledge graph if you think about it. But these are platforms. These aren't like a database. Make a query. I was talking to an entrepreneur who's doing some AI in another area, he's like, hey, you mentioned business logic, he said, I used to do a lot of SQL queries and I used to have to think about the business logic, then execute the query. Now I just say what I want and it just does the logic for me. This is kind of what you're getting at. The context and the logic is the relationships. And this is where the agents really shine because you just ask for the outcome and the reasoning gets done in advance. It's a whole paradigm shift relative to the business model use cases that are out there. You could apply that to anything, customer experience, warranty, risk fraud, agentic workflows, cybersecurity. Those are horizontal use cases, but the first principles are, here's the data, what do you want? And let the agent do the reasoning and leverage the mathematics and the AI systems to do it.>> Oh, yes. And when you see this happening in front of your eyes, you go, wow, this is really, like you can see it's trying to traverse it. Let's see, no, I didn't find it. Let's go back. Let me try something else. Oh, I have an entry point here. Let me walk this graph. Okay, now I found it. As you say, it's native, it's AI native. It's the perfect way of just storing information for an AI agent because it can really work with it. You can't really do that in SQL. There's no way you'd be able to do that kind of structure or walking or finding information that way. And I think this is one of these AI native technologies we need to get comfortable with. You have the vector DBs, the graph DBs. We're looking at MongoDB for page storage. And then, of course, everything about semantic storing of especially memories and the whole memory infrastructure, which I don't think anyone has really solved yet because it's so complex. You need them to decay and then you have to remove old memories when something new shows up. And it turns into an enormously complex uh thing. But i think that's the next thing to solve uh to have live contextual memory that is always fresh and updating that all the agents are continually.
John Furrier
>> Usingwith access control. Well, the great news is the neoclouds, NVIDIA, the semiconductor companies, they're building up the stack. You're starting to see the abstraction. there's a lot of people doing a lot of work on data, as you know, you're one of them. There's many AI native applications that are going to come out, whether it's a headless system or a different user interface, we're seeing that too. But a lot of people in the data area are like, Well, I already work with a major cloud provider. They got all these frameworks, they got a data platform. how does this fit in? Do I have to disrupt anything? I won't say it's an objection, it's more of an awareness. How would you talk to your colleagues and peers out there who are dealing with a lot of data work, data engineering, preparation, we're seeing compliance and governance as a big part of that, that feeds into it. How do they then talk about the risk or not risk around dealing with knowledge layer that sits above these investments?Oh. >> Start with the user and try to understand how will this data be used. Absolutely. Instead of saying, oh, it works, but it's free for all. And you have to start with thinking about, OK, make sure that every little fragment of data has metadata to it, who does it belong to, where does it come from, provenance, which record did you pull this from, which documents, and who, and just to make sure that you start with making sure that everything has the metadata to it to enable ABAC later on because RBAC isn't working in an AI world, and attribute-based access control is critical to make this work. So I would say, for sure, start with the use cases and try to understand, okay, when we're done, how is this going to work and who's going to use the information? And then build from there and make sure that you have all the metadata attached to every little fragment of data in your data layer. And then you can lift it up into the agents and they can decide if, or you can restrict data from your agent so they don't touch them. I've seen a lot of people are trying to solve this problem with the access control thing. Tailscale is doing some fantastic work also with their gateway. So you can do things there and there's Permit.io that we use for ABAC. and I'm sure there's a number of systems, but I think that that access control system also has to be solved. I think everyone was kind of surprised when MCPs came along. And it was one API key. And it was wide open bypassing every security system. Yeah, yeah, exactly.
John Furrier
>> And it was like, wait, wait a minute. What's going on here? Yeah, we made the models behave, now the agents are going rogue. So now you got to rein that in. So, okay, models are behaving, thank you, Cypher-compatible. We just talked about that, but now the rogue agents, they're just trying to do the best they can, but if they don't have any guidance on the relationship maps or any context, they're going to just do their thing.>> Exactly, they have no idea who owns this data, who's allowed to see it, under which circumstances and everything.
John Furrier
>> It's like that video game, Pac -Man, where you just chomp through and just, okay, took the wrong turn, chomps up all the data. It's bad. that's kind of where the intelligence comes in. I think if you can harness the intelligence, get the data layer, almost, I call it the brain of a company. And a lot of people are thinking that way now, Magnus. Like, hey, if I can build the brain of my company, you have essentially, it's a graph where you can connect the different pieces of data, which is parts of the brain, that kind of a metaphor. You're seeing a lot of biology examples. The bloodstream is the data, the brain is the graph, and the data and thinking through that is key. So, this is what we're seeing a lot of these metaphors. What's your take on that? You agree?>> Oh, yes. The stuff that we see now, what our client is able to do now in terms of work orders and warranty repairs and getting quotes out and everything. Once you get all the data up there, the speed increase is really shocking stuff that usually takes an hour or two before we're able to solve in 60 to 90 seconds now. And that frees up time to do meaningful work instead of just sitting there and chasing documents in the SharePoint folder, which I think -. Grinding away.
John Furrier
>> Like I said, eating glass and spitting out nails. But again, there's light at the end of the tunnel. You're now a luminary. We should put this video also in our Mixture of Experts series because this was a great expert conversation. You're on the frontier and again, the value's there, great use cases. Magnus, thank you for coming on the Luminary series with Neo4j AI on theCUBE. Appreciate it. Thank you very much. It's been absolutely great. Thank you so much for having me. You're welcome. It's been great. Yeah, there's a lot of opportunities out there. I'm John Furrier with theCUBE. If you're looking at AI and you're looking at tapping into the models or having specialty intelligence with domain models, graphs are a beautiful thing, but you don't have to replace other things to bring in graphs. They add to the equation, they sit on top of data. A lot of advances we're seeing come out and a lot of the winners in the agentic world are looking at graphs and are expanding more and more and keeping that context on point and in line and keeping those agents and those models kind of behaving well. More content coming on theCUBE. We're doing our part to bring you the data. Thanks for watching. Thank you.
Magnus Helander, The Imago Platform | AI Luminaries with Neo4j
search
(INTRO)
John Furrier
>> Hello, I'm John Furrier, host of theCUBE here in our Palo Alto studio. Of course, we have our New York City at the NYSE theCUBE Studio. We connect Silicon Valley and Wall Street, all the best tech content as the world evolves into AI. This is the Neo4j AI Luminary Series. We talk to leaders who are making data work, using graphs, using data in a new way that's compatible with the AI infrastructure, the AI tokens, all the things that are going on that's driving a lot of value. Magnus Helander is here, co -founder and product leader at Imago, imago.io is the URL. Thanks for coming on, appreciate it. All the way from Sweden, we're in Palo Alto, California. Good afternoon, good morning here. Thanks for coming on.>> Good morning, thank you very much for having me. Really looking forward to this conversation.
John Furrier
>> Yeah, well. >> Congratulations on being a luminary.
John Furrier
>> And being a luminary, sometimes you take arrows in the back, you've got a lot of grinding, you eat glass, spit out nails, as we say. And graph databases, and Neo4j is really highlighting, what we see in the marketplace. We're seeing, things like all over the mainstream news, you see, Palantir, ontology, everyone thinks ontology is a new thing. Oh, it's not a new thing, but you're starting to see that knowledge graphs, knowledge systems, knowledge layers are connecting this new AI infrastructure slash data layer, but it doesn't change the data game. You still got databases, you still got data lakes. the models have separated, you have this new contextual layer. The people who are architecting this way are seeing significant advances and significant movement in value. Magnus, share what you're working on and how that ties in and how you guys got here and some of the things you're working on. Set the table, set the context.>> Well, the platform, we tried to find a good word for it and I think operational intelligence was the core idea that all the information was spread out into 10, 15 different systems. And a lot of time was spent just trying to get hold of the information. And usually everything ended up in an Excel sheet. And we thought, this is not good. So that was sort of the starting point for the Imago platform. Can we bring all these data sources that are spread out into all these different places into this one thing and then actually do something useful? So that was the starting idea, I think, for the Imago platform. And then we got our first client and they were in the lighting and electrical business. And it turns out that we had to resolve warranty claims for products. And it turns out that that is extremely difficult because every manufacturer have their own policies and there might be additional policies in terms and conditions. And then there's timings and there's just like, It was an N combination problem, and all the data was in PDF documents. So that's when the journey started, and we thought, okay, so how can we work with this to make these PDF documents that contain everything come alive? And that journey started about a year ago. and it was a really interesting learning experience.
John Furrier
>> Painful probably. Yes, it was. Share what happened because we were talking before we came on camera. That one of the things you observed was that it really fit into the AI and almost made it behave, are the words you used. Talk about what happened because that's a scenario that we see in general. It's a great example. You see the models, the frontier models, they can suck in PDFs. So it makes sense that they would be loving that. You're struggling with it. Take us through what happened next.>> Oh, we just couldn't get the thing to 100 % accuracy. And there is no way you can do any kind of system that sort of doesn't deliver 100 % accuracy. These systems, the models, they are non -deterministic by design. That's how they are built. That's how they work. They give you a probability. Which fixture is this? There's 10 of them, and most likely this one. And we're like, no, that's not going to work. Most likely is not good enough for this. And we tried so many ways to extract information, to encode it, put it in our vector databases, slice it and dice the data every which way. and we just couldn't get the thing to answer properly because there were so many factors like in the lighting and electrical, you have wattage, you have lumens, you have all these technical specifications and everything and the models just couldn't deal with it. And sometimes we would get good results with one, two or three projects and we said, okay, good, we got it. And then we scaled up and everything fell apart again. And at some point we just realized that vector databases, it's not going to take us there. And then we started looking for something else. And then we came across graph databases. And we got on the Neo4j Startup Program and got some help to start working with graphs. and suddenly everything just fell into place. Suddenly the model started delivering correct results again and again and again. So it was, that was just, it was like, okay, finally.
John Furrier
>> We figured out how this works. the headache's gone. It's an aspirin and a steroid because there's opportunities to grow. Take us through the context piece because your example highlights kind of a more global problem that people are struggling with and they're solving, which is I have context. You know what it is. It's specific. It's just hard to surface. There's so many different challenges with that.>> How did it all come together? There's really two things. There's a knowledge layer, which is all the data available to the agent. And the knowledge layer, we have everything there. There's graph databases and vector DBs and any kind of data store and lakes and everything. But then you need to pull some of it into the agent. And it only has a limited context window. And then suddenly you get into context engineering. And things get really, really tricky. Because suddenly you also need access control. In a corporate environment, you just can't share everything open. It's not possible to do that. So first you have everything in a knowledge layer available to the agent, and then you need to select some data to get that into the context window. And then you have to also apply access controls to that data. And things get complex very quickly, we noticed. And additionally, one thing is, of course, that you want the systems to be smarter the whole time. So we also added platform memory, so we can track and follow what the agents are doing and to get faster and better results to provide context from previous work. And then suddenly we have the data product and also with additional access control needs. So things get very complex quickly once you start moving into context engineering.
John Furrier
>> I like that word, context engineering. Again, the data shows that people who just throw MCP servers at things will fail because they didn't really think about the semantic foundation and the knowledge layer fills that gap as we just talked about. But as people think about this, there's a lot of builders out there going through the motions and they're really enthusiastic about AI. So they got their data lakes, they want to work with models. Now there's more deterministic workflows with agents, with proprietary data in say this knowledge layer or inside the enterprise. How do you think about this knowledge layer from an architecture standpoint? Is it, do you see it positioned above the data platform? Because most people say, and we're like, I got a data lake, I'm good. Or let's just put a sidecar database and then work on the data lake. Is it above, is it beside? How would you describe for folks out there building to think about the architecture of the knowledge layer with their existing data efforts? Because everyone's got experience pipelining data, working with data lakes, dealing with multiple data sources. That's not a new problem. They're fixing that, but now you have AI in there. How does that knowledge layer sit in the architecture in your view? What worked for you?>> What worked for us is hybrid everything. I think it's very difficult to draw a line between these two things. But I think definitely that the memory layer and the actual instructions end up on top of the data layer, for sure. you would have a number of workflows pushing data into your knowledge layer from the data layer, which has to be fresh. It has to be updated. It's constantly changing. And something has to keep that layer fresh the whole time. And once you have that, you need some way to pull data from it depending on the task. And then you get the agent and you give it some kind of instruction, some job to do. and then it needs to figure out, okay, where are my data sources? And that's when the AI agent then starts the tool use and you build the tools to hold the data in a useful, structured manner with the access controls in place and, of course, also using platform memory. I don't see them as totally isolated. I think they very much connect into each other.
John Furrier
>> People who have Databricks, Snowflake, they don't want to move the data and migrate data. They want to actually just send it to or connect to the context reasoning in the graph. It's like, all right, you don't have to boil the ocean or do menial tasks to make it work.>> Now, I read somewhere the business logic moves into the AI layer. I think that's the best way I can put it, that that's where the actual business logic lives. It gives all the domain knowledge, all the skills, skill sets, how to perform something. And the whole business logic layer, I think, is the word that I would use for the actual processing. And there is a number of tools you can hand out to the agent. You can give it access to databases, file storage, live data, APIs. And then you just need to figure out, okay, how do I solve this task? And then once you have that, you run into another problem. You solve one thing, you get something else. And suddenly you have agents working in the background because they are deep down into Kubernetes network or grinding away somewhere where you don't really have the observability. so once it's done all this it presents a result and says okay this is you know approved or not approved or it's five or it's this model or this is the recommendation and you really have no idea how it arrived at that conclusion because it is just very difficult to see where this happens and again Neo4j has saved us there because it does this, it can trace the agent's work, everything. It creates nodes for every step of this. Like you have an agent and a prompt coming in, then you have a planning, and then it's going to use the tools, and then it has a result, and it makes a decision, and then it forwards it to a human, and the human approves it. It's like all these steps are invisible initially unless you push it into Neo4j and build a graph of the agent's work. So I think that's the only way to get an audit trail and see what actually happened and be able to go back and say. How did we arrive at this decision?
John Furrier
>> It's interesting when I was in college, we learned about compiler design, operating systems. if you look at the computer science and this AI wave the graphs are just nodes and arcs, right? And traversal, right? It's very compatible with the neural network paradigm that really has been around since the 80s, but now with super computing capability, you can actually move super fast. So talk about the value that you're seeing on the results and talk about that compatibility from a computer science standpoint. Like you said, the models behave differently because they're kind of compatible with graphs. They like graphs. They play well on graphs. And they need data, so you got to feed data from other database. Talk about that compatibility alignment. And then what are some of the results you guys have seen?>> Oh, I think something we realized is that these agents are, or actually the models are designed to be helpful. And if it doesn't have data, it will generate it for you because that's the definition of helpful. And then you get hallucinations. And the more context and data you provide to the LLM, the large language model, the less hallucinations you get. And as you say, something happens when you provide context to the model. This thing is connected to this thing, which is related to this thing in this way. and suddenly it just seems like a perfect match i think graph dbs are ai native they are definitely built for the models i'm not an ai engineer and i try to understand why and it's again it's complex but it actually works what we have seen is that we are getting 100 % accuracy now with our warranty resolution system. And it's almost magic, because we have both a vector database and a graph database, because some of the stuff is not. Sometimes you're kind of looking for a number of results and maybe you want 10 of them, but sometimes you're just looking for this model with this specification, and then you need a graph database. But I think the combination of a vector DB and a graph DB is what makes this possible.
John Furrier
>> There's a lot of conversations on that. That's a good point you called out because vector databases are great at retrieval. And that's a discovery mechanism. Graphs are things you can traverse down with context. That's where reasoning shines. So search isn't reasoning. Search is get an answer. In this case, you get hallucinations if you use the models. Sometimes it's just an answer to a query or a list in order of the results. Search is not reasoning. Reasoning is multi-step. So they kind of work together. So you want to have a discovery layer and a reasoning layer, right? That's kind of where this fits. That creates tons of new opportunities. You get dynamic personalization. If you have context and you have relationship maps on a specific thing, it's like going down, opening a door and going down a contextual graph, you can personalize things, autonomous systems work better. It's kind of an infrastructure piece.>> It really is. And we were able to, we have another product also, a product finder where you give it your needs, like for a car. I have three kids and I commute, what can you recommend? And we were able to find the perfect car for you instead of going through the classic check boxes and trying to figure out which car is a good one from 300 alternatives, we were able to build a needs-based product engine. And again, that also would not have been possible without both a graph DB and also a number of advanced search technologies. So for us, it has been absolutely critical and we would not be able to do what we do today if we didn't have a GraphDB on there. And Neo4j has been extremely useful and helpful for us. So for us, this has really been the game changer. I wonder what it was like for Neo4j because first they built this obscure technology a number of years ago. And who needs a GraphDB? Everyone's running SQL. And suddenly they end up in the absolute spotlight of the AI revolution.
John Furrier
>> Yeah, it's like they were way ahead of the curve. But when you look at it, as neural networks become more popular, even the word ontology is essentially a knowledge graph if you think about it. But these are platforms. These aren't like a database. Make a query. I was talking to an entrepreneur who's doing some AI in another area, he's like, hey, you mentioned business logic, he said, I used to do a lot of SQL queries and I used to have to think about the business logic, then execute the query. Now I just say what I want and it just does the logic for me. This is kind of what you're getting at. The context and the logic is the relationships. And this is where the agents really shine because you just ask for the outcome and the reasoning gets done in advance. It's a whole paradigm shift relative to the business model use cases that are out there. You could apply that to anything, customer experience, warranty, risk fraud, agentic workflows, cybersecurity. Those are horizontal use cases, but the first principles are, here's the data, what do you want? And let the agent do the reasoning and leverage the mathematics and the AI systems to do it.>> Oh, yes. And when you see this happening in front of your eyes, you go, wow, this is really, like you can see it's trying to traverse it. Let's see, no, I didn't find it. Let's go back. Let me try something else. Oh, I have an entry point here. Let me walk this graph. Okay, now I found it. As you say, it's native, it's AI native. It's the perfect way of just storing information for an AI agent because it can really work with it. You can't really do that in SQL. There's no way you'd be able to do that kind of structure or walking or finding information that way. And I think this is one of these AI native technologies we need to get comfortable with. You have the vector DBs, the graph DBs. We're looking at MongoDB for page storage. And then, of course, everything about semantic storing of especially memories and the whole memory infrastructure, which I don't think anyone has really solved yet because it's so complex. You need them to decay and then you have to remove old memories when something new shows up. And it turns into an enormously complex uh thing. But i think that's the next thing to solve uh to have live contextual memory that is always fresh and updating that all the agents are continually.
John Furrier
>> Usingwith access control. Well, the great news is the neoclouds, NVIDIA, the semiconductor companies, they're building up the stack. You're starting to see the abstraction. there's a lot of people doing a lot of work on data, as you know, you're one of them. There's many AI native applications that are going to come out, whether it's a headless system or a different user interface, we're seeing that too. But a lot of people in the data area are like, Well, I already work with a major cloud provider. They got all these frameworks, they got a data platform. how does this fit in? Do I have to disrupt anything? I won't say it's an objection, it's more of an awareness. How would you talk to your colleagues and peers out there who are dealing with a lot of data work, data engineering, preparation, we're seeing compliance and governance as a big part of that, that feeds into it. How do they then talk about the risk or not risk around dealing with knowledge layer that sits above these investments?Oh. >> Start with the user and try to understand how will this data be used. Absolutely. Instead of saying, oh, it works, but it's free for all. And you have to start with thinking about, OK, make sure that every little fragment of data has metadata to it, who does it belong to, where does it come from, provenance, which record did you pull this from, which documents, and who, and just to make sure that you start with making sure that everything has the metadata to it to enable ABAC later on because RBAC isn't working in an AI world, and attribute-based access control is critical to make this work. So I would say, for sure, start with the use cases and try to understand, okay, when we're done, how is this going to work and who's going to use the information? And then build from there and make sure that you have all the metadata attached to every little fragment of data in your data layer. And then you can lift it up into the agents and they can decide if, or you can restrict data from your agent so they don't touch them. I've seen a lot of people are trying to solve this problem with the access control thing. Tailscale is doing some fantastic work also with their gateway. So you can do things there and there's Permit.io that we use for ABAC. and I'm sure there's a number of systems, but I think that that access control system also has to be solved. I think everyone was kind of surprised when MCPs came along. And it was one API key. And it was wide open bypassing every security system. Yeah, yeah, exactly.
John Furrier
>> And it was like, wait, wait a minute. What's going on here? Yeah, we made the models behave, now the agents are going rogue. So now you got to rein that in. So, okay, models are behaving, thank you, Cypher-compatible. We just talked about that, but now the rogue agents, they're just trying to do the best they can, but if they don't have any guidance on the relationship maps or any context, they're going to just do their thing.>> Exactly, they have no idea who owns this data, who's allowed to see it, under which circumstances and everything.
John Furrier
>> It's like that video game, Pac -Man, where you just chomp through and just, okay, took the wrong turn, chomps up all the data. It's bad. that's kind of where the intelligence comes in. I think if you can harness the intelligence, get the data layer, almost, I call it the brain of a company. And a lot of people are thinking that way now, Magnus. Like, hey, if I can build the brain of my company, you have essentially, it's a graph where you can connect the different pieces of data, which is parts of the brain, that kind of a metaphor. You're seeing a lot of biology examples. The bloodstream is the data, the brain is the graph, and the data and thinking through that is key. So, this is what we're seeing a lot of these metaphors. What's your take on that? You agree?>> Oh, yes. The stuff that we see now, what our client is able to do now in terms of work orders and warranty repairs and getting quotes out and everything. Once you get all the data up there, the speed increase is really shocking stuff that usually takes an hour or two before we're able to solve in 60 to 90 seconds now. And that frees up time to do meaningful work instead of just sitting there and chasing documents in the SharePoint folder, which I think -. Grinding away.
John Furrier
>> Like I said, eating glass and spitting out nails. But again, there's light at the end of the tunnel. You're now a luminary. We should put this video also in our Mixture of Experts series because this was a great expert conversation. You're on the frontier and again, the value's there, great use cases. Magnus, thank you for coming on the Luminary series with Neo4j AI on theCUBE. Appreciate it. Thank you very much. It's been absolutely great. Thank you so much for having me. You're welcome. It's been great. Yeah, there's a lot of opportunities out there. I'm John Furrier with theCUBE. If you're looking at AI and you're looking at tapping into the models or having specialty intelligence with domain models, graphs are a beautiful thing, but you don't have to replace other things to bring in graphs. They add to the equation, they sit on top of data. A lot of advances we're seeing come out and a lot of the winners in the agentic world are looking at graphs and are expanding more and more and keeping that context on point and in line and keeping those agents and those models kind of behaving well. More content coming on theCUBE. We're doing our part to bring you the data. Thanks for watching. Thank you.
John Furrier