NODES AI 2026 Opening Keynote: Exploring Context Graphs: From Data to Decisions

This talk focuses on context graphs and their importance in the realm of AI, specifically how they facilitate decision-making processes in enterprises. The speaker discusses decision traces, which capture the nuances behind recorded outcomes within systems of record, emphasizing their role as institutional memory. Different panel members contribute their insights on context graphs from their respective companies, showcasing various applications, such as decision engines and trust scoring through quality data assessment. The discussion highlights the shift in understanding and implementing context graphs in organizations, the necessity for governance in agent-driven environments, and the interplay between bottom-up and top-down approaches in building knowledge graphs. Overall, the session underscores the evolution and growing adoption of context graphs within AI frameworks.

[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 Cortana. I'm the founder and CEO of Player Zero. 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 Andres Loven, I'm founder and CEO of Indykite, kind of like the

application infrastructure for AI. Specifically trying to build the 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 [clears throat] 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. Why do you think it hit the nerve? What nerve did it hit? And what's the real opportunity here? So, on 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 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 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 Player Zero's case, right? We should, you know, look at this service instead of that one, right? And so, these ends up because 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, so let me shift to you. You've built various [clears throat] technologies around graphs um uh previously at FourGraph 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. >> [snorts] >> 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 and the whole context graph actually becomes a decision engine. And >> [clears throat] >> and understanding the the context is core. And I also think from a learning perspective kind of like keeping track of all these decisions actually going to make the next agent or the next behavior or next action much much better. So, we kind of like been building everything

based on a context graph out of the get-go. The flexibility, the kind of like the value it actually gives us, it just kind of like super. Then we integrated that also with the core identity systems kind 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, that agent, 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 all 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. 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 that has a lot to figure out 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 this actually proved? There's just 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? What how did it get into the system? The age and a lot 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. Should the audience interpret this as a signal whether they're an enterprise or a startup or a startup selling to the enterprise? I think it is very telling that, you know, we we Philip and I were presenting at to a senior executive 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. And 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. Will, I'm going to turn to 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. The post in January was, you know, largely a look at what is a full stack stack context graph application look like for a financial services agent? And and 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 uh requests for approval coming

in, you have customer service things coming in. How 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, be great if we had an example for car manufacturing or for you know, what whatever it

is, right? Initially, there's like 20-some domains, but but really the idea is with a single command, can you create a full stack context graph application 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, you do this by conversation, by discussion. And while 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 in a full-stack application context. So it's just

a way to get started. Listen, 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 are actually a couple of things. And and it's kind of like two sides. One thing is kind of being the the context graph being the decision point. Of course,

you can definitely [clears throat] 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 it's 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, uh and there's no learning in any of that. It's kind of like coming in and looking for something that happened yesterday. What why bother? So uh 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 agents 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 a context graph is definitely the best solution. Yeah, the the is 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 change 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 and and so on. 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 the enterprise,

like us as a as 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 it is 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 of these enterprises. Um and I think that's 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. One of the things that you spoke

about really well in that initial blog post following up after J on our shows 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 you should you should play back the the real version, but like some version of empirically discover bottom up the ontology or the schema, uh you know, the the metadata layer kind

of of the universe, right? And then I hear you saying that uh 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 No, I think I I think >> 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 I I I I think I think like Philip, your your point about, you know, starting with a problem um 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 plate of engineering teams. This is a support ticket, this is uh 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 past resolutions. 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 >> did you deploy that? I don't know. I still don't know. [laughter] But there's there's agents are really good from like a problem's like directed standpoint, right? To be able to take a problem and actually start stitching together context across all of

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've 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 that is 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. Um and because of it, actually, a lot our representations in the context graph end up being represented in, you know, embedding space, right? So, there's actually learned representations of, you know, how different records, um, across your entire system are actually related to one another. Um, so, it's it's it's very different.

And actually, the the way we talk about it is, you know, a context graph that is really well-tuned becomes a world model. Yeah. Right? Um, so, An enterprise world model. An enterprise engineering world model, exactly. And when you say embeddings, I'm pretty sure everyone who is on this page, but you mean graph embeddings, GNNs, not Not always. uh, word embeddings. Not always. Also, they're they're they're they're

structural embeddings. Yeah, that's right. Um, they're structural embeddings. So, uh, they don't always, again, the 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, uh, that are being discovered by the

agent. Cool. So, I want to hear, Will, is that in opposition to Very curious, yeah. >> You you or you or is it complementary in some way? Yeah, the way I think about it, I think there's a close overlap. It 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 often 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, uh, like like procedural memory. This is the, you know, how, um, 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 what did we do last time, and did that result in a good outcome, and and making, uh, those traces available, um, to the agent during the next reasoning phase, right? That that's an important piece. I think that on the question of of ontologies and and

data structures that ahead of time, because we're talking about unstructured data, we're working with, uh, with agents, there's a lot of text data, like conversations, uh, documents, emails, this 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, uh, a data model an ontology that maps to your business domain, you are able to, increase the likelihood of of success, because now your your knowledge graph is more closely mapped to the data that you care about, right? >> 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, uh, with that data model, with that ontology in mind, so that we're

extracting, uh, information about, uh, 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 I think is an important component, like just one component of the context graph. 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 that have 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, this this other, uh, 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 the point of view. Where I sit today, now that we see basically two things change. One is Neo4j is being more frequently used by multiple applications at the same time. Like a single Neo4j instance is used by multiple applications at the 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 did 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 uh, in early access currently, which for 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. Thank you. Thanks, all. Amazing. Thank you. Have a good day. >> [music]