NODES AI Opening Keynote: Exploring Context Graphs: From Data to Decisions - Extended Version

This talk focuses on the emerging relevance of context graphs at the intersection of AI and graphs. The speakers discuss the role of decision traces in capturing the rationale behind outcomes stored in record systems, which is vital for improving agent productivity. They highlight that context graphs enable organizations to create a form of institutional memory that enhances the decision-making capabilities of AI agents. The discussion encompasses the need for a decentralized approach to context graphs, addressing both local and global views. Furthermore, they stress the importance of building applications based on real problems rather than abstract concepts. The conversation also delves into governance, trust, and how agents can effectively access and utilize diverse data sources in an enterprise setting.

[music] >> We are here kicking off Nodes AI. We have We're soon going to break into three tracks with more than 40 talks at the intersection of AI and graphs. And to start off, there's no better topic than context graphs, which has been super hot a super hot topic the last couple months. And I have a distinguished panel of guests here. Let me go through and ask

each one to introduce themselves. Everyone, my name is Animesh Kirtane. I'm the founder and CEO of PlayerZero. We're an AI production engineering platform and super excited to be here. Glad to have you. You wrote one of the best blog posts on context graphs. >> [laughter] >> A couple of months ago. That's awesome. So, Lars Andresen founder and CEO of Indykite. Kind of like the application infrastructure for

AI. Specifically trying to build a control plane and talking to all the different data out there and then also controlling all the access. And my name is Will Lyon. I'm a product manager at Neo4j on our AI innovation team. I'm working on building tools for making it easier to build and orchestrate your agents. So, my name is Emil Eifrem. I'm the founder and CEO of Neo4j. All

right, let's jump in. Animesh, let me start with you. Jaya from Foundation Capital was scheduled to come today. Unfortunately, was unable to make it. So, I'm going to ask you to channel her a bit. >> I'll do my best. Yeah. She wrote this incredible post in December where she actually referred to your company and it clearly hit a nerve. It went super viral. Yeah. Why do you

think it hit the nerve? What nerve did it hit? And what's the real opportunity here? So, you know, the context graph piece really really went viral. The I think the thesis was that 2025 was supposed to be supposed to be the year of of agents in the enterprise. And as the year went on, it became really clear that there was there was a gap, right? Agents were

creating really cool demos. They were able to stitch together, you know, different systems of record, you know, do work that otherwise was, you know, purely done by humans in the past. But as these things started becoming, you know, more and more deployed in in in production scenarios, there was, you know, something missing. And I think context graphs went viral because they took a, you know, prescriptive stance

on what that gap actually is and how to close And so, you know, the core idea behind context graphs was this idea of a decision trace, which is, you know, for every single thing and outcome that ends up being stored in a system of record, there's a bunch of decisions about why that end up being lost. And if we can capture that, then we can start creating

a new form of, you know, externalized institutional memory. And that ends up being kind of the, you know, the missing link for agents to be really productive and effective in the So, separating the system of execution from the system of knowledge and memory is a key part of this. Exactly. And can you talk more about decision traces? Let's drill in one more level. What what [clears throat]

is that actually? Yeah, I mean, I think I think a good way to think about this is to kind of like reverse engineer the outcomes that are stored in systems of record. So, let's take something simple, right? We think of Salesforce, right? As a system of record. And it's a system of record of customers. And so, when a deal is stored in Salesforce, we end up storing

something in the order of, you know, we closed this customer for $100,000 and, you know, the renewal's coming up in the next 12 months. The entire negotiation of how did we get there, right? Oh, we're at the end of the quarter. They had only this much in budget. You know, these are the specific people that we talked to and, you know, here's what their personalities were. We

had this particular champion who was, you know, really liking us, but this other person was a detractor. All of those nuances end up being lost. And that ends up being actually really important. So, that way when we're actually looking at the renewal 12 months later, right? To be able to understand why the deal was closed in the way that it was. that ends up becoming the the

the decision trace, the the series of kind of decisions that actually kind of led to a particular outcome. A context graph is basically a fabric of decision traces that are woven together. And I think the key insight here was agents instead of humans end up owning these decisions, their trajectories actually end up becoming the decision trace. Right? The agents are the ones actually making the decisions about,

you know, maybe we should negotiate in this way instead of that way. Or we should offer this particular price point instead of that one. And, you know, in in PlayerZero's sense, right? We should, you know, look at this service instead of that one. Right? And so, these end up beco- the the these accumulated over many different agent trajectories end up becoming decision traces that can all of

a sudden be captured in a world where, you know, for the last two decades, we never really could introspect into them. That's great. Lars, let me shift to you. You've built various technologies around graphs um uh previously at Four Js and currently at Indykite. And you're building tools that deal with context graphs, but also infrastructure that agents require in order to be able to work with context

graphs and decision traces. Give me your perspective from actually having being in the process of doing it. First of all, I think what you just said about the difference between 25 and 26 kind of like now in the enterprises, people know they have a problem, which is a huge thing. Of course, these these agents, they are connecting to a lot of different systems and they are making

the whole context graph actually becomes a decision engine. And >> [clears throat] >> and understanding the the context is core. And I also I think from a learning perspective kind of like keeping track of all these decisions actually going to make the next agent or next behavior or now next action much much better. So, we kind of like been building everything based on the context graph out

of the get-go. The flexibility, the kind of like the value it actually gives us, it's just kind of like super. Then we integrated that also with the core identity systems. Kind of like identity is kind of like kind of gives the birth certificate to the data. If you really can trust and know where the data coming from, that sensor or that agent or that human, you actually

can say something about the quality or the trust in the data. If you then also have the context to it and you can connect the data sources, you have a really like we also actually call it a system of intelligence. And the core to this all the decisions is the context graph. Just drill into trust a little bit cuz this is such a big issue with AI,

right? And arguably one of the reasons AI projects can't make it from pilot to production is that you can't achieve trust, be it with a business stakeholder, regulator, end user. What do you see these ingredients of trust? You you kind of named two, which are agents able to access the right things and not the wrong things and that speaks data privacy and so on. And the other

is the quality of the decision itself. I think it has a lot to figure out kind where does the data come from? What is What is the kind of like >> uh quality of the data. And that can be a lot of different things. It can kind of like can you identify the source truly? Kind of like is the the data using kind of What is the

timestamp? Is it kind of like 3 years old or is it something fresh? Is it just a comment from one person? Is it actually proved? There's a lot of things that you actually need to combine to understand the two the trust. So, we we have something we call trust scoring where we kind of like can decide what kind of elements needs to be in place for giving

it a high trust score. And if you have a high trust score, you can tell the agent, you can continue. If that trust score is not met, you shouldn't continue or you should ask another agent or a human for interaction. So, uh and the trust of it can be a lot of things. Like as I said, location, where is it Who entered it or to what How

did it get into the system? The age and a Of course, your context graphs actually encapsulate and bring in a lot of things. I was pretty tickled this morning. On my way to the recording studio, I actually noticed that Gartner just this month published a piece with a hype cycle on AI agentic AI and context graphs now show up there. And they're actually reasonably far up the

curve. They're still in the first phase. They're so late. >> Come on. Well, Emil, let me flip over to you. So, you and I for years have actually looked to Gartner for various kinds of signals. What do you read from this and how should the audience interpret this as a signal um whether they're an enterprise or a startup or a startup selling to the Yeah. I think

to the to late comment, I think, you know, some people would say that Gartner's the they're masters at predicting the present, right? In >> many ways, but they are a really good barometer in many ways of actual maturity of enterprise buyers, right? And I think it is very telling that, you know, we we Philip and I, we were presenting at to a senior executives at a big

bank just a few weeks ago. And you pulled together a few Gartner quotes that were released just in February about the value of knowledge graphs and and and AI. And there's like several reports talking about that just in the last few weeks, right? And I think that says something about the the maturity of adoption in the enterprise for knowledge graphs broadly speaking. This is Nodes, so this

is about not just context graphs, but but knowledge graphs and AI broadly speaking. Specifically for context graphs, at least what we see in the Neo4j community is that it's the kind of the normal spectrum of startups are much earlier adopters of context graphs and that's as a term because it's hyped, right? That certainly exists, but also like in reality doing it versus as what we see in

the enterprise is lots of interest, but very few that have actually put it in production yet. So, let me shift into actually the building phase and you know, we've got a few builders here and Will, I'm going to turn to you. You you've been turning pros into code from the perspective of um actually education and synthesizing things that we're seeing in the community and helping people with

examples. You wrote a great post um called hands-on with context graphs in Neo4j in January that sort of echoes back some live examples of you know, how to do this in Neo4j for members of the community here. Um [snorts] you've since launched uh just a couple um a site with 20 domain examples and I'm wondering if you could share your lessons from having experimented yourself hands-on in

the lab and then also from the dialogue that's resulted with the community. Yeah, well, I you know, I'm I'm a very I don't know hands-on practical learner I I I think and so I wanted to really demonstrate how do I actually you know, do something non-trivial with context graphs with maybe demo data, but but something just synthesize some of these ideas and and just demonstrate as a

practitioner as a developer, how do I get started? What is a What is a full-stack context graph look like, right? And and so that was the the post in January um was you know, largely a a look at What is a full a full-stack context graph application look like for a financial services agent? And then so it's a a demo application that's you know, let's say you're

uh an analyst at a financial services uh company, you have credit [clears throat] uh requests for approval coming in, you have customer service things coming in. How can you leverage some of the um institutional policies, the decisions in and in a graph to help the analyst um you know, you know, agentic setting make some of these decisions and I think that was a good one for me

just to understand, okay, here's here's the pieces of how we build up a context graph. Uh ideally we have data from different systems. This is the the requirements for how we stitch that data together, what what that looks like. And then um a lot of good feedback from folks in different industries. You know, we I said we built this demo for financial services. I had folks saying,

well, it'd be great if we had an example for car manufacturing or for you know, what whatever it is, right? Cuz obviously I think you're not going to um address all of the nuances that come up with the with these different use cases in one. And so that was the uh the idea for create context graph, which was the um the project that that Philip mentioned. Initially,

there's like 20-some domains, but but really the idea with a single command, can you create a full-stack context graph application uh with data, with an ontology that defines the the domain data, um how all these things fit together? Um and then also connect to real-world systems like Google Workspace, Linear, uh pull in your Google code or sorry, your cloud code sessions to look at where did these

discussions take place? How do we actually make decisions in an organization? Well, we do this by conversation, by discussion. And well, not all of these, you know, thoughts are encoded in in like work product, we have much of this discussion in comment thread in a Google Doc, in discussion in a Linear ticket. Um and so that's uh another piece of this create context graph tool uh is

really can we search through the history of those discussion threads, surface when how did a decision come to be and can we materialize that in the graph? So, that's kind of the the goal of of that project um that you mentioned. Like first, get started with some real-world data um and then also give me this enough full-stack application context. It was just a way to get started.

Lasan and Animesh, let me ask you, having built applications, what are some of the uh learning surprises, gotchas that you've experienced in the course of building what we're talking about? I think there are there's a couple of things and and it's kind of like two sides. One thing is kind of like the being the the context graph being in the decision point. Of course, you can definitely

use that for learning for next time you want to make a decision and record that. Um but also you have from security side, the governance side of the traceability kind of like why did this happen? And in the old days you kind of like, yeah, we are logging everything, but the logging is just event. They don't understand the context at all and it's too late and it's

afterwards. There's no feedback loop. There's no feedback loop um and there's no learning in it. That's kind of like coming in and looking for something that happened yesterday. Why bother? So, um so what we see is kind of like people are using this for both kind of like having agents to be better, decisions to be better, but also again back to the auditability, the governance, the traceability

of stuff uh is is core. And since kind of like AI teams are pulling information and data for so many different systems, how are you actually going to put that together to understanding the the full decision why did this this happen? And this is where context graph is definitely the best solution. Yeah, they they I actually second what was said just now. Like the the real challenge

uh with building a context graph is figuring out how to instrument the decisions. Um if you can do that, the rest of the the structure, the representation, the learning, all of these things follow. Um there's this question that I get often, which is like, you know, are context graphs an application layer or an infrastructure layer opportunity? And I think the reality is it's kind of both. Right?

And the application layer opportunity is like you have to find the right UX to be able to actually the place where the decision's actually happening. And I think agents kind of changed the UX in in some really, you know, positive ways so that way they can actually own decisions, right? For for us, for example, right? When a ticket is created, everything from the problem happened to where

do I look to who do I go to to you know, what does the solution actually look like? An agent can own instead of, you know, passing from support to engineering to QA and So, I think that's, you know, one one non-obvious sort of uh realization where you know, this is actually a little bit of a UX problem just as much as it is a a infrastructure

and and you know, continual learning problem. Um the second one is and I think this is going to be increasingly important as as agents kind of scale in the enterprise is governance. Mhm. Right? Agents and and I think we've kind of known this as we've started deploying agents more and more in enterprise like us as a as a community and um as as builders in AI. Um

but there's this realization that like, you know, agents are really good at figuring out how to solve problems. And in order to do it, they're able to, you know, fluidly navigate data. They're they're able to, you know, pull records from Salesforce and from Linear and from, you know, GitHub and codebases and there is no parallel for that as a as a human, right? In most of these

enterprises. For example, at a large bank, there's no single person that has access to the full kind of ticket history, the full the full codebase and all these different things. And so we say that an agent can do all this work, but it has to be governed, right? And so the access and kind of partitions of this context graph uh need to be governed in a way

that, you know, intuitively make sense to the kind of the governance models uh of these enterprises. Um and I think that's a a secondary, you know, challenge uh with building context graphs in the wild. Um but huge kind of uh potential um and and opportunity there. Those are those are some great tips and what I'm coming coming away with is there's a real mindset shift. It's almost

like you need to think about org design and process much much more than you do when you're writing software Yep. old you know, the old way. Yeah. Um because there's so much more capability and independence, but that independence comes with agentic interdependence, which needs some kind of supervision. Yep. Um I want to pull on one thread that you mentioned, which is local versus global. Like each agent

needs access to its own local view of the world in order to make a decision, but on the other hand, competitive differentiation for an enterprise ultimately comes down to how much can I use all the data across an entire um to my advantage because that is part of my unique advantage. Yep. Um and I'll open this up to anyone who has thoughts on it, but uh is

there a right way to think about a local context graph, a global context graph, some combination, do you need both? Who wants to go first? >> That's a hard question. That's a hard question, right? I I think the answer and I'd love to hear like it's going [clears throat] to be the lame it depends 100% where it is it it's going to be a spectrum and I'm

sure like you framed it as an enterprise thing, right? And so enterprise then my head goes to kind of brick-and-mortar type company that has been around for 100 plus years, grew up pre-software and you know, all that kind of stuff, right? There's no effing way in the next few years at least, my ability to predict 10 years out is just gone like in this universe. That they're

going to have single one massive instance spanning the entire thing. I That's just not how it works in those kind of Maybe you could see that is if it's a small startup. Yeah, I mean there's all this talk maybe a little bit less now but around like single founder billion dollar like a single founder unicorn. Not single single employee unicorn startup, right? Okay, maybe in that universe

you do have kind of one global one. But in any real non-trivial size organization, I just can't see that that happening. So that's my That's my take. I don't know what what you guys think. >> No, I completely agree. I mean I think I think this this question is invariably tied to what do context graphs do to org design and kind of like the shape of work

so to speak. You know, one thing that we've realized is that the the context graph for production engineering and when we use that word very you know precisely and and and intentionally because we think that production engineering for example is like a super set of you know SRE and support and QA and you know, there's a little bit of development and product work also mixed into that

and the reason for that is because the context graph for all of these things is shared. You can do better SRE or better support if you understand the intent of the developer and you can do better QA if you understand how things actually break in production. And this seems like very intuitively true in in hindsight but to your point, right? I think the the context graph is

domain specific and that's why we can centralize all of these things into into a central you know institutional memory. If we try to go and you know mix in sales information and you know you know, health information and you know, HR information all these things into like a single context graph, it just wouldn't work anymore. Right? There is no the the the leverage that you get from

actually sharing these things don't look the same. Um and so I I think this is invariably tied to you know, what is the future of work actually look like and which functions um that used to be separate can actually start being blended together because of the fact that we can actually centrally represent this context. Yeah, because I guess I could see or like just to devil's advocate

that then your point of view which is also my point of view but just to like >> I have the other would be like I could also see like the value over time if we had everything in some kind of connected thing, right? Like and we saw that like several years ago pre-AI where like there was like a really common pattern where we saw okay, I'm going

to start with graphs for supply supply chain analytics for example, right? To figure out like get visibility into my entire supply chain, root cause analysis, like what if scenarios, that Then over there on the far out on the other side of the house, someone else used it on the website for personalized recommendations, right? In completely separate silos and then over time what ended up happening was that

they found each other, realized there was both written graph, they connected them up. Now all of a sudden the recommendations only recommended stuff that they could actually ship through the supply chain. There's like a 1 + 1 = 3 kind of a we call it a use case network effect, maybe it's a data network effect, something like this. So I could see something like that kind of

dragging the context graphs, connecting them more together over time, right? But not in the next few years, right? Do you guys agree with that? Yeah, and I I also think kind of one of the things that kind of like attracted me to graphs in the beginning kind of like in 2011 or whatever Was the charismatic Swedish origin CEO talking about It was I have to give you

that. Don't think talk about the Olympics. Um anyway, the the the natural kind of like technology advantage of a graph is that you don't need to kind of like model the the whole world up front. And and that's a big thing if you go back to days when there was only human in in the loop. You can This is the organization you work in a sales department.

You are doing this. That was role. Like even that that time that was broken. What you can do with graphs, you can start kind of like very specific kind of like use case in supply chain or whatever and over time oh there's somebody else in the my ecosystem that partly also need some of this information and then that context and that makes it extremely flexible. This is

one of the things that I think make the graph data model and specifically like a schema optional schema flexible progressive schema kind of style implementation especially relevant and powerful in this age of AI I mean you don't know what your business is going to be from week one week to the next so you clearly don't know what your data is going to be from one week to

the next and so you need to be able to explore and add and subtract and being add things in like Emil mentioned data network effects uh gives you the advantage of being able to form your opinion over time and then of course the more new kinds of data you add in, all it takes is one relationship to connect two different data sets and each one becomes more

valuable and then you have this value in the in in the whole. Um one thing I heard in some of the responses to this question and some of the previous ones was um feedback loops and so in a way I'm I'm taking away it doesn't matter so much what your opinion is now of whether it's local or global. You're going to want to start with just solving

one problem, not boiling the ocean. Um and then from there you can say what are the feedback loops that inform bringing together multiple parts of data add value and add network effects and if it's completely distinct and there's no added value then I can separate it and then maybe over time I can refactor and edit it. Emil, you look like you were just Yeah, yeah, I was

going to say no I >> really well said. Everyone's jumping dying to jump in here. But I I wanted to pull on a on a on a related thread to what you just said because one of the things that you spoke about really well in that initial blog post following up after J and Asha's one was around ontologies and kind of your view on and I'll I'll

you know probably bastardize it here and you you >> you should you should play back the the real version but like some version of empirically discover bottom up the ontology or the schema, you know, the the metadata layer kind of of the universe, right? And then I hear you saying that in kind of create context graph you include 22 plus kind of ontologies which I think is

really powerful, right? Which represent more like the top-down thing and then maybe your approach that represents the bottom up. I would love to kind of see if we can reconcile those. Are they in conflict? Are they complementary? Right? So first of all, maybe Animesh, did I bastardize like >> Maybe you can speak to how you do it in in kind of player zero and then we can

kind of figure out what the Yeah, yeah, absolutely. I I I think I think like Phil, your point about you know, starting with a problem is basically the way that we've we've started as well. You know, first we're a startup and you know, we have to start somewhere and um you know, where we chose to start is thinking about kind of the unplanned work that shows up

in the player engineering teams. This is a support ticket. This is incident. This is a a problem happening in your software. And now different groups of people have to go and and deal with it. Now in the process of doing that, right? We have problem directed agents, right? Receive this incident, receive this ticket. And in the process of actually going and figuring out why this broke or

how this broke and what do I need to do next? Right? It's starting to stitch together these different systems of record. Maybe you have to go look at DataDog. Maybe you have to go look at the code base, you know, I have to go look at you know, past resolutions. I have to go look at you know, last time I I asked Emil, right? Why did we

deploy this service in this particular way? Right? And so there's And where did you deploy the service? I don't know. I still don't know. >> But there's there's agents are really good from like a problems like directed standpoint, right? To be able to take a problem and actually start stitching together context across all these all of these different places. And if we observe how are they actually

navigating that context? That's where we can actually start learning kind of this the structure of a existent but unobservable context graph, right? We're starting to kind of see the nodes in the graph and we're starting to see how they get related. And then from there, right? We have you know, more agents that are you made the code change and now let's simulate, you know, whether this thing

might actually break or not in the future, right? Running verification, running you know, review, running kind of intent based um you know, documentation and and all of these different things. And so you have agents that are actually reinforcing the graph from the other direction as well, right? About trying to take intent data and start moving it into you know, the central representation. And so the idea behind

player zero is that you know, we start with a wedge and a wedge that will actually you know, solve a problem for you right now and there's some fire in production. Let's go fix it quickly. And as we do more and more of that, we start learning how do we make decisions in our engineering team? You know, how do we you know, short circuit that next time,

right? Why did we build this in this way and what did we verify? Next time some sort of code change happens, we can actually go and you know, verify that these changes aren't going to reintroduce the problem that we saw in the past. And these are all you know, things that were that are ultimately being learned into this context graph. And this whole thing kind of accrues

and and and um it builds a flywheel, right? Um kind of into this context graph. So so so Emil, to your point, yeah, this is completely discovered. Right? Um there isn't like there isn't a single ontology that we go in and say, you know, this is exactly how you know, this enterprise is um you know, context graph should be looking. Here's what the relationships should look like.

It's very problem dependent. And because of it actually a lot of our representations in the context graph end up being represented you know, embedding space, right? So there's actually learn representations of you know, how different records across your entire system are actually related to one another. So it's it's it's very different and actually the way we talk about it is you know, a context graph that is

really well tuned becomes a world model. Yeah. Right? So the enterprise world model. An enterprise engineering world model, exactly. And when you say embeddings, I'm pretty sure everyone here is on this page, but you mean graph embeddings GNNs, not word embeddings. >> they're they're they're structural They're structural embeddings. So they don't always again the graph is not fully observable. It needs to be discovered. And so as

we keep doing more and more work, we're starting to understand the structure of you know, sub partitions of that graph. But the embeddings themselves are structural relative to you know, other nodes that are being discovered by the agent. Cool. So I want to hear Will is that in opposition to various >> is it complementary in some way? Yeah, the way I think about it, I think there's

a close overlap. It's not one-to-one, but there's a close overlap between agent memory and context graphs, right? And and with agent memory we have to think about short-term memory, long-term memory and then reasoning memory. So short-term memory this is like the the length of a conversation. Long-term memory these are like entities that we've extracted out of of the conversation and and how they relate. And then reasoning

memory, this is like procedural memory. This is the how agents plan during the reasoning phase, what tool calls they make, the result of those tool calls and and this I think the reasoning memory is an important part of the context graph piece in that it's understanding >> [snorts] >> what did we do last time and did that result in a good outcome and and making those traces

available to the agent during the next reasoning phase, right? That's an important piece. I think that on the question of ontologies and and data structures ahead of time because we're talking about unstructured data. We're working with with agents. There's a lot of text data conversations, documents, emails, that sort of thing. anytime that we're working with unstructured data and generating a knowledge graph, the success of that project

from from what we've seen is largely dependent on the quality of extracting those entities, doing the entity resolution, going from unstructured data to your your knowledge graph. And by applying a data model an ontology that maps to your business domain, you are able to increase the likelihood of success because now your knowledge graph is more closely mapped to the data that you care about, right? If you

And you're talking about like SKUs, customer names, things that are well-known terms in the business that you can apply to your graph extraction. And that's exactly in in create context graph that we're talking about. That's exactly what the ontology is. It's just the the data model, the domain that is relevant for healthcare versus financial services versus manufacturing. And so as we're going through the the entity extraction

resolution pipeline, we're doing that with that data model, with that ontology in mind so that we're extracting information about yeah, drug discovery and drug protein gene interactions. And if if we're manufacturing cars, we're extracting information relevant for that process, right? So that that's where where I think the power of the ontology comes in is during that you know, informed construction of the knowledge graph phase, which I

think is an important component, like just one component of the context graph, not not not just the only piece, of course. >> And these can come from existing systems or they can come from standard industry ontologies which you have in healthcare and finance and so on. Cool. I'm going to shift gears and Emil, question for you. So >> dying to talk about ontologies. >> Well, let me

just kind of my my my final view on on on on this So for those of you who have been with Neo4j for a while, this is the Nodes AI community. So we have several people here like listening in. They've been using Neo4j probably for 5 years, 10 years, maybe 15 years, right? We in many ways in the graph world represented kind of the bottom-up approach, right?

Where it's like okay, in the world there's you know, um alternative way of expressing graphs called RDF, then you tended to start with an ontology, right? It was more top-down. It was more kind of upfront work. And we said, you know what? Schema-free is really powerful. And I always had the perspective as you well know of schema-optional. That's the thing. Like so you can start in a

schema-free way and over time you add more kind of schema-rich constructs, >> So that that was always kind of the the point of view. Where I sit today now that we see basically two things change. One is Neo4j being more frequently used by multiple applications at the same time. Like a single Neo4j instance is same time. That's one thing. The other thing is what Will spoke to,

which is importing unstructured data and trying to create a knowledge graph out of it. Both of those are real drivers of having a better understanding of the schema or the metadata model or the ontology for for that that domain. And so it's actually an area that we're going to invest a ton more in the product over the next couple of quarters and you're going to see several

exciting releases from us over the next yeah, just few months in this area actually. And so I actually think it is one of those best of both worlds. You want to be able to do it completely bottom-up and discover it and completely build it in that way, but being able to marry that with a top-down view when appropriate, I think that combination is is really powerful. Hard

to implement and do well. The kernel team, the database kernel team is kicking us, right? Cuz it'd be so much easier if you do choose one. But having said that, if we can pull it off in a good way, that I think is the best of both worlds in this in this And and I'll actually put in a plug for create schema, which is in early access

currently, which for the for the first time lets you define a schema and associate various kinds of constraints with it. So encourage the audience to play with that. I'd like to talk about startups more broadly and for those of you who have others who have startups who are listening, Neo4j launched a startup program last September for AI startups, which I guess is probably most startups if not

all these days. Um and in the you know, 6 months or so that that program has existed, we've now enrolled more than 600 startups into it. And now September was prior to the blog that called out context graphs, but of um I see that much in the same way as when we came up with the term graph rag or actually adopted the term Microsoft I I credit

for popularizing it. That this was a pattern that was already happening. And Emil, I'm curious from insights about how startups are using Neo4j, how much of that is driven by context graphs and if not, what else is driving it? Yeah. So I think at a high level there's a huge amount of overlap between graphs and AI up and down the stack, right? And like the the rag

version of that is graph rag, like to your point. As you mentioned, I think in agentic memory there's a lot of people, not even Neo4j people, right? Like outside of the graph world who independently conclude that like graph is a great substrate for agentic memory, right? You can look at kind of agentic planning as a graph of very small graphs, right? From our perspective, but still, right?

So like there seems to be like this overlap between graphs and AI up and down the stack broadly speaking. Specifically context graphs, like prior to your blog posts, that term didn't even exist or maybe people used those words together, but certainly not with the more precise definition around decision traces. We saw that earlier happening. One one of the first use cases that I saw was like a

massive tech platform that has a digital twin of all of their infrastructure, millions of consumer accounts and all of their digital resources like their object storage and their like whatever virtual machines and like all that kind of stuff, right? And how it all fit together. And then they layered initially human agents on top of it and then actually like AI agents on on top of that. And

they built out this agentic brain which had a memory piece, it had decision traces and an audit log. And it's like okay, that's cool. And that was like I don't know, a year ago or something like this, right? Um so certainly people have been doing that. It's hard to peg numbers on it, right? But I think there's a lot of hype around context graphs right now. So

there's a lot of people who frame it that that way and I think that's a a generally positive thing. And much more inside of startups again like we mentioned compared to in in in the enterprises where it's much more exploratory today. Spitting great discussion. I'm going to start to move this towards a close and I'm going to ask each of you two questions. One is from all

the things that you've said, is there any advice that you'd offer to the audience someone trying to get started. And then, just for fun because it's impossible to predict what's happening just a few weeks out. We started with context graphs as a trillion-dollar opportunity, which implies like there's going to be a lot that's going to happen, you know, from now until the point that we realize that.

So, where will we be in a few years with context graphs? Where do you see this going? Animesh, let me start with you. All right, that's heavy questions. >> Um So, I I I I think for the advice, you know, just to kind of keep it uh context graph specific, I think it would start with the real problem. Right? I think there's um there's always this instinct

to, you know, start with the context graph and then see what can happen. And it's that's a that's a hammer looking for a nail. Data first. Yeah, exactly. And and I I I think it's really important to actually start with a problem because that actually gives you the best possible wedge start the flywheel. Right? To start the kind of the the the reinforcement process. the trillion-dollar opportunity,

um I think it's about as real as it gets. Like, it's it's a huge huge opportunity. Context graphs represent uh a form of kind of externalized learning. Right? Continual learning I think is like another huge topic right now in in the AI community. Context graphs represent a way to externalize so that way you can knowledge work in really complex environments and agents can truly own the outcome.

Right? I don't think that that opportunity uh particularly existed in as palpable a fashion um as it does right now. Um and so, you know, I think context graphs represent, you know, one big step uh towards achieving it. I think in a couple of years, and probably even sooner, uh we're going to see see agents start earning an increasing amount of authority um in the enterprise in

complex environments uh to actually own and make decisions. And I think context graphs represent the way to get there. Love it. Lessa? Yeah, I I really like all what what you said in the beginning here of conflict just have a real problem and get started. And then you you learning kind of like on on your way by doing that. And the good thing is with agents is

uh there's no politics. There's no humans in the room. >> So, so that [clears throat] I like that really helps in in a good way. What I what I see also kind of like what is is doing now is also to kind of like from agent to agent communications, kind of like understanding the um the intent. Mhm. Both from kind of like security perspective, kind of like

what are you trying to do here? I'm kind of like be ahead of of the game making decision. Um but also kind of like, okay, this person was actually kind of coming in with this agent trying to book a airline ticket and then you go over to a payment kind of like agent. So, understanding the intent of what actually started the workflow is going to be very

interesting. I from a trillion-dollar kind of like um thing, I I just call Emil and he will tell me. No, um I've never met met an enterprise that says, "I have too little data." So, the whole thing is actually how do you operationalize all that assets, all that information you have, and also what your ecosystem have, and what is publicly available. So, I think unlocking all that

value and operationalize it is is the big winner in this thing. Mhm. Great. For me, so I I guess on the the first question, which was you know, kind of an advice and and things on getting started, I you know, I just echo the the idea of just just dive in and and just try to to build something. Um but but specifically, when you do uh share

your feedback with us uh so that we can can, you know, make that uh improvement loop and and improve some of the the tooling around uh working with context graphs and and Neo4j. Um you know, forward-looking and kind of question like what what is context graphs going to be like in you know, a few years from now, I I don't know, but I I think that we're

certainly going to more access to data. Um just like we we saw that like, you know, our personal data and there's value in in data and getting access to that and building businesses on on top of that um a while ago. Perhaps we will see something similar for the more exhaustive uh work product, more exhaustive of that data. Is there value then in the decisions you're making

and and in in the metadata and how do you get access to that? I think that'll be a big piece of the next challenge for for folks to solve. Emil. Yeah, look, the predicting a few years out in this crazy world that I find it impossible to predict a few weeks out, a few days out, right? With everything going on in this in this But it it's

it seems very likely that the core concepts behind context graphs, whether they're going to be called that 5 years from now or not, who knows, but that that is going to be a key component of making agents actually work in reality. Just think about if we're in this broader shift of taking decision-making that were in like wet wearing human in by human brains, right? And shifting that

into kind of software and AI wearing into more agents. Right? Just think about when we all started working at some place, like how much was actually how does things actually happen at this place, right? And out of how how much like out of all that how do things happen at this place, how much of that is encoded in some policy handbook? I don't know, 5%? 10%? Right?

Like, you're a Neo4j boomerang, you were at Neo4j for many years, and then you wandered out into the wild. Then you came back to papa again. >> Right? And when you came back to Neo4j, somethings had changed. How much of that was encoded in some guidebook? Probably none of it or It was all very well documented. >> Yeah, exactly, right? And so, that to me is what

we're trying to do here with the context graph. Like, encoding that institutional memory. And this goes to show like it to tell that that seems very likely to be an important source for for those agents to be actually to able to operate in in in the real world. So, the opportunity feels like more real than than anything ever, right? On the practical advice, I would just say

I think uh Jay and Ashu who who aren't who aren't here, their blog post, your follow-up blog post were an amazing, very eloquent articulation of the value of this. We will definitely link link to them. And then, Google this guy's name, Will Lyon, Lyon with a Y. Like, so much of the getting started stuff that's out there around context graphs that that Will has written is just

amazing. Including this create context graph thing, which is just even I it's it's as it's so easy that even a CEO can get started with [laughter] with it. Right? So, that would be my like my final advice for for people, right? To to to pick it up and start building. Cool. So, start with a purpose, just build it, understand agent intent, and read Will's stuff. Yes. Yeah.

>> Good summary. Good summary. Yeah. Excellent. Cool. I've enjoyed this. Uh thanks for the conversation, and I'll >> say a few last words to our audience the journey they're about to embark on along the three tracks and 40 talks and uh a day of Nodes AI. Yeah, I mean, it's it's back to what I just said. What I love about this community, it's a it's a very

engaged and enthusiastic community of builders, people who actually do stuff, right? And that has been true for all the Nodes that we've done now for six, seven, eight eight years. So, dive in. There's lots of amazing sessions going going on. Dive in, watch, but don't forget to build. Thank you. Thanks, all. Nice thing. Thank you. Have a good day. Thank you. >> [music]