NODES AI 2026 - Temporal Substrate Architecture: Building Persistent Identity for Autonomous Agents

This talk focuses on the concept of temporal substrate architecture, which aims to enhance large language models by integrating a sense of time into their functioning. The speaker discusses the challenges enterprises face when interacting with AI conversational agents like Claude and ChatGPT, particularly the difficulty of maintaining contextual awareness of prior conversations. The talk emphasizes the necessity for these models to access and understand historical interactions to provide coherent outputs relevant to ongoing projects. The speaker introduces a model that utilizes knowledge graphs and a two-layer structure to track temporal experiences, facilitating better knowledge transfer within organizations. The architecture aims to improve AI’s utility in enterprise IT by ensuring that the model captures and learns from evolving user experiences and maintains the chronology of events, allowing it to generate meaningful insights and solutions. The ultimate goal is to provide a framework that enables organizations to leverage AI effectively without losing the essence of historical context.

[music] >> Welcome everybody. Today, we're going to be talking about temporal substrate architecture. As the introduction mentioned, but ultimately what this really amounts to is time, right? How do we give large language models an experience of time that matches and aligns with our own? This is a challenge that I'm sure everybody's had. They walk into a chat with Claude or with, you know, ChatGPT or with maybe

the Gemini models, and everything that they've asked them before is no longer a part of that experience, right? Um the more of those experiences you build, more of those chats that you accumulate over time, the more challenging it becomes to bring everything back together when you have a new chat and you need all the pieces that you've had in the time stream that occurred before that current

moment, yeah? So, to put everybody in the frame of mind, if anybody's seen this particular film, this is the experience. So, every time you talk to Claude, that's the one that I tend to use, or ChatGPT, I use that one as well sometimes, one of the issues that we have is, particularly in the enterprise, when I ask it about something that I used to know, something that

we used to do, something that we built yesterday or the week before, how did that thing evolve over time, If you have to constantly pull bits and pieces of previous conversations, or if you have a running tally of all the notes that you've had where you have to constantly cut and paste and update those, that becomes not just tedious, but a mental block eventually because what you

have to do is constantly remember in your own mind, how do I keep all of these pieces together and organized? Because when you present them to that next session, where the model knows nothing about every previous session, you have to not just take what you knew, what you learned, and what you experienced, and put them into that chat. You have to order them temporally, so the model

understands what came before what, why this resolves into this, and how these things connect together to compose a PowerPoint presentation that you're going to provide to the senior management team, um a new design spec that you're going to provide to the engineering team. All of those things need to align, so that when the model produces something that you can hand over as a work product, the people

that are looking at that work product go, yes, I understand why this design is the way it is, right? And everything aligns temporally, because if it doesn't, the design team is going to notice that immediately and bring it right back to you. And the more of this data that you challenging it becomes to keep it organized, to keep it aligned, and to keep the causality that was

there from the beginning. Everything seems fine when you first start. You've never used, you know, any of these models before. Your first couple chats are great. But, as you continue to move forward through time, you start to feel and sense that if I don't do something about this, this is going to be completely unmanageable within a week, a month, you know, however long it takes you to

accumulate enough history with the model that it becomes almost impossible to maintain that same time stream moving forward, right? This is where the challenge comes in in enterprise IT specifically. So, all of these organizations have done research on enterprise companies that have tried to implement artificial intelligence in 2025 alone. I will initiatives happen before that, but that's when it really started to pick up an enterprise IT.

Everybody's looking into purchasing something, implementing something. How can AI benefit my business? 95% of GenAI pilots produced zero measurable return according to MIT and AIDA, 80% from Rand. S&P Global went about it a different way. They took a look and they said found out that 42% of companies literally abandoned their AI initiatives, right? And then you can continue to go down. All of the individuals and organizations

that are cataloging this data out there eventually return back with the same message. Any of the initiatives that deliver value deliver value in a very simple deterministic way. There's a model that we built and it goes out and it does a specific thing every single time. It doesn't have to remember what happened before. It takes data in and it puts data out. Sure, a large language model

can do that, but would I call that success necessarily? Because what is that model, right? That's a deterministic model. You can do that with Python, you can do it with TypeScript, you can do it with any number of languages and frameworks that we already have deployed today and you can do it with a significantly lower cost for a simple automation process like that. Even no-code solutions like

AnyChart, for example, offer this type of capability. Large language models add value on the non-deterministic side. When you present them with a causal chain of events and ask them, "Based on what you know about how all these things connect, what should we do next? What are our possibilities? What can we envision for our business over the next 6 months based on what you know about us from

the past 6 months. The only way to actually get to that value is if the model actually has a sense of what that last 6 months was. But if you start the model with nothing, you get nothing. If you start the model with all of that causal history, you get all of that history before you even start the conversation. It becomes integrated into the The idea being

that you can move from this doesn't generate any value except in the simplest of deterministic cases. To this generates an enormous amount of value that we didn't even know was possible. So, that's one of the challenges that we've had. And according to all of this data out there from any of these organizations that make it their business to know these things, this is a challenge that literally

everybody has. So, that's when we started looking at how do we solve this problem? How do we build memory and experience into our large language models at our business? So, that we can get the value that the people are looking for, enterprises need, but aren't able to find given the current paradigm, right? And that brings us to the model that we eventually settled on. That's where we

are today. That is responsible for any number of different initiatives that are bringing real value to our business. So, when we looked at knowledge graphs and we decided how are we going to build this? We thought about all of the things that make something mean something. So, if you have an event and you have another event that related in time, that's what the model needs to know.

But not as in let's tell the model this, as in when the model looks at the graph. That's the constitutive component of the structure of the graph itself. So, we have an MCP server. The MCP server has two different layers. It has the process layer. That's an invariant. That right there is time. That's what you'll see in the top row up there. A domain defines what is

this thing, this experience that we're talking about. It could be knowledge transfer for a particular product or solution that your business uses. We deployed this today when we had an individual who was moving on from that person's role where they currently are, or contact center. Contact center is a bear for any organization to manage, and when the person who knows contact center decides that it's time for

them to move on, they need to bring all of that knowledge, all of that experience. And that's really what it is with contact center, because when you're talking about dealing with customers and the groups that support them, you never know what's going to come across that particular help desk or that assistance center. It's constantly shifting as we move the experience of it, how you solve those challenges

resides within the individual that knows the system. It's not in a read me somewhere, it's not in a pile of work documents somewhere. It's in that person's head. Because what that person has of that contact center is a phenomenology, a journey. They've lived through a terrain that at many times made them want to turn around and go back. And they wear those battle scars with them every

single day. Now, how do you get that experience into a model? And this is the challenge that we ran into and we continue to run into. Those types of roles when you hand them off to someone else, you can't hand off your experience of them. You can just hand off what you know about managing them. Those are two very different things. So, when that individual goes and

makes a change and it creates some issue where when you bill all of the different contact centers back, making that one change results in a billing error that isn't apparent or obvious. That group never gets billed and that particular vendor never gets paid. How did this happen? Why did this The person who manages that solution today, they have to spend hours, days, weeks fighting with it, struggling

with it, discovering what that strange, weird caveat that's not mentioned anywhere actually was. That's where the business begins to suffer. And those are exactly the experiences that you want to pass on to the next person, next team, next group. Because if you don't, what happens? They eventually make the same mistake and they suffer the same painful journey. Right? When you use a knowledge agent and you give

a knowledge agent this graph structure that you see in front of you, the individual comes in, they start their interview. I'm so-and-so. I'm moving on. I'm going to go ahead and transfer my knowledge about this thing that I manage. [snorts] The agent has a prompt that essentially allows it to understand what it's supposed to do. It uses this MCP server. There's a Neo4j graph on the back

end and immediately says, "Welcome so-and-so. Very interested in what you have to say. Let me go ahead and get our session going." It starts a domain for that piece, executes run one. This is the first temporal stream in the experience of this particular application for our and then it continues from there. Every day or maybe not every day, whenever the individual who's leaving wants to come back

and talk about something else, something else that they experienced, some of their pain that they had to deal with, time doesn't matter. The time stream is what matters, what came before what. Because the other layer that you see under there, the second layer, knowledge evolves because the agent evolved because the experience the agent has of the individual who's interviewing with this knowledge transfer agent evolves as well.

Because when that person comes in for the next day or maybe later in the day they have another chat session, becomes another run session. They come back with oh, you know, I forgot that one bit. Man, this this was just awful. Let me tell you about it. And the model is extremely good at digging into what the person said. It's looking for coherence. You said this, this

is very painful. Let me go ahead and record that as a prominent thing. But let me connect that to everything else in the graph. Not all of the pieces in the process layer, that's an invariant, that's the time stream. All the components in the knowledge layer, not to the components that are in the existing temporal frame, but something run one evolved into something that this person remembered

in run three. That's the power of it. That's what gives this thing the ability that no rag solution is going to give you, that no pile of markdown files or you know, pile of XML, you know, if you're using the Anthropic recommended, you know, system prompt structure, right, for the Claude models. Because all of those pieces, they do the one thing that you don't ever want to

do. They strip the temporal dimension from the thing that you're trying to model. And when you strip time from a domain, you don't get timeless data. You get meaningless data. That's the challenge that anybody who's worked with large language models long enough has experienced every single they start a new chat that needs to evolve from something that came before. The model that we kind of came up

with in basically triggering this in an automated way because the model that I just mentioned is the user essentially going to the model and starting every one of these temporal sessions, these temporal experiences. But you can extrapolate this out. You can use something like N8N with a schedule trigger. And then the schedule trigger goes in and says, "Okay, I'm going to call Quad Code, for example. We

do this. Quad Code has a Quad IM B. The IM B goes out and says, "Okay, we want to take a look at all of the SaaS products that we use as a business. And we want to understand what Microsoft is going to push down our throats without telling us. We don't want their marketing slides. We don't want them to tell us what's great about Copilot. We

want to know about the little changes that are going to happen in the tools that our business uses every single day that they have buried in some FAQ somewhere or in some Microsoft developer network um you know, notes list or or something of that nature. It's It's buried somewhere that technically it's notifying the customer, but the customer really has to know where to go and where to

dig to find these things. Yeah? They're the kinds of things that when you come in in the morning, you see six tickets because Microsoft pushed something that changed something in Excel and didn't notify [clears throat] anybody through the traditional channels that make them look good. They just put it as a footnote somewhere else, you know? Simple to fix, but the user experience suffers as a result. So,

we use this same structure. Claude code goes out, it does all the research, and it digs, and it digs, and it digs. It goes through all those places, all these SaaS companies. Not that they don't want you to look, they just don't make it easy for you to find. Well, Claude doesn't give up. It just keeps looking and looking and looking. And over time, it builds the

same This is what I've learned about what's coming down the pipe from Microsoft. If you want to add third-party agents to record your team sessions in Microsoft Teams, that's great. Maybe you use Otter AI, for example, right? Well, pretty soon you won't be able to. They're going to go ahead and cut that out. You can only use the team solutions. And there's any number of these, right?

From SMTP, authentication, can you use the basic? Nope, we're getting rid of that. So, all these little things, for all of these organizations, all these SaaS companies out there, Claude maps them all out. And then Claude also can put together a dashboard-style interface for your management team. The management team doesn't want to look at a graph directly. They don't necessarily want to ask Claude to go and

tell them what's in the graph every day. They just want to be able to go to a dashboard and see what's important to me right now. What matters to me at this moment, on this day, what am I going to have to do? And then, once I've addressed those, what am I going to have to plan for? That's what a manager needs to know, you know? So,

Claude also goes and builds an S3 or a bucket an application on an S3 bucket in AWS, and it just modifies the data. The structure of the application is fixed. In our For we use Astro for this because it's excellent at building this sort of large language model dynamically generated front ends for managers. Or for an engineering team. Right? And then we have a skill that takes

a look at the data in the graph itself and asks, "What is this thing that we're presenting? And what is our audience?" The look and feel of the app when the audience that it's designed [snorts] for looks at it is designed by the structure of the thing itself. We don't try and fit it into a framework, make it look like this, or, you know, use this front

end design paradigm. No. The front end design paradigm is designed by the domain that the thing that we're modeling represents. The people that are looking at it from their perspective, from their frame when they look at this, do they say, [snorts] "Yes." Right? That's the idea. The model decides all of this. And it learns and understands why it needs to do what it does because it has

two-layer graph to examine. It understands the time stream, and it understands in the knowledge layer how all of these bits evolved over time. These are some of the bits that we put together, that we have in production >> [clears throat] >> So, excuse me. [laughter] >> Knowledge transfer. >> Wrong pipe. So, for >> for knowledge transfer, sorry. That's the one I just talked about quite a bit

that we're using every single day to take information from all the different domains that we have >> [clears throat and cough] >> put them into a single graph. So, I mentioned contact center, but we're also doing this for all of the other domains that we manage, you know, as a Particularly within enterprise IT, but it doesn't have to be within enterprise IT. You can use this like

I mentioned engineering, you can use it in marketing, you can use it in finance. >> You can use it in human resources. It can be applied to anything. The structure of the graph applies across all domains because the constituent [snorts] component is time. And time is a constituent component of literally everything that means anything because time is meaning. Enterprise infrastructure, >> that's the initial ontological aspect of

everything that we built started with enterprise infrastructure. We had to split from one organization into two organizations, we needed to understand how all those things relate. And anytime you want to relate something to graphs are essentially uh the native environment in which the relationships are the first-class citizens, right? So, we built a graph based on network data from ExtraHop, we built one based on security policies >>

from east to west, um from north to south, we have different firewall models to handle each of those aspects in our enterprise environment. F5 load balancers and applications and then Windows and Linux devices themselves. Right, so they also send data up to Splunk. It doesn't have to be Splunk. There's many different ways to collect logs from all the telemetry that comes in throughout your organization. Splunk is

one of the ones that we use in addition to some others, but ultimately, if you have something collecting that sort of telemetry, all you need >> is an ETL pipeline to take that data and push it into a graph that represents what that thing is from that thing's perspective. >> That last bit is the most important component. In order for the ontology to accurately represent the thing

that you're claiming it does, you have to model the graph from that thing's frame. What does a Fortinet firewall see? What is its actual experience? If I were to be able to shrink myself into the size of a box, let's Fortinet firewall, give myself interfaces, plug into the network, and process the electrical signals that come through me every day, what is that like? And when you can

understand the thing that you're modeling from its own frame, it doesn't just tell you what that thing did. It provides you with the of that thing's experience. And that is what the large language models are looking for. If you start with coherence, you get coherence. If you start with incoherence, incoherence being build me a PowerPoint of all of our sales data over the past quarter, for example.

And you tell to go into SharePoint, it pulls a bunch of data, all those pieces together. But it pulls a bit from here, because retrieval-augmented generation just chunks up all of your data, and it puts it up in high-dimensional spectrum space, yeah? And then it chunks up what you've said, does the same thing, and it does its math thing, cosine similarity, whatever you're using. And then it

says, "Okay, here's something from this deck, here's a piece from this pile of documents, from this pile of documents." And it brings them back to the model, and the model builds your PowerPoint. And then you go on to present it, you get to slide six, and you say, "Here's our sales data from the last quarter. You can see all of" and then a manager stops you and

says, "That's not our sales data from this quarter. It is from this quarter 3 years ago. Where'd you get this?" That's the problem. When you use retrieval-augmented generation, it strips the thing that matters most, which is time. It doesn't know how to relate the chunk that it took from here and here to each other. Because that's the piece that gets stripped out when you chunk the data

and push it up into a high-dimensional vector, right? So that's why all the solutions that we've built, particularly in the enterprise infrastructure, always return what is and how it evolved from what was. Security intelligence is another one that I built, and recently, using that same model that I mentioned for mapping the SaaS components, right, that we leverage, application infrastructure. Our CIO came in and said, "We have

a solution, a system, and it's a black box, and it it bites us. I need to know more. What is this thing? When somebody says, "How do you fix this? What is happening with this?" I don't know what to say. Nobody knows what to say. How can we gain visibility into this thing? Same model. We use enterprise infrastructure to map the entire What's feeding it? Who's using

it? How is the data that's in there presented to the people that are using The large language model went out using the enterprise infrastructure ontologies and mapped the entire thing and produce an Astro application for that particular consumer. From the CIO's frame what does he want to see when he looks at this? When he asks that question, this is a black box. Open it. What does he

mean? What is What is meaningful for him? And that has a lot to do with, you know, his education, where he came from, you know, the the culture, everything. What does he When he looks at it, does he say again, "Yes, this is what I wanted. Thank you." Right? Without even articulating, he looks at it and he just knows, "That's what I wanted. Perfect." Then the words

come out. But the minute that he looks at it, that experience has already occurred. The words come after. This is the penultimate piece that we're still working on deploying. And what this is designed to do is to expand upon all the components that I've already discussed. Taking a and giving it the ability to go and look at a domain. We're not going to tell you We're not

going to trigger something. You go out. This is your experience. You examine that thing. Go look at all those ontologies, the enterprise ones, and you examine it in any way that is meaningful and interesting to you. And then you get your own temporal graph. That becomes who you are. And you build it every hour, every 15 minutes, whatever the time frame is, we trigger the ears component,

right? Exist, examine, record, report, stop. Yeah. Plug that into your graph, and then over after five runs, after [snorts] 20 runs, after 50 runs, when you go out and look for something, you have the ability to trigger a message to me in Microsoft Teams. You decide, [clears throat] based on what you know to be true, your phenomenology, what's important to me and what isn't. And when I

respond to you, and I say, "I don't care about those things." That also goes into the temporal graph. Over time, the model learns not just what to notify you of, but what not to notify you of. That last bit is key. Yeah. So, that's what we're all about. That's what we're focused on. And that's what we're driving towards. Right? How can we have these agents that have

a phenomenological history, an experience of what it means to be the thing that they are. If they can remember where they were, they can help us where we are, and they can expand where we're going. That's what we're all about, and that's where we think the next generation of large language model implementations, especially in the enterprise, are headed. Because everything else that we tried so far, better

retrieval augmented generation models, better, you know, embedding, my all those things, none of those things have improved any of these numbers. But the systems that we've built, the experiences that our users have, when they start using the solutions, particularly the enterprise infrastructure solution, the response is when we used to get a P1 incident, I would have to sit in a meeting for days with 60 people. Everybody

has their own idea of what's wrong and how the things work together. Now, I just ask, "Claude, go and look at the enterprise infrastructure ontologies and tell me why this thing is broken." And now it comes back and it has the entire causal history of why this thing is not doing the thing that it should be doing. Once they experience that, the suffering and pain of sitting

at a P1, once the user knows, "I don't have to do this anymore. I never had to do this." They will never go back. They'll just refuse. And we've had this same experience. "I'm not going to go sit in there. I can just ask the ontologies and they'll just tell me." "If you want to do it, go ask Connor. He'll give you a login. But there's no

way I'm going to go back and suffer like that when I know that I don't have to." That's what sells it. Once somebody feels that they don't have to suffer anymore, there's no chance, zero, [snorts] that they're going to be going back to that pain and suffering. Yeah. So, I think that's it for my time today. Thank you very much for attending. I hope you enjoyed the

presentation. Any questions? Go ahead. >> [music]