NODES AI 2026 - The AI Agent Memory Landscape

This talk delves into the relationship between context graphs and agent memory, emphasizing the importance of extracting entities and their relationships from unstructured data. The speaker discusses the Neo Forj agent memory Python package, which categorizes agent memory into short-term, long-term, and reasoning memory, allowing for sophisticated interactions in various contexts such as financial services. A detailed look is provided on how to create a context graph application, highlighting the integration capabilities with different agent frameworks and the use of an interactive scaffold tool. The session explores the multi-agent memory concept, showcasing how various agents can share a memory layer for collaborative decision-making. Additionally, the importance of ensuring compatibility among agents through technology compliance is underscored.

Great. Thanks a lot. Hey everyone, thanks for joining today. Hope uh Nodes AI has been been a good event for folks uh so far that are watching live. And if you're catching the recording uh welcome to you as well. You can find my slides uh either by scanning that QR code or the the URL down in the bottom left graph.com/nodesai2026. I'll put that in the chat too

and um we we'll share that again at the end too. Uh but it might be some useful resources to to check out some of the slides. Um I want to pick up kind of right where you know we left off in the um session earlier this morning in the panel discussion in the keynote. I want to pick up some of the the topics there that we touched

on and and maybe drill in a little bit um specifically around context graphs, agent memory on ontologies, these sorts of things. So, I'm going to jump uh jump right in. And the first thing I want to talk about and and this came up in the in the panel discussion uh is this relationship between context graphs and agent memory. And so, you know, I said earlier today that

there's this this close relationship. I don't think it's quite onetoone but I think there's a very close relationship between context graphs um and and we'll we'll go through a refresher on on context graphs and in a second but there's been a lot of discussion around context graphs today but context graphs and agent memory with with memory we're typically thinking about some text representation some uh expression of

a preference or something that happened. Um, but you know this typically like file or vector like textbased um is how uh often times we're initially implementing uh some of these things. But with something like uh like a context graph or graphbased memory, we're actually extracting out the entities. So what are the what are the things mentioned in the conversation and identifying the relationships? uh between them. I

think that's one of the the most important uh you know first things that we need to think about when we're working with graphs uh with with agent memories. How do we uh identify the entities? How do we go from unstructured data to identifying like what are the the things like right like the entities are the things that exist events these are things that have happened and then

context in in the context graph terminology the the decision traces. This is the the why, right? These are the policies that were applied, the risk factors, the reasoning that was applied either by um a human employee or or by an agent applying some policy. But we need some uh some insight into the decision that was applied. And um I wrote a blog post a few months ago

and and showed this this demo application. that's probably um still up and running, but basically a context graph for a financial services organization. Um you know, we can do things like ask for uh credit approval decisions or responding to customer support questions as they uh as they come in. And really the the architecture for this is we give the agent tools. So we give them some uh

functionality, some way to interact with and understand their environment by querying, updating the context graph uh and finding the most relevant decisions uh applying those policies, generating a recommendation is a core part of what that agent um is doing. Graph data science is an important component of this. Uh we can use the structure of the graph through uh through node embeddings. We can use things like community

detection to help us find and and service the most recent or the most relevant uh context and and decision for any step uh that we are in uh in sort of our uh agent interaction. And this is largely based on the Neoraj agent memory Python package which exposes short-term long-term and reasoning memory. So there's an important observation that context graphs need three types of memory. Um when

we're talking about agent memory um often times we're thinking about preferences or u we're thinking about conversations but reasoning the decision traces these are also an important part of agent memory. Sometimes this is called procedural memory or experiential memory uh things like that. But these are all abstractions that are baked into the Neo Forj agent memory package um which we can install uh through pip and integrates

with pretty much any Pythonbased uh agent framework uh and has lots of configurable functionality for things like entity extraction and working with graph data science. Now I mentioned these these three types of agent memory short-term long-term and reasoning memory. Uh short-term memory we can think of as conversations, right? Conversation history, session state. Uh this is really though an entry point into entity extraction, right? So uh we're

talking about conversational so unstructured data uh conversations with an agent. And in that uh in that text unstructured data, we're going to be mentioning things, right? we're going to be mentioning customers or uh products, accounts, we need to go through this entity extraction and entity resolution phase to understand what what is the actual thing that uh that we're talking about and applying just an LLM only approach

to entity extraction and entity resolution can be quite uh slow and and quite expensive. And so as part of the Nej agent memory package, we've built this uh multi-stage sort of entity extraction pipeline that is able to use uh named entity resolution like like statistical NLP methods as well as smaller local models like the the gler fine-tune models for entity extraction that can run on CPU um

to run locally for free essentially with fallback to LLM for more complex uh extraction and resolution. Now, the data model that we apply during entity extraction and resolution is really important. And that data model, I think, is going to depend on the domain uh that we're working with. Right now, by default, Nefj agent memory uses the pole plus O entity model. This is a a common model

that's used in investigations, right? So, person, organization, location, event, object. Um, this this I think of as kind of the the starting point. Um, but as you're going through and implementing your own agent memory, I would really encourage you to extend the the base data model, the base ontology, uh, that's used, and we'll see how to do that, uh, in a moment here. reasoning memory. This is

the the third type of memory uh that we mentioned that's supported by the Nej agent memory package. And this is really all about understanding that why, right? The the missing piece, the explanation of uh what execution plan did the agent make? Why was the decision made? What are the decision traces? What are the uh what can we observe from uh the agent's reasoning phase? Those sorts of

things are captured in uh reasoning memory and altogether um these are the the main abstractions for working with memory in the nearfj agent memory package altogether short-term memory long-term memory reasoning memory these together make up your context graph and they're they're all related right so so messages uh these can trigger a a reasoning trace they can trigger like the reasoning phase for the agent. Um, we extract

specific entities from specific messages. Messages trigger a tool called the these sorts of things. We've been working a lot with the different framework uh and agent uh cloud orchestration vendors. Um, and so we we've spent a lot of work making sure that near agent memory integrates well with Google ADK, uh, with AWS, Microsoft Agent Framework. Um, and so you'll see some specific examples and and specific integrations

with some of those, uh, those tools as well. But there's still a bit of a a challenge that I saw after we um after we released this and and it was great to see folks adopting um especially some of the more uh sophisticated agent memory integrations um that are out there but I I think there's still a bit of an overhead in surfacing some of this data

like how do I actually surface the decisions that have been made in the organization? How do I actually get that data uh into the graph? How do I expose that as a tool for my agent to make sense of? And so to to help smooth that process a bit, we created the create context graph project. Um create context graph. This is inspired by the create react app

project which which was for a while kind of the default way of creating a react application. Go through this interactive scaffold and choose uh sort of what what domain are you working with? Do you want to import real data? Do you want sample data? just to get started. Uh that's kind of the the basic idea. Um and let's take a look at at what this looks like.

So if I run uvx create context graph, uh it'll take me through this interactive workflow. Let's say uh I'm going to create a science graph project. So we can uh suck in SAS data or generate demo data. Let's do demo data for scientific research. And we can choose which agent framework we want. Uh let's go with cloud code. And I'm going to use an existing Neo forj

instance. We can also connect to nearjura instance or uh use docker. But I have an instance running locally let's see localhost. There we go. And we're going to skip the kind of optional enhancements and and add-ons here. And here I'm being asked to add um an anthropic API key. And and these are optional for my agent. I I can use whatever model um I want. By default,

we'll use um anthropic sonnet model and OpenAI So we've now uh provisioned out kind of this full stack context graph application. I'm just installing some dependencies. This step here to download um the spacey model. This is probably the uh the longest step of of what we're going to uh see here. But if we go to the uh the docs here, this is the create context graph um

page which has um documentation. There's good um tutorials here. We're basically following through this your first uh context graph app. Uh but okay, now we're installing uh the uh front-end dependencies and so the front end is a uh Nex.js application. Um and so we saw earlier we had our choice of backend framework, right? And and so we chose I think the cloud uh cloud agent SDK. We

could have chosen any of the the Python models supported by uh supported by uh near agent memory. Okay, cool. And so then the next step is to uh seed our database. So we'll run the make seed and this is going to just load some sample data uh in my database. And then finally we can run make start and this is going to run uh the back end

and the front-end application. So now if we go to localhost 3000 and zoom in a bit we should see this is our full stack uh scientific research context graph. So the first thing we see is the data model. Um but we can ask some uh questions here something like um show me the citation network around deep learning in drug discovery. And we can see what our uh

our agent has access to a number of tools and it's going to choose which tools to execute uh to try to answer uh this question right. uh and initially it's found um a paper here. We can explore uh the paper and the uh the citation network around that to bring in uh more data and that's essentially what our our agent is doing here. Um sort of doing

text decipher to bring in more data to answer um our question. Now what data did we actually bring in like this? This is sample data. We we we see like documents. I have kind of decision traces here. Um I have like like science papers. I have like researchers that are affiliated. And you can see like this this data matches uh the domain that I chose and was

all generated uh by piping work documentation. Right? So, uh, in in this case, we're working with science papers, meeting notes, uh, from, uh, organizations that are allocating, uh, grants, the these sorts of things. We're, uh, taking documents that represent that sort of work product and running that through the NEFJ agent memory entity extraction pipeline to construct uh, this context graph. So that is one way to get

started uh with context graphs and the Nej agent memory um package that that's using sample data right and and that that's helpful for for demos but h how do we surface like the these realw world decisions that occurred um and for that we can use the uh SAS connector data in currently there support for um GitHub linear, Google workspace, uh cloud code, there may be a few

others um that we've added in there, but the basic idea is we can um include a connector um or you saw when we're going through the interactive flow uh we were being um asked if we wanted demo data or uh to connect to SAS to to a SAS service to pull in um real data. And so for cloud code for example um the connector works by parsing

uh the JSONL session files that we have uh locally on our machine uh and we'll parse those into a context graph and look at like what are the uh what are what is the like graph structure of our sessions that we've had with cloud code. Right? So cloud code is a a coding agent. I interact with it by you know sort of sending messages that can either

be um you know feedback on a plan or uh maybe a PRD but it it's somehow related to some project that I'm working on. I'm going to be calling tools uh to update a file. Right. Right. Like the these sorts of of interactions. Now, an important component though of of context graphs is surfacing the decision trace, right? Like what were the decisions that were made either by

a human or or by an agent and materializing those surfacing those from uh from our work product. And here's an example in the cloud code connector for create context graph. We do this using some heruristics. Um and so essentially we're looking for the case where there was some user correction um or maybe user chose to change dependency uh or there was some error. How did we resolve

the error? Um we were presented with an alternative uh that was like a clear decision that the the human had to make based on you know maybe an architecture decision these sorts of things. Now what's really important is when we're able to combine these data sources and query across them. So here we're adding the Google Workspace and the linear uh connector. And so we can combine projects

that we found in cloud code with uh linear work items and maybe PRDS that we found in Google Workspace for example. So here's just another look at some of the heristics we use for the um the decision extraction um and some examples right where I'm I'm using explicit statements right always use uh single quotes for example right they're those are easy to um to sort of have

reg x reg x's that are trying to identify um those sorts of explicit statements behavioral patterns are uh are more interesting and and tricky to identify. Cool. So, this is my second demo that I wanted to show. Um, but maybe I'll I'll skip sort of this process since we're um have limited time here. Uh, we'll skip the import process, but I'll show you a bit of what

this looks like. Uh, so I pointed this at my uh Aura instance. Zoom in a little bit here. And we can see here uh if we start by querying uh for projects. See I have 16 projects. Um this is grouse flocks. Oh, this was a uh this was an experiment on um adding some new visualization styling um using the uh the NVL uh the NVL visualization uh

package. And so anyway, we can see the the message the messages that were sent the the tool calls that were made. Here's a tool name uh edit, which is essentially, you know, editing um a file. always see the file that was updated and and um so on. Uh and we have the same full stack like like front end piece that we can use to interact with that

uh as well as part of Cool. So the third piece that I want to talk about here is this idea of multi- aent memory. So I I I think it's you know somewhat intuitive when we're interacting with a single maybe maybe a a coding agent using the cloud code example. Um these are the preferences that I personally care about and and we can extract that and and

maybe a markdown file for saving that you know locally is is fine. But the case where we have you know hundreds or thousands of agents that are collaboratively working together uh how can we enable memory uh and specifically the context graph the um that we're using with new agent memory how can that be a shared coordination layer uh for our like swarm of agents essentially right like

databases were created to solve this coordination problem there there a lot of advantages that we can have there as we're leveraging that um that graph database as our context graph memory layer. Um let's look at another example. Um so here we have uh kind of an agent swarm again in the financial services domain. Uh we have in this case a series of agents that uh are all

implemented in the same agent framework. So they're all implemented in AWS strands. They share a uh memory layer, but they all have a somewhat different persona, right? So, we have a know your customer agent, an anti-moneyaundering agent, a compliance agent. They all have somewhat different uh personas, somewhat different outcomes, somewhat different goals, but they have that shared memory layer still um because they're all using agent memory.

they all have this the same conventions, the same data models that they're using, the same contract essentially um with the database for the shape of their memory. And so uh a typical workflow might be something like this where uh the know your customer agent is you know ingesting new customer data going through this entity extraction. Maybe it has some uh process for flagging uh suspicious transactions. Uh

and this can happen just in the memory layer. So in in the the memory layer the the KYC agent you know maybe flags that oh this is a suspicious relationship that's immediately available for say the credit agent to pick up on because that is in the uh shared memory layer. Now this example I think this this makes sense to us and and we said okay these are

all written using the same uh agent framework the same like newj agent memory uh integration for strands is kind of how these were implemented but what if we had you know a system where we had many different agents implemented in many different languages or uh you know different frameworks we have different um you know different teams throughout our organization that are all working on um you know

different pieces of technology. Having a shared memory layer uh that all of our agents conform to the same conventions uh means that our memory layer can then be the layer of coordination for our agents. But we need some way to certify that uh those agents are all using uh the same conventions that the memory layer that they're using is compatible. Uh, and this is where uh technology

compliance kit testing comes in. Um, and so this I think is something we're going to be uh working on in our our agent memory tooling quite a bit going forward is being able to certify uh that different agent memory implementations adhere to the same conventions. They have the same shape and behavior of agent memory uh in the graph. And when when we do that, we're able to

share uh this agent memory layer as a coordination layer. Um and so we've begun some initial work there. There's a link here to the agent memory uh TCK repo which has um the specification and and some of the um conventions that we're using in the NearFJ agent memory tooling. This this is by no means uh done and comprehensive. just sort of a first stab I think at

what this looks like. Um, and there's an example application in there of uh I think we have six agents written in in different languages from Python, TypeScript, Go, C um multiple versions, multiple um Python frameworks. Um, and then also just earlier today I got the the R uh version working. So if anyone is is interested in um Rlang and and agent memory for R, we can now

have sort of a agent memory client um in that. So anyway, that I think is just kind of the the vision that I want to set out um for going forward in the future is you imagine we have uh all of these agents in different languages, different frameworks, all uh working together contributing to learning from uh the same shared memory layer. Cool. Well, I think we're we're

about out of time. Um, but I'll I want to leave some resources up and then we'll we'll go through some questions uh if we have time for them. Here's some some links to some of the things I talked about. Um, Graph Academy is always a a good place to start. There's a new Graph Academy context graph course. Um, take a look at that. the create context graph

project. That is the command line tool used to scaffold up your your context graph application which is built on top of the Neoraj agent memory uh package. So those are some resources um I would encourage folks to check out. Um I want to leave you with I think what was my favorite paper uh from last year. This came out just the end of last year and this

was kind of a survey of memory in the age of AI agents. And I think it does a really good job of presenting a few different ways to to slice up the memory landscape based on sort of like the the form function or or dynamics of the memory system. Um and so I'd encourage folks to to check this out. We I talked about some of the the

aspects but just maybe not through the same lens. Um, so I I would encourage you to check this paper out um as a good way to uh to sort of have a different lens on uh the memory landscape piece. And I see a few folks asking for the slides. Yes, the slides. I usually have a link at the end. I forgot that. But if we zoom all

the way to the beginning, uh we have yes, the slides here. So the link is I can write that in graph stuff.com. Nodes AAI. There we go. I think I typed that right. We'll see. Cool. So we have just a a few minutes left. Um not sure if we have time to take questions here. Let's see. I'll just scroll through the chat. Maybe take one or two.

Uh let's see. So I see a few a few folks asking about the um like the difference between the industry domains in in create context graph and like the the connector data. So yeah, maybe that's a that's good um a good shout there. So the idea with create context graph is really to be able to get started with this this full text graph uh application. Um and

so really the idea is choosing a domain and an agent framework. Um and then if you want to work with sample data or if you want to actually connect your own um SAS service like linear GitHub uh and uh if you do that we'll actually try to identify uh some of the decisions that were made in your in your work documents um through that that process that

I talked about. Cool. And so I see we have um one minute left. So maybe we will pause there because I think we're going to head into the next session soon.