GraphSummit London 2026 - The Knowledge Layer for Trustworthy AI, Emil Eifrem

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: GraphSummit London 2026 - The Knowledge Layer for Trustworthy AI, Emil Eifrem · Channel: Neo4j · 49:25 · Watch on YouTube

Topics: AI agents, Data, databases and embeddings

Summary

Emil Eifrem traces Neo4j’s origins to the challenge of working with complex, connected data using relational abstractions, then explains why AI agents make reliable access to enterprise data an urgent issue. He argues that agents need three things to work reliably at scale: meaning, reach across disparate data, and continuous learning. He presents graphs and ontologies as foundations for these needs and describes the knowledge layer architecture and Neo4j Context Engine as ways to put that approach into practice. He closes by emphasizing that data architecture shapes how agents understand the world, and that relationships are a defining strength of graph databases.

Key points

Neo4j began after the founding team found that relational database abstractions were a poor fit for the large, messy, connected data in their enterprise content management application.
The property graph model represents data as nodes, relationships, and key-value properties; the important question is whether a data model is a good fit for a use case.
AI agents have become a third major consumer of enterprise data alongside applications and human analysts, making reliable context a critical challenge.
Enterprise data problems include unresolved entities, stale information, and conflicting values that lack a clear source of truth.
Eifrem frames the challenge as helping many agents act reliably across many heterogeneous and disparate data sources.
The three requirements for reliable agents are meaning, reach, and learning: ontologies provide meaning, multihop access provides reach, and memory supports learning.
A business-facing ontology describes concepts in the language of the organization, while a technical ontology maps those concepts to systems and data.
Agents may need to traverse many connected data sources and relationships; Eifrem describes this as multihop reasoning, which can go beyond single-step retrieval.
Agent memory should form a feedback loop: new information updates knowledge and skills so that agents can act on what the system has learned.
The knowledge layer architecture brings together ontology, reach, and memory; Neo4j’s Context Engine packages this approach with runtime and governance capabilities.

Chapters

Start	Chapter	Summary
00:00	Welcome and Neo4j’s London roots	Eifrem welcomes the audience and recalls that Neo4j’s first office outside Sweden was in London.
01:02	The problem that led to Neo4j	He describes how a content management startup struggled to handle complex data with relational database abstractions.
04:11	The property graph model	Eifrem explains nodes, relationships, and properties, and why choosing a suitable data model matters.
06:48	AI agents as data consumers	He identifies agents as a new category of data consumer and introduces the challenge of supplying them with useful context.
08:22	Enterprise data problems in a banking example	A refinancing scenario illustrates unresolved identities, stale information, and conflicting customer tiers across systems.
13:00	Context platforms, graphs, and ontologies	Eifrem argues that enterprise AI is bottlenecked by access to the right data and notes growing adoption of graph and ontology approaches.
19:19	The three requirements: meaning, reach, and learning	He introduces the three capabilities he sees as necessary for agents to work reliably across enterprise data.
20:23	Meaning through ontologies	Using an order-status example, he explains how ontologies make business meaning explicit and distinguishes business-facing from technical ontologies.
27:34	Reach and multihop reasoning	Eifrem explains why agents need governed access across data silos and deep relationships to complete complex workflows.
34:21	Learning and agent memory	He describes how memory and feedback loops can help agents and their knowledge improve as data and circumstances change.
38:04	The knowledge layer architecture	Eifrem presents an architecture combining ontology, multihop reach, and memory, with several possible configurations.
41:11	How an agent uses a knowledge layer	A practical flow shows an agent interpreting intent, locating data, enforcing policy, retrieving information, and retaining execution traces.
42:42	Introducing the Neo4j Context Engine	He describes the Context Engine as a packaged offering based on the knowledge layer and Neo4j’s experience with graphs and AI.
45:17	Ontology layers and design partners	Eifrem outlines the Context Engine’s ontology layers and invites organizations to work with Neo4j as design partners.
47:22	Closing takeaways	He summarizes the importance of data context and graph architecture for AI, then encourages attendees to make connections.

Quotes

nodes that are connected to other nodes through relationships. — 04:11

The bottleneck is giving the right data at the right time to these models. — 13:00

Meaning, reach and learning. — 19:49

It’s the type system for your data. — 25:00

The fact that we have relationships as first class citizens between our data elements. — 48:54

Concepts and entities

Emil Eifrem, Neo4j, property graph model, AI context platforms, ontology, multihop reasoning, MCP, Neo4j Agent Memory Service, Neo4j Context Engine, Redpoint, Google Research, Anthropic, OpenAI, Oracle, Palantir

Full transcript (original language)

00:00 [applause] Good morning, London. Uh, great to be here. And truer words have not been said. I used to say that I have the best job in the world, but I don’t get to build demos on exotic hardware in dark mode like my friend Steve Chin does and does so well. Uh, it’s phenomenal to be here. Uh we were started in Sweden about a trillion years ago. But some people don’t know that actually our first office outside of Sweden was actually

00:32 here in London. It was in my friend uh Jim Weber. He’s our chief scientist, employee number eight. It’s his bedroom in London was our first London office. And uh fast forward to today and you know we have you know several hundred people here in our London office near um London Bridge. And it’s actually our only I call it our only crossf functional office. So we have a big engineering team building many of the key parts of the product but we also have go to market and GNA and it’s like

01:02 an endto-end office. Uh so London has always been this really important place for us. So it’s always great to be here. So um we got started uh almost 20 years ago today and I was the CTO at a small startup in Sweden and we were building what we today would call enterprise content management content not context. We’ll talk a lot about context later today but enterprise content management. So we were processing large media files or at least what at the time felt like

01:34 large media files. So you can imagine tons of pictures and PDFs and things like that. And our job was to build what we today would call a multi-tenant SAS application to help make sense of all that data for our customers. So imagine a big file system. You upload your information and then we need to store that on the back end in some way. We had an engineering team of about 20 people and we had a massive problem with our data. And it turned out that half the

02:04 team about 10 people spent the majority of their time just fighting with the database. And this is a big surprise to me because in all my prior projects the database had been this big accelerant. It took this super big hairy problem of let’s take the data let’s ensure that it’s stored on disk make it queryable multiple users if things crash it needs to always be consistent online backups while it’s running like all of those

02:35 really big hairy messy thing took them off our table no pun intended so we could focus on building the application but something was different with this project and I think Today, 20 years later, as an industry, we have a clear understanding and a language for what was going on. But it took us a long time to figure it out. The root cause was that we had data that was a mismatch. The shape of that data was a mismatch with the core abstractions exposed by our core data structure and core data

03:06 infrastructure. And so we had data that was really big and messy and connected and complex. And we had abstractions that look like this. rows and columns in the relational database. The relational database is an amazing piece of both computer science and engineering. Sometimes people want to make it out such that, you know, because I represent another type of database that I hate the relational database and stuff like that. I actually think it’s a fantastic, you know, piece of software. Um, it isn’t good for everything though. And we had that

03:38 problem where there was this mismatch between the data that we had and this core abstraction. And we ran into the problem. We banged our head against the proverbial relational wall for a while until fundamentally we said you know what there’s got to be a better way of doing this and because we were young and naive we said you know what we actually first we looked around and tried to find other ways of doing it certainly other people had run run into this problem before but after a while young and naive we said screw it let’s just build it from scratch quote how hard can it be

04:11 and here I am 20 years later we’re still working on building that that database. What we ended up concluding was that many of the problems that we ran into could actually be abstracted out as concepts or entities that are connected to other concepts or entities or rings that are connected to other rings through dots, sorry, through lines, right? Or dots that are connected to other dots through lines. In other words, nodes that are connected to other

04:43 nodes through relationships. And if we had those fundamental two abstractions, nodes relationships, plus a third one, key value pairs that you can attach to both the nodes and to the relationships, holy crap, we could model everything. Subsequently, it has been proven out that you can model everything. Uh probably three or four decades ago that that was proven out with a relational model. You can take any piece of data and model in the relational model. The property graph model as this now has

05:13 been been termed is isomeorphic with a relational model. Thus you can model everything every piece of data you can be model with these abstractions. But that’s true of any type of database. It’s true of document databases of key value stores of relational database at least the big popular ones. So that’s no longer the interesting question like can you model your data? The interesting question is it a good fit? It turned out that this way of representing data was a great fit for a lot of important use cases. So, fast forward to today and

05:47 every single one of the 20 biggest banks at least in North America are now customers and users of this technology. Every single one of the 10 biggest car companies in the world, every single one of the 10 biggest pharmaceutical companies. There were a few people who raised their hand when Steve asked if you were here a year ago. The eagle-eyed people from a year ago will remember it said nine out of 10, you know. So, we’ve made progress since we last met. Um, and so on and so forth. Eight of the 10

06:17 biggest retailers, insurance companies, and so on and so forth. Almost all of the Fortune50, 85 plus of the Fortune 100 now use Neo Forj in production. So huge amount of of success. All this on the back of this instinct that we had that we articulated as the mission statement of the company which is we want to help the world make sense of data. This we said pre- AI we thought it was valuable even back then. Holy crap

06:48 is it becoming more and more valuable by the day. Speaking of data and speaking of AI, it took me I don’t know four or five minutes on stage as a tech CEO in 2026 before I said the word AI. So I think that might be a a record. But having spent my entire career focused on data, I’ve seen the biggest change happen in data in the last 12 months. And we all know that AI is the big

07:18 driver of this. But to be a little bit more specific, the big discontinuity is that for decades, there were only really two types of consumers of data. If you had data in a on on a file system or on on disk, there were two types of consumers of that data. The first one is an application. Many of you in here are developers or were developers, right? And so you write an application that gets the data out of the out of the database. That’s the user. The second type of user is some form of a human

07:49 typically analyst and there might be some BI dashboard there might be some spreadsheets involved there might be some reports involved but ultimately a human end user is the consumer of that data and in the last 12 months a third category has come online and it’s of course that of agents. Now we have agents that are looking at that data autonomously, assessing that data, making decisions based on that data. And holy crap, that changes everything.

08:22 A little bit more specifically, let’s talk about an example of this from the perspective of a large organization, right? So let’s say that we’re on a journey to identify our big organization. And maybe this is I’ll use an example from financial services since we’re here in London. Lots of I’ve seen the the stats that lots of people from financial services represented here in the room today. So let’s say that we’re identifying our experience and we have an agent receiving a call from a customer. In this particular situation, the customer wants to they have a loan

08:53 with us and they want to refinance because a competitor has off came come in with a better offer, right? And so it’s an important customer with several products that we have, lots of relationships to various parts of the bank. And we have some kind of window, let’s call it, in this case we said 30 seconds to make a decision. Should we match that offer? Should we beat the offer with a better one or should we just let the customer walk? So let’s unpack that scenario. Right? Ultimately, we need to figure out what product can I

09:24 offer this customer and at what price point. And so what do I need to know if I’m the agent trying to figure this out? What’s some of the pieces of data? So first of all, I need to understand who’s calling, right? And that’s actually pretty easy, right? Because they’ve identified in some kind of way when they’re talking to to the agent and I have access to a ton of data. Why? Because I’m a big bank, right? So who’s calling? So let’s look at some of the data in this example. So, in the call center over here, that customer has

09:54 identified themselves as Charlie Dolan, and that’s probably what they said when they talked on on the phone with with the agent, Charlie Dolan. And then they have a loan with us. So, there’s an origination system of record. Origination in a big bank is all the work that you do prior to approving the loan, like the KYC and all of that kind of stuff, right? And there it’s passport verified to say Charles Dolan. And then in the actual loan servicing which happens once the loan is approved and that’s all the payment and all that kind

10:24 of stuff it says C Dolan which is ridiculous obviously hypothetical because we had loan origination saying Charles Dolan and of course the handoff over here would never end up with C Dolan [snorts] except every single person here has ever worked at the big company has seen exactly this happen many many times. So we have the same individual identified by three different names. This is called unresolved entities. One example of the type of problem that might occur in the real

10:55 world in a large organization. Okay. So that’s the first question we want to answer. Who’s calling? Okay. The second question we’re figuring out like should we match or beat or let the customer walk? So how much do they earn? So we look inside of the data for that and that exists across several systems of records. We have a some kind of a mortgage system. We have a credit card system. And we have a wealth system. And they actually have different numbers. And we look at this. And why do they have different numbers? Well, the

11:25 mortgage one, that’s back to when he actually applied for a loan. And it says $145,000 was was his income. With a credit card, it’s self reported. And then there’s a KYC in the wealth division that was verified last month. So, we’re looking at this and the data is actually from different time eras without the metadata associated saying when it last changed. I’m sure it’s some audit logs somewhere. Certainly isn’t available to the agent to be able to figure out. So, that’s the

11:57 third type of sorry the second type of problem stale data same right accurate data but wrong time unit. And then the last one is have some kind of tier for the customers, right? And what tier are they is an important factor when they’re the agent is going to decide. And here we have different things. In the retail bank, it says that it’s a standard tier. In credit cards, it says it’s silver and in the wealth it says gold. So this is all accurate just from different perspectives. So in this case we have

12:28 conflicting data without an established priority hierarchy of what is the single source of truth for this particular dimension on the customer. So three like a non-exhaustive list of data problems that this agent is running into in the real world at a large enterprise. Okay. So what is emerging is this view that I see across our customer base today which

13:00 is at least inside of large organizations AI is no longer constrained by model intelligence right we have freaking sci-fi level intelligence trapped in a little box that is available to us on tap today it is phenomenal what these new AI models can do. Yes, they are uneven. They’re not perfect across every single dimension. Jagged intelligence, but holy crap are they amazing. That’s not the

13:31 bottleneck. The bottleneck is giving the right data at the right time to these models. What people end up calling context. And a really fascinating thing that has happened to the industry over the last call it maybe 12 to 18 months, maybe more like 9 to 12 months. I feel like everyone is now converging on exactly the same problem. At least when I think of when I frame it down to getting AI to work inside of the enterprise, inside of

14:02 large organization, exactly the same problem. It’s some version of I have M agents running across n heterogeneous, disperate, messy data sources and I need to make sense of that, right? M agents across N data sources. How do I get them to act reliably at scale? So, Gartner has done a lot of work on this and they have coined at least an

14:34 initial name for solving this problem that they call AI context platforms. AI context platforms. It’s a great report. We have one of the authors here somewhere. Hi Aros uh of that report. It’s a really great report. Um and even like I think the name even in the report you say that the name may not stick but the problem is very very real and I want to as an aside on on the name uh context is a word that we hear a lot

15:06 in AI today and context we have a long history of talking about context actually it turns out at our event here okay in London not in this this room almost 10 years ago. A younger a slightly younger version of me uh gave a talk kicking off an equivalent of this talk at our the bigger version of this conference. Graph Summit is the city bycity tour. Back in those days we

15:37 did Graph Connect which was an annual conference that we held twice per year. Go figure. Um, this one was here. We called it Graph Connect Europe, even though it was in 2017 because a year after Brexit, because we were still naive about that. Um, and my favorite section of that keynote was the let’s look forward 10 years. It’s like, okay, where is the world of graphs going? It’s still on YouTube today. So, you can you can uh hold me to my hold me accountable to my BS by looking at that and uh see

16:09 if it makes sense. But why talked about the future of graphs and I said one of the key drivers of the of the adoption of graphs over the next 10 years is going to be AI. I use the word deep learning and machine learning rather than than AI and why because context drives meaning and precision for machine learning systems. And I went on to talk about what context actually is. And this is an example of my context. Right? So this is my context in 2017. I am the

16:40 father of two kids and this was just a few weeks after my my uh daughter was born. So I remember I had a little animation with a stroller coming in from the left. So now three kids. I work at Neo forj. This is our old logo. I’m married to Meline. I play the piano occasionally. I watch a TV that looks like it’s from the 50s. I’m not sure what’s going on over there. I was born in Sweden. It says that I drive a Tesla. That actually is fake news. I drive a Volvo because Sweden. Um, so if you

17:11 think about what happened right there in about 10 seconds, I gave you a much richer understanding about who I am. That added a lot of color to me as an individual. And it’s all about how I connect to other concepts in the world. Context is how you how an object relates to everything else in the world. the relationships. So, we’ve seen this for a long time, but boy

17:43 has the world caught up. Just in three months between April and June, everyone and their mom in terms of the key data platforms and cloud platforms launched a product to solve exactly this problem using exactly graphs and ontologies. A couple of examples. This is data bricks launching Genieontology in June of this year, incorporating an ontolo ontological view of their data platform. Snowflake a month or so

18:14 earlier did a similar thing with with Cortex. Palunteer of course has been founded as an ontology company from day one. They’re even slightly older than than we are and founded on ontology as the one of the key if not the key secret sauce to make sense of data and the cloud plat platforms as well. So, Microsoft Fabric went GA in in in June with fabric graph and fabric IQ. Google launched their knowledge catalog with based on based on

18:46 graphs. And AWS has AWS context which is a knowledge graph on top of their data estate. So everyone is independently coming to this conclusion that in order to solve the M agents across N messy data sources, you should use graphs and ontologies, which is great news because after spending the last 12 to 18 months really immersed in specifically this problem as

19:19 as um with a driver being agents using using data. We have a extremely clear view on how to do this. We as you know have been doing graphs for 20 plus years right now. AI in production for over a decade and specifically transformer-based AI models call it modern AI for about two years right now in production and what’s emerging is an

19:49 very very crisp understanding of exactly how to solve this problem. I need my agents to act reliably at scale across my data my landscape of disperate data sources. And to solve that problem, there are exactly three things that we need to convey to our agents. No more and no less. Exactly three things. The first one is we need to convey the meaning of data. The second one is we need to give our agents reach across the enterprise data ecosystem in a way that respects security and policies. And we

20:23 need the system to be self-learning so that it wakes up tomorrow smarter than it was today. Meaning, reach and learning. So let’s double click on each and every one of these. So meaning so what are we talking about here? So let’s say that we have this application. It’s using data in this database. In this example, I’m going to use just some simple order form type thing going on like an order log I guess, right? right? Where we have some kind of order ID, we have a status of

20:54 the order and then we have an amount per order something like that. The status is two for this particular order over here. The the one in blue what status is two equals to means is encoded in imperative code in Java in this case in this application. If status equals two, go on and do these things hold the order and notify the the review team or something like this. That is what two means. That meaning is encoded in software in the

21:25 application. Okay. The same data cons you know consumed by the second type of consumer the human analyst. It’s in their head two means suspended pending review and it may be on some post-it note. It may be in some Google doc somewhere. It may be encoded in some Tableau BI dashboard, but ultimately it it’s out of the head of the human analyst for the agent. The agent is going to look at this data and two it has no

21:56 idea. It has no idea what two means. [clears throat] And so now as an industry we’ve converged. How do we solve this meaning problem? Everyone is saying ontologies to the rescue. And I’ve spent 20 years of my life in the graph universe trying to avoid that world word because it just conveys complexity. Right now all of a sudden everyone is talking about ontologies. And I think there’s it’s because of AI but honestly also because

22:27 Palunteer has kind of made the term acceptable. Now there’s still a lot of people who have opinions about ontologies. for example, that you have to be over 40 to even discuss ontologies. And I get it, right? Because actually, if you think about the word ontology, it goes all the way back to the old Greeks. Aristotle in metaphysics 4 talk about the structure of reality itself, right?

22:57 Way back in the days in a little bit more modern time, still feel feels like a while ago. Tom Gruber at Stanford in 93 had a great definition of what an ontology is for computer science. It’s an explicit specification of a conceptualization. I actually really like that definition, but it’s one of the categories of of things where if you know if you already know what an ontology is, you’re like, “Yes, that’s exactly what it is.” But if you don’t know what it is, it doesn’t help you at all. Right.

23:29 Um, and then the palunteer, they have several ways of talking about ontology. This is one of them. It’s a digital twin that connects an organization’s raw data to the real world business concepts. Um, I like this one. This is from Graph Connect uh in New York in 2018 uh where Dr. Jesus Barasa uh gave a talk about how to store ontologies in in Neo4j. Jesus, are you

23:59 here somewhere? He’s over there. So, Jesus uh um spent he’s a PhD in knowledge representation in AI. Spent seven years at the ontology company. Um and then a decade at NeoAJ. Um many of you have worked with him or his team running a big part of our solution architect organization. And for the last year or two, he’s been our field CTO for AI. So he has a dedicated team that works with like our most frontier

24:29 companies in putting graphs and AI in production. There’s no one on the planet that knows more about putting graphs and AI in production. So after this keynote, don’t come up and chase me, chase that guy. And you you can just see how credible he is because clearly he was below 40 at the time, right? And still discussing ontologies. these days however [laughter] so he talks about ontologies as this it’s a domain model don’t be too silly about it conceptualization of a

25:00 specification no domain model it needs to be three things though it needs to be formal so machine readable it needs to be explicit so not pros in some Google doc kind of thing and the point is to have it be shared right shared across maybe applications shared across teams that’s what is I really like that definition another one is the nouns and verbs of your business. What’s actually going on? Who are your customers? What do they do? What do they have? Right? And how I really think about it, it’s

25:30 very simple. It’s the type system for your data. I’m ultimately a software engineer by background, right? And this, you know, the the data is the instances and the ontology is the the classes, the types, right? The type system. Okay. So, this is a realworld example of an ontology. uh you know you I’ll talk a little bit more where this is this is coming from right where you have not a single example of an ontology but you have multiple ontologies uh for a given

26:00 application or a given enterprise but this is a great example of where the people who love ontologies tend to go wrong. It’s like overwhelming with complexity off the start. And actually when you get started there’s really only at at enterprise scale for large organizations there’s really only two that you need. It’s a domainfacing it’s a businessfacing ontology and it’s a technical ontology. The first one describes your customers,

26:33 your bank accounts, your transactions, your credit cards, your insurance plans, your whatever it is that your business is about, what your colleagues, how they talk about your business. It turns out that agents quote unquote think in the language of your business. This is how to encode that in your businessfacing domain ontology. So that’s the first one. The second really important one is the technical ontology. That one is a

27:03 map to your data state. It says that over there at that IP address is an Oracle instance. Inside of that is a schema where there’s a customer table and that customer table has a column called F_name, right? And then very importantly, you have the mapping between the two. All of a sudden when your agents want a customer’s first name, it knows that the customers have first name through the ontology the customerf facing ontology

27:34 and then it has the mapping down into that particular f_name column in that particular Oracle database. So those are the two fundamental ontologies that you need to get started with agents um in in AI. Okay, so that’s the first one. The second one is reach. This one is absolutely fundamental, really, really important. And when I talk to people, when I talk to other data platforms, when I talk to analysts, this is the one that most people miss. They don’t understand how absolutely crucial this

28:07 one is to make agents work. And so, think about this one from the perspective of where we’re going in the universe, right? So, this is a great report from a a Silicon Valley venture firm called Redpoint earlier this year, and they talked about where we are in terms of adoption of agents. It’s a little bit dated because it’s like six, seven months old and you know how fast this universe moves but it still holds up really really well. And what they’re saying is 25 and earlier we were in the let’s call it chat and co-pilot era and the independent runtime of agent was in

28:38 seconds right and we were mostly conversing with with with with our agents. Where we are in 2026 is in the universe of task agents. So the independent runtime now is typically in the minutes and it takes on fairly narrow tactical a aspects uh of our business which might still be extremely valuable. What we’ve seen by the way internally at Neo Forj is that throughout 2026 we did have made a

29:09 little bit of a switch inside of task agents where earlier in the year most of our customers used task agents with humans in the loop like for example they would end up drafting some message but still the human being would be clicking send and sending it out to our customers. So that’s where we started in 2026. By now, many of our customers are making them completely autonomous. Still within fairly narrow remits, but completely autonomous.

29:39 The next step is end to end workflow agents. So, this is taking on an an entire business function orchestrating this multi-step process end to end with runtime in the hours and then ultimately we’re going to drive it up towards towards days to get what they call autonomous agents. So that’s kind of where we are and what’s going to end up happening as we move from task agents to endtoend workflow agents. We’re going to need to be able to go much deeper. Our

30:10 agents need to be able to go much deeper across our data estate. And so let’s talk about this from the perspective of an example. Let’s say that again we’re a large financial services organization. We do mortgages. We have lots of customers and we want to go in and we want to offer send send messages that offers a refinance uh to to our customers some kind of upsell offer. It might be over text, it might be over email, over time, maybe even like a voice agent. But let’s just focus on text for a moment. If you think about

30:40 that that solving that problem for that agent, what do you need to do? So first of all, you need to find the customer, right? Right. Okay. So, this is a particular customer that we want to to draft a a refinancing upsell offer for and we need to look at their data. So, this customer has one house and on that house they actually have two mortgages with one bank. So, that’s important for us to know obviously if we’re going to send some kind of a refinancing message to them. Uh but not just that, we also need all the prior communications which

31:13 we have across three modalities. We have emails, we have text messages, SMS text messages, and then we have call transcripts, right? All those three are deep chains that we need to traverse. So, in order to draft this upsell financing offer, we need to traverse this entire data estate which is I don’t know 5 10 20 hops deep or something like this. And we ideally want to be able to do it in real time. But then of course in the messy real world then this

31:44 customer has a spouse and another house that is jointly owned and that spouse has exactly the same thing. Another loan with a separate bank and they call transcripts and communications with them. All of this you need to take into consider consideration when the agent drafts the perfect upsell rate refinancing offer. And then you take this data structure and you look where it would might be stored inside of your enterprise and it rarely sits in the

32:16 same system. It’s going to be spread out across multiple silos. And imagine if all of them are relational databases, which is still the case, right? And even if one of them is a graph database, that’s very very hard because here we’re talking not 5, 10, 20 hops. This is probably a 100 hops deep or something like this. And you want to be able to do it in near real time to be able to do this at scale with many customers. That level of reach is very very

32:47 important for an agent to be able to have. Um this is called multihop reasoning. And even though I just said that few people in the data world are talking about this, the labs have figured this out. So they talk about it. So Google research talked about current singlestep rag systems were not designed for the multissource multihop queries of modern business workflows. This is Google research in June of 2026 a few months ago. The same from an anthropic saying

33:20 you have a pile of unstructured documents no single document contains the answer. Rag retrieval so retrieval augmented generation rag. So vector only rag is what this means. what uh Steve showed you on the left in his demo uh won’t chain the facts for you. You need a knowledge graph that’s enthropic. And then OpenAI almost a year ago said, “Okay, this method allows you to answer complex multiaceted questions beyond what single hop retrieval can

33:50 accomplish. Uh actually in your neck of the wood, there’s been a great uh research uh report released very recently. You can see it here. National Innovation Center with an RE, not an ER. It’s here somewhere. Um, which uh has really great like scientifically robust, reproducible benchmarks talking about how accuracy goes way up when you add a knowledge graph on the retrieval path uh for your

34:21 uh for your agents. So that’s the second pillar then reach. Now to the third pillar, learning. This is maybe the most intuitive one. I think we all feel just intuitively that agents have to become better over time, but it’s important to remember that it has to apply to both of those pillars. It has to apply to the schema level or the type level, the ontological level and the instance level. And why is this? Well, first of all, the

34:53 enterprise landscape is changing all the time in terms of your data, right? Why? because the world is changing all the time. So your agents, even if they just did exactly the same thing, would still need to learn because everything is changing. But then, of course, a huge part of getting to escape velocity with AI is this RL loop, the reinforcement learning loop where your agents wake up tomorrow smarter than they were today. We’ve done a ton of work with this at Neo Forj. So it turns out that memory is

35:27 an intrinsically graphshaped data structure. Um MCP I’m sure everyone here knows what MCP is. When I ask the question that way no one dares not to raise their hand. [laughter] Um so the model context protocol actually the first release of MCP ships with a tiny little this is a hard thing to say a tiny little in-memory memory implementation. So an in RAM agentic memory implementation um which is a toy. It’s 300 lines of Python. Uh but it’s

35:59 actually a graph and there’s a ton of startups that are building agentic memory on top of of Neo forj. So lots of people are are independently concluding without even talking to me that memory is a graph shaped uh data structure. Um there’s at the high level three types of memory that I think mostly about. There’s short-term memory which is your core conversation and what’s going on live right now or in the or in the short term with your agent. There’s long-term

36:31 memory and then there’s the agentic execution traces or the reasoning memory. Um, and the most important thing that I see where people go wrong with agents is that they end up storing the memory, but they don’t have a closed loop system to be able to act on that memory. In the NAM’s service, this is the Neo Forj agent memory service. I’ll throw up a link in a moment. We are encoding that in the entire piece of software. So where you start with your

37:02 raw information you convert that into your into knowledge with what are the nodes and concepts but then very importantly you then express that in a scale and that skill is represented in the graph and you can materialize it as a normal skills markdown file for your agents to consume. When things change over here in the raw information, your knowledge base gets updated and that invalidates your existing skills.mmd which gets regenerated so that your

37:33 agent actually immediately uh acts on the new knowledge that the system has learned. Uh there’s a QR code down there. It’s a great uh blog post outlining how this works uh in in practice with a Neo Forj agent uh uh memory system NAS. Okay, so we’ve talked about this really valuable problem. I need my agent stack reliably at scale across my messy data state and the three pillars that are required to get there. The first one

38:04 meaning we solve with ontologies reach through multihop retriever or multihop reasoning and then learning self-learning uh with with memory. And the really good news is that over the last year, year and a half, 12 to 18 months, we spent a ton of time on this together with lots of customers, some small, some big, some here in this room actually, including large banks, uh, a massive global tech platform, uh, out of

38:35 the US West Coast, and a leading property tech company to really focus in on solving this this particular problem and what’s emerging is this blueprint that we call the knowledge layer architecture. So the knowledge layer architecture unsurprisingly has three pillars. The first pillar is the ontology pillar. Here you can see the domain model the business facing domain model. You can see the technical ontology which is the systems metadata of exactly where your

39:06 data sit and then your business rules and actions. The second one is reach. This is an ability to go deep and traverse your your data. And there’s variants of that. You’re going to see some examples of this later on in the product session. And then you have memory of course long short-term procedural memory and then the reasoning memory or the context graph. This is the knowledge layer architecture. And there’s actually multiple configurations of this. So one

39:38 is what we call the ontology based semantic layer. This is a really easy way to get started. Semantic layers is another one of those terms that is really really overloaded in the word world of of AI right where some people talk about it as BIcentric semantic layers which is very metric centric uh other people come from the RDF world and so on and so forth this is an ontology based semantic layer and it’s a configuration of this architecture where you take all the ontology pillars just with some reference data so the ontology

40:10 might describe all the geos that you’re in, but the reference data might be, hey, if we have a drop-own list of all the cities, how do we prepopulate that? So, that’s an example. Um, and then there’s a configuration where you start with the ontology based semantic layer, you add memory to it. This particular one, I gave a talk at the AI engineer world’s fair in June. Uh, it’s a very short 9-minute talk. If you want a really brief overview of what I’m talking about here that you want to send

40:41 your boss for example, this is a good articulation I think. And then you can also start with the ontology plus uh the data. So there’s various ways and shapes that you can configure uh this this architecture. What does it look like in practice though? So let’s say that you have implemented this and you have an agent running. So let’s look at that. um just very pragmatically a flowchart. So let’s say that we have an agent which wants to

41:11 answer like a similar version of a question that we asked before. What’s our exposure to this customer right step one is for the agent to interpret intent and it calls upon the business facing domain ontology for that what even is a customer what do we mean with exposure those types of questions and then it needs to assemble the context. So after that it goes to the technical ontology. It’s like okay I understand the concepts now where do they sit in my data landscape and then very importantly in

41:41 any large organization you got to enforce a policy right so what things am I who am I and what am I allowed to access what are my entitlements after that it it’s now assembled the key parts of the context and then it needs to figure out okay how do I get the data and there’s two ways of doing that with a knowledge layer one is you deep query Right? So the technical ontology pointed to that Oracle database. Right? So you deep query into that Oracle database to get the data out. The other one it’s

42:12 prematerial pre prematerialized already in the graph. So then you can do the deep traversal right away. So that’s the two ways. And then after you’re done, you leave the agent exhaust all the runtime traces from the agent you leave behind so that you can RL on that and self-improve both the ontology and the core instance data. So that’s the full flow of uh how an agent might use a knowledge layer in in

42:42 in practice. So as I mentioned for the last year or so we’ve been building out this architecture with customers and what we’ve learned is that this is super powerful. It is those three things they are what an agent need in order to work in reality in the messy world of large organizations. [snorts] But it also takes a while. It is something that you have to build from scratch on top of the graph intelligence platform that we’ve spent 20 years

43:13 building. So what we’ve realized is that hey wouldn’t it be great if we could take this and prepackage it and give you an offering where you can’t get to 100% because every single large organization is unique but maybe 80% or even 90% there. And so we call this the context engine. the Neo Forj context engine. And what it is is taking this entire architecture and all the learnings that

43:43 we’ve had from the last year, year and a half, but really the last 20 years of doing graphs and 10 years of doing graphs in AI. Pour that into one product that sits on top of the graph intelligence platform that treats context in the same way that we’ve now learned how to treat our data in a completely first class citizen way. And it consists shockingly of three core pillars. You know them. The first one is

44:16 the ontology. And in here, it’s not just the capabilities of working with ontologies, but actually ships with an existing ontology that we’ve learned over the years that this ends up encapsulating much of the core aspects of most customers. And there’s of course different configurations per vertical. Um, it has a runtime so that you can run this in production. Of course, the fundamental part of this is the near database which has been running in production for many many years now.

44:47 And then you have the memory pieces that I talked about before, including the end-to-end full life cycle connectivity through scales markdown files and and all the the full feedback loop of that. And then on top of that is a human centric, believe it or not, a governance plane where you have a studio where you can go in, you can look at it, you can put humans in the loop, approvals, all of that kind of stuff is really really important today and will be for many

45:17 many years in the in in in the future. So we build that right into the context engine offering. So in practice what this looks like is there’s a six layer meta model or a six layer ontology cake that you can mix and match but that ends up representing this meaning reach and learning really really well and at the top are these two

45:48 layers. The first one is a business process layer where you can say hey I am have a bank account that’s a business process I have the various steps that I have to walk through to be able to open an an account and the second layer has all the core business concepts. So what is a customer? What is a credit card? What is a bank account? All of that stuff. And then you have the physical layer which might have data products depending on if if if you use that that

46:20 those concepts in in your business and the actual systems that we talked about before. And then you have the core capabilities that your agents might need. This might consume information from an MCP registry and other other things like that. And then ultimately the exhaust of the agents the agent execution traces. This end-to-end ontology is a really good at least start to get that um enterprise knowledge layer up and

46:50 running in a large organization. If you think this is looks interesting, if this feels like something that uh is um interesting to your organization, we’d love to work with you. This is a journey where you know it’s early in that journey. I think the world is learning how to do this today. like how do you get agents to act reliably at at scale and we’d love to work with you more closely as design partners to help shape this this new offering.

47:22 Okay, so I’ve given you a ton today. That was a lot of information. Uh I wanted to try to take a little bit of a step back to just kind of summarize in a pathy way of what I’ve tried to convey here. So first of all, our models, our AI models are amazing. AI, at least inside of large organizations, is not constrained by model intelligence today. They’re constrained by the data that we give to

47:52 those models at the right time. And I think our job as data people is to design the world that our agents think in. And it turns out that the data architecture is that world. And most importantly of course for me is that graph is this very very natural data architecture for AI. So those are the three key things that I

48:23 would love for you uh to to remember. I’ve done this for about two decades right now and I almost always end my talks with in the same way which is at other data conferences you know people talk about scale and precision and performance and all that kind kind of stuff and I think that’s really important as a database geek that’s what I’ve spent most of my life focusing on how do you get data to actually work reliably at scale and all that kind of

48:54 stuff But fundamentally what sets us apart though is the core data model. The fact that we have relationships as first class citizens between our data elements. So I want to encourage you here at this conference to not be tragically isolated documents. Please go out and talk to your fellow attendees, make connections and really enjoy the rest of the day. Thank you everyone. Thank you very much.

49:25 >> [applause]