Why your Agent needs Memory, not just context
Agent memory and skills provide the structure, persistence, and continuous learning that raw context windows lack.
Highlights
4 clips · 8 min of 44 min-
- Agent memory combines embeddings, databases, and LLM parametric memory.
- Memory engineering optimizes retrieval pipelines and database search.
- Memory serves as a human-friendly mental model compared to raw context.
-
- Skills mirror standard operating procedures used to onboard humans.
- They provide structured step-by-step processes for specific tasks.
- In memory architecture, skills represent procedural knowledge.
-
- Memory life cycles involve ingestion, cleaning, encoding, and storage.
- Unlike standard data pipelines, memory systems must implement a mechanism to forget.
- Weighted scores can help suppress obsolete or low-relevance memory units.
-
- File systems allow rapid building by removing infrastructure setup friction.
- They lack crucial enterprise features like security, concurrency, and transactions.
- Rebuilding these features on file systems leads to recreating a database.
That’s all the highlights.
Questions this video answers
8 · every answer cites the moment it was said01 What systems make up agent memory? 2 sources · 4:32
Agent memory is built on a combination of embedding models, databases, and large language models. The embedding models handle semantic search representation, databases store and retrieve information, and LLMs provide static parametric memory.
02 How does memory engineering differ from context engineering? 2 sources · 6:33
While context engineering focuses on curating information for limited context windows, memory engineering optimizes retrieval pipelines and latency. It combines disciplines like database engineering, search optimization, and AI engineering to manage agent recall.
03 What role do skills play in agent systems? 2 sources · 10:05
Skills act as standard operating procedures for agents, serving as procedural memory for tasks. They provide step-by-step instructions and tool locations to ensure consistent execution, similar to how human SOPs transfer knowledge.
04 What is entity memory in agent design? 2 sources · 23:26
Entity memory stores user-specific details like preferences, working styles, and tool stacks to build a persona. This memory helps make the agent's interactions more believable and tailored to the individual user.
05 What does the life cycle of agent memory involve? 2 sources · 28:12
The memory life cycle starts with data ingestion, cleaning, and encoding via embedding models into a database. Crucially, it also requires mechanisms like forgetting or suppressing outdated information to keep the system accurate.
06 How can omnipresent agents prevent loss of company knowledge? 2 sources · 34:18
Omnipresent agents operate across tools like Slack and Google Workspace to track successful workflows and processes. They automatically document these events into skills or workflow memory, capturing tribal knowledge before it is lost.
07 Why do developers choose file systems over databases for agents? 2 sources · 0:42
File systems allow developers to build quickly without worrying about infrastructure setup or tool selection because LLMs have a natural affinity for bash and shell commands. However, this speed comes at the cost of enterprise security, concurrency, and data privacy.
08 How will future agent systems achieve continuous learning? 2 sources · 41:05
Future systems will merge the agent loop with the model training loop by feeding collected traces back into training. This allows models to continuously improve their core latent memory rather than relying solely on retrieval context.
Section-by-section summary
9 parts
Agent memory combines embedding models, databases, and LLMs
Agent memory describes systems and techniques that allow agents to remember and adapt over time. It encompasses embedded models for encoding, databases for persistent storage, and parametric memory within LLMs. Memory engineering focuses on optimizing retrieval pipelines and latency.
Skills act as standard operating procedures for agents
Skills are comparable to standard operating procedures in human organizations, defining step-by-step processes for specific tasks. In agent memory architecture, skills represent procedural knowledge. They give agents structured workflows and tool locations to achieve desired outcomes.
Comprehensive data and memory drive agent success
Agents fail when they lack sufficient information, similar to onboarding a new human developer without context. Organizations sit on massive amounts of enterprise data that must be transformed into accessible memory. Equipping agents with this institutional knowledge enables reliable task execution.
Robust memory systems help agents traverse enterprise data
Agents can scan database schemas and underlying code to understand how data is structured and used. Equipping them to handle heterogeneous data storage ensures they can retrieve information securely. This iterative process builds reliable and capable agent behaviors.
Entity memory establishes user context and persona
Entity memory gives agents an understanding of a specific user's preferences, tech stack, and working style. This can be frontloaded or built through back-and-forth interaction over time. Entity memory significantly improves the believability of interacting with an intelligent agent.
The memory life cycle requires a mechanism for forgetting
The memory life cycle involves ingestion, cleaning, encoding, storage, and hybrid retrieval. Unlike traditional data pipelines, memory systems must also implement mechanisms to suppress or forget obsolete information. Data augmentation techniques can further enrich embedding representations.
Omnipresent agents capture workflows and prevent knowledge loss
Modern agents can operate across multiple tools like Slack and workspaces to observe successful workflows. When successful events occur, agents can document them automatically into new skills. This omnipresence prevents institutional knowledge loss across teams.
File systems offer fast builds but lack enterprise security
Using file systems for agent context enables rapid prototyping by eliminating infrastructure setup and tool selection. However, this speed comes at the cost of security, concurrency, and transactions found in databases. Reimplementing these features on file systems essentially rebuilds a database.
Future agent systems will merge agent loops with training loops
The future of memory engineering points toward continuous learning where agent execution loops merge with model training loops. Collecting traces from agent interactions allows teams to fine-tune models and embedding spaces automatically. This bridges custom context with core latent model improvements.
Connects to your library
by shared topics
n next · p previous clip · t highlights/full
< > slower/faster · / search what was said
-
Agent memory6× · first 4:04
A term describing systems and techniques working together to allow agents to remember and adapt.
-
Context engineering4× · first 5:01
Thinking systematically about the information curated to pass into a limited context window.
-
Memory engineering6× · first 4:59
A cross-section of disciplines focusing on optimizing retrieval pipelines and latency within agentic systems.
-
Standard operating procedures3× · first 10:08
Documentation defining how to do certain tasks to transfer knowledge, acting as agent skills.
-
Entity memory4× · first 23:26
A form of memory storing a user persona, preferences, and ways of working.
-
Data augmentation2× · first 30:27
A technique introducing diversity into data by modifying perspectives, applied to augment LLM outputs.
-
Continuous learning3× · first 41:07
A norm where agent interaction loops are merged with model training loops to update core memory.
7,742 words · about 31 min to read
Agents can be omniresent. You can have an agent that is used on Slack, on maybe your Google Workspace. You can have the same agent in other tools you're using. Now, when the agent is going through maybe processes or workflows or messages and it's starting to go through successful events, what the agent can do is document that for you and store that within some form of skill. Therefore, we actually don't have the problem of loss of knowledge. If you do this properly, you start to have like a scribe.
What would you say the kind of like differences or benefits of the approach of a file system versus like context that is from a database?
The key benefits of using a file system is the speed at which they can build when you don't have to worry about infrastructure components and tool selection. You're just using files. But that speed comes at a cost. Mhm. And the cost is Before we jump into this episode, I wanted to let you know that this podcast is for developers building with AI at the core. So whether that's exploring the latest tools, the workflows, or the best practices, this podcast's for you.
A really quick ask, 90% of people who are listening to this haven't yet subscribed. So, if this content has helped you build smarter, hit that subscribe button and maybe a like. All right, back to the episode. Hello and welcome to another episode of the AI Native Dev. My name is Simon Maple. I'm your host for the show and joining me today is Richmond Alake who is the director of AI developer experience at Oracle. Welcome, Richmond. On this episode, we're going to be talking about context management and memory management and where you draw the line between the two. We're also going to be talking about whether developers should experiment with their data storage and also a wonderful question about how we differentiate between onboarding humans and onboarding AI agents. Richmond, welcome to the episode.
Thank you for having me, Simon.
Oh, it's an absolute pleasure to have you, Richmond. And you were in London, so we thought, oh, come on. We got to we got to invite you around to the to the podcast studio. So, Richmond, let's give a little bit of background to yourselves. Let's talk a little bit about about, you know, your your career and things like that. uh you were with many companies uh such as Nvidia and Neptune AI in the past and and you previously worked for MongoDB uh before joining Oracle. Um now I I'm a big Java person in my background so Oracle I work with a lot on the Java side and things like that. Um but today you are the director of AI developer experience at Oracle. Tell us a little bit about we don't need to say what Oracle does although you maybe maybe let's talk a little bit about what is happening in Oracle in and around AI but tell us a little bit about what an AI developer experience role looks like.
Yeah. So um again thanks for having me on and uh we're going to have a very good conversation. So yeah, you're right. I've had a very interesting trajectory across my career, but one thing is very important across the different companies I've worked with for the different companies I've worked at is I've always kept the developer front and center of everything I do. So when I worked with Nvidia, it was uh as a writer when I was speaking to machine learning engineers and data scientists and I was writing about algorithms and all the good stuff we had around computer vision and deep learning at the time. And in MongoDB I was a developer advocate. So again focused on developers. And what that led me to is to understand what developer developers really want from technology. How they want to use technology and experience technology especially within the domain of AI. And that's led me to be um one of the key folks within Oracle database that helps shape our products and features around reaching developers.
That's pretty cool actually that you went from to Oracle as well because I remember back in the day of course when when kind of you know document style databases came out you saw the right big rush to to to folks like and stuff like that but
Agent memory combines embedding models, databases, and LLMs
1 Highlight · Defining agent memory and memory engineering
obviously you know Oracle is so present in so many different organizations it's it's a big area now if we think about uh one area that you're you're very familiar with today uh agent memory um in fact why don't we start by defining a few things what what is when we talk about agent memory and memory management and things of that. What do we actually mean?
Okay, so with agent memory, it's actually a term that describes a bunch of systems and techniques working together to allow agents to remember and adapt.
It's as simple as I can keep it. But if we just uh double click into the systems and the techniques, the systems within agent memory are your embedded model that does the encoding of different data objects into numerical representation that allows you to do semantic search. Then you have your database which stores all the information and allows you to retrieve information as well. Then you have your LLM which has a form of parametric memory which is static. It doesn't change
except you fine-tune it.
So these are the systems. Then techniques are what we talk about such as context management, memory engineering, all the context engineering techniques. And and so when we talk about the context management, context engineering, what's the difference I
guess between context management uh and and memory management? And I guess so we have prompt engineering as a as a as a role uh that that people like, oh, we need a prompt engineer for this. Do you feel like or have you seen and do you feel like there's space for a context engineer role or a memory engineer role? So one thing about AI in the field is it's moved so quickly and people are trying to understand this space and for developers is trying to understand the job to be done.
Yeah.
And because we're moving so quickly we tend to just latch on to something that we think is something and then started to find roles around it. Prompt engineering emerged probably two years ago which is nothing.
Yeah. Although it feels like about two decades in AI terms and prompt engineering was meant to describe the key job to be done um that developers were doing which was actually using a bunch of linguistic patterns to actually steer the LLM into a desired outcome, right? We wanted the output to have a certain uh have a certain um representation or come out in a certain way and we started to put in a bunch of prompts and prompt engineering became the job to be done. But the reasoning capabilities and the abilities of this large language models actually improved and that led us to concentrate more on what we actually put in rather than the the robustness of the prompt itself. So we went into context engineering which is actually thinking thinking very systematically about the information you're curating to pass into the context window because the context window is limited. So to answer your question, are they going to be context engineers and memory engineers? I would say yes, but
would they be called memory engineers is or context engineers is something we're yet to see. But memory engineering I could speak to because it's nothing new. M
memory engineering is just a cross-section between a couple of disciplines which includes database engineers um search optimization engineers for that work within database domain software engineers and a bit of AI engineering if you just cross-pollinate some of the techniques and disciplines within the roles I mentioned
you're going to go into memory engineering which is a set of engineers that really focus on optimizing the retrieval pipelines or um the latency of the retrieval pipelines within aentic systems and that's what they solely focus on but they need to understand software engineering and database as well.
Absolutely. And and would you say memory management is a superset of context management generally? It's a very good it's an interesting debate, right? Which one encapsulate the other? Is it memory context? So, look, I'm I'm very biased, right? Um I see everything as memory and that's because I always look to how human work and use human analogy to actually describe what I'm seeing in tech today because I communicate with both technical and nontechnical people.
So, when I use uh human analogies, folks understand me. the general populace understands me. So memory actually is a good
way to bridge the gap between people's knowledge of nontechnical and technical. So when I say memory to my mom or my grandma,
they understand what I'm talking about. But if I said context, I'm like
they don't have the context.
Yeah, they have the context.
But um memory really brings people into that same understanding um uh landscape where you can start to build upon it. So when I say hey we have agents in our phone and they need to remember. So every information you give into an agent the agent is that's actually memory. Yeah.
So it starts to allow you to think about ways you can improve the re the chances of that specific information being recalled. You start to think about ways you can optimize your retrieval pipelines.
So this is where we're heading towards and that's how I that's why I see everything as memory. Well, you can argue maybe everything is context.
It's an interesting way to frame it. I guess it massively depends on your on your on your perspective, right? Exactly. In terms of how you look at it. Um, one thing I'd love to chat about, we talked about we've talked about skills now for the last gosh three four weeks on on on the podcast. Um, I'd love to I'd love to kind of like hear your thoughts in terms of okay, skills where where do they sit in in relation to context and and even at Tesla we have that question like when we put stuff on the website should we should we say skills and then context? Well, you know the the kind of part overlaps as well.
Where does skills sit in?
It's very important to get the naming right within this space. It's very hard and because it moves so quickly you're
Skills act as standard operating procedures for agents
2 Highlight · Skills are standard operating procedures for agents
like okay we can't use that anymore. This month we'll say skills. We say skills next will say something else and no one was saying skills last year like early last year right so where do we see skills in this whole thing again I'm a very simple man let me go back to humans um skills are nothing new humans have the equivalent and they're called SOPs
standard operated procedures which are documentation that you have within organizations that define how you do certain task and the reason why we add SOPs is because
you might have a certain way of doing things and let's say you hire someone else and you want to be able to transfer that knowledge to someone. The best way we saw as humans to do that was to document it and really document it in a structured way where you define the steps by step um pro stepby-step um process you have to take to achieve a certain outcome.
They're called SOPs
and we have organizations today skills are SOPs for agents.
Yeah.
Right. is just a way of telling an agent there is a task and I'm gonna give an arbitrary name to the task. Then I'm going to describe the task in in in a certain uh length. Then I'm going to give you step-by-step instructions and maybe the locations of tools and scripts or MCPs that allows you to achieve this um the outcome of the that we want from this task execution. And that's what skills are. So where do they fall into the domain? Well, if you come into the world of agent memory, you're going to realize that skills are actually a form of procedural memory, right? Humans have pro procedural memory in our brain.
There is a part of our brain responsible for storing and understanding skills that we have. For example, if you could do a backflip, where that knowledge actually is stored is something called the cerebellum in your brain. And that stores a bunch of procedural knowledge that you have the ways you do routines
and tasks. Skills and if you look at things from the agent memory memory perspective, skills are procedural knowledge for your agents.
I love the I love the parallels that you're drawing between humans and agents here. In fact, yeah, I'll call out our marketing team here who don't tell them. I I I like marketing messages cuz that I'll lose all credibility. But one of the things that they kind of like mentioned was it was it was effectively saying if you had a new person join the team, yeah, a human, let's call them, if you had a human join the team, you'd have to on board them. And one of the things that we're doing obviously with context is we are on boarding on boarding agents. And so it's about, you know, humans need on boarding, agents need that onboarding, too. You have to provide them with that context. You have to provide them with those skills and things like that. It's exactly the same thing, right? And one of the things I love about what you kind of said was um how organizations already have those those procedures, the standard operating procedures. They already have them written down. If they're only if they're, you know,
yeah,
if they want consistency across their organization, they need to explain to developers this is the way we do things and if you want to follow procedure, this is how you do it. All you really need to do is take that, skillify it, if that's a word, and and provide it to the edge. is now if we use it enough it will be the Oxford English dictionary. So, so it's it's it's really about you know wrapping up and to expect a human to be able to perform the way that we want them to expect a developer new developer to to to do that without giving them that information. We'd think are we
Comprehensive data and memory drive agent success
being stupid trying to expect a human to do that. Why would we ever expect an agent to do exactly the same without providing it that context that memory that skill?
Yeah. Um let's talk a little bit about what kind like leads onto what do agents need to be successful and I think a lot of the time we blame agents and you know unnecessarily whereby actually we're not giving the agent that that the level of context or the level of information it needs to actually be successful in the same way if I just said to a new developer or a developer who's just joining the team I needed to do these things I didn't give them the information and then they come back and they said well I've done this thing and it satisfies what you asked say No, you know, we need to do it this way. We where are the tests? This we need to follow this style guide, etc., etc. We wouldn't do that to a person. So, what do we need to provide to an agent so that it can be successful?
So, we'll start a very simple answer to that is information.
Mhm.
We need to provide agent as much information as we can.
Then the second thing the answer to the second answer to that question would be data. information is data
and organizations are sitting on top of tons and tons of data.
Then you come into my world, I just tell you you need to give them memory. You need to give them information of existing um uh you need to give them existing memory that contains information that you have previously and you need to give them a robust system that enables them to actually adapt and continuously evolve and learn. Mhm.
I happen to work in Oracle
and it will be no surprise that pretty much all the Fortune 500 companies or most of them are using an Oracle database.
I heard you do Oracle do some work in data.
Yeah, I heard they do. Yeah.
I wasn't sure if it was a rumor but yeah.
Well, the thing about the unique position of where Oracle is is and and this is very rare for any company in tech. Aroka has existed for over four decades
and across that four decades we've seen different crucible moments and paradigm shift we've seen the internet error the cloud transformation data now we're in AI but because we are students of change itself we understand what we need to do to evolve and meet the needs of our customers and developers
and that's why most of the data is sitting in in in uh most of the data you see in Fortune 500 companies sitting in Oracle. So Oracle understands data that means we understand what agents need to actually be successful which is memory and we understand the robustness and the techniques we have to build around the agent itself to allow it to continuously learn. Now, a couple of points here because I think one interesting thing which I think humans are very good at where agents are perhaps not as good at is as a human I I can kind of understand when I'm being overwhelmed with data. I can also understand when I need to seek data and when I make a decision as to do you know what I can't I I I may have enough information to just about be able to complete this but I know I'm not going to be able to complete it well without more information. Agents on the other hand when you overload them with data you see their performance degrade
when they sometimes get just enough data that they can possibly form an answer. sometimes they rush that and jump into the answer before actually getting all the data they need. And I guess one of the wonderful things about like you know Oracle customers is that they will have so much data. Um how does that I guess my two questions are how do you get an agent to the right data
um given that there is so so much and let's start with that one. My second one as a follow on will be how do you make sure that the agent is smarter about getting enough data so it's not so so
Robust memory systems help agents traverse enterprise data
much that it overwhelms it but it's not you know so little that it it doesn't have the the the right information and capability to actually perform the task well. So your first question was how do we get an agent to the right data and so I'll answer your first question which is it's a very hard thing to solve right and as we're talking a few days ago openai put out a piece on how they built their data agents
and one of the techniques that they they actually mention is
they have a single agent that actually scans it works at different levels. So one way and this answers the question and one way the agent actually works is if firstly it scans through all the tables in the database to understand how what they have in the schema definition and how they relate to each other
and that allows the agent to understand how data is stored and how it's used. But then they have the same agent scan through the code that is used the Python code the Java code that is used to actually construct this tables and manage the tables. Now the agent understands the thinking that went behind the generation of the tables or what sort of datas are stored or the transformation that happens.
So how do you get an agent to the right data? is by giving it will be the answer to the last question which was giving the agent a lot of memory of what's been happening in your organization. You have a bunch of institutional knowledge, you have a bunch of information, tribal knowledge. The best thing you can do is have a very secure agent go through and traverse through this information. M
they have a capacity to understand and when it's doing this traversal of information it's able to store this in a system that allows it to retrieve information efficiently. So this is what I would say in production the data you encounter is has a heterogeneous nature. M so you have vector, you have JSON data, you have unstructured structured um uh uh semistructured data, you have knowledge graphs and but you just need to really equip your agents with the capabilities to work with all of this different variety of data in terms of storage and retrieval and allow your agent to be able to scan through different um aspect of your enterprise data securely. When you actually do this properly with a very good robust agent memory system, you start to understand or you put yourself on a trajectory of
really building a reliable, believable, and capable agent. It's not going to be one shot. We're not going to oneshot our way through this. It's going to be an iterative, experimental process of improving the agents we have.
And securely was a really key word there as well because obviously there is so much data. How do you allow the agent the request the permissions that a user should uh
it's such a it's such a huge room for us in Oracle because again we've existed for over four decades and
you can imagine the the the amount of times we've seen the nature of privacy change
and the requirement to actually secure data change as well. different regulations from different um governing bodies on how data should be stored retrieved securely as well and this is embedded in Oracle Oracle database
you have all the usual kind of like role-based access built in so it's about the it's about the agent
so when I speak to developers and AI developers today I'm going to be very honest we the security on the list of things we care about comes in You surprise me. You surprise me.
Second to last.
Second to last. I'm not even going to say second for a minute.
Second to last.
Come on. We can't What's last?
Well, to be honest, I don't know.
Let's not embarrass the team. That is lost.
The thing the thing is you have to think about and when I say AI developers, I mean AI developers within the industry all across.
So when I speak to AI and you can see just look at today, right? Um the the popular thing we have now is um uh open claw or or claudebot or whatever the name is now or moleot.
Yeah.
Um
the security issues with that open-source framework and that's all I'm seeing on my timeline.
Yeah.
Because AI developers are we love to experiment. We love to get stuff working. But one thing I actually see with Oracle developers is this because Oracle, we take security and privacy, we keep it number one.
It's it's third bomb. Oh no, it's number one.
It's number one for Oracle. Security and data privacy is number one for Oracle. And when you use a Oracle database, it means that you can move as fast as you want and you get to worry less because we are
giving you it's built in. Security is built in. is developer ready. So you know that you have that infrastructure for security in the Oracle database in Oracle cloud. Yeah. Which allows your developers to just do what they do best. Nice
just move fast and innovate and experiment because
AI is very experimental in nature.
So let's talk about that user single user. We'll start with single user then we'll jump into kind of multi-user and
Entity memory establishes user context and persona
team. as a single user. Um what what what do you see as a typical context that will make a single user more effective?
A single user. So when you say single user, you mean a single user interacting with an agent or an agent understanding?
Single single user interacting with an agent outside of a team.
So let let's say a single user interacting with an agent. What? And I'll speak from the agent perspective.
So go on, let's role play. You you be the agent. I'll be the you be the singer. Okay, this is good. So one thing that agent will actually need is a form of memory we refer to as entity memory.
So the agent will need to have a very good understanding of Simon and it can get that in two ways. one, we can frontload this information of Simon because
you have data in in all the tools you're using and we can just ingest that into the agent's um memory and it's able to then create a persona of you within his entity memory. That's where we're going to store it. We store it in his entity. Humans have this as well. um we're going to store it in his entity memory, but or we can just have back and forth interaction and we begin to formulate um an understanding of Simon within the agent's entity memory. Or we have both where we start with some information about Simon and we build on top on top of that. We evolve what we know about Simon. And this would be things like uh my preferences, my way of working, my stack, my capability with certain languages and libraries I like to use.
Exactly. And it's very important we start to identify the distinction of this different type of memories because
we don't need to reinvent the wheelchair.
Neuroscience has been trying to do this for decades, right? Neuroscience have been trying to understand the human brain. And the best way that they've seen they can understand it is by really distinctively identifying what parts of the human brain is responsible for what.
So that way you can actually have a table within Oracle database just for entity memory.
And in there you have Simon. You have a row for Simon and it has all his likes and preference and you have different forms of uh of data. You can have JSON data. You can have a embedding representation of your of your likes and preference and that allows us to do semantic search whenever you ask a query. And all of this information is how you can start to make a single agent be useful
for an end user because with entity memory you solve one thing which is the believability of the agent. How believable is it that I'm interacting with an intelligent entity?
And you see this in a lot of commercial tools today. So if you use um uh chat GPT, I always get this box that says, "Do you like this personality?"
Yeah.
I'm like, "No."
Yeah.
I'm joking.
Do better. Do better.
But you see that even people on the frontier of this space are trying to understand how we be how we start to make this agents and computational entities believable.
Right? We're trying to understand a persona and we're trying to modify that. So this is entity memory. you know the agents are being asked the same questions right they're like do do you like the personality of this you use no I would like a new user please yeah so so I think from the point of so what we've talked a lot about there is kind of like ways of working right so it's almost like how effective a user can be with their agent based on because ultimately the the user is the reviewer there right the user is the person where the when the agent provides something the user it works but I want it to work like this and so knowing and understanding those ways of working a personality that how a a person wants to wants to see things done will allow the agent to provide the user with an outcome that the user will be happy with. I guess there's also very objective answers where it's like this is true or this is false. And that's like I guess another style of context which is potentially a truism like if you're going to use this library the this is the API,
right? Don't you know and we're talking maybe through hallucinations or version problems, but it's about giving context to the agent to make it actually do things um accurately.
Yeah. And so there's when we think about things that will if we think about a life cycle in this context, you probably have the first that we talked about there probably actually changes a lot less frequently because the way someone wants to do something well that's probably more about who they are and the way they like to work than an API which may change two months later and then another week and then another two weeks and and you get updates that the agent needs to be aware of. So when we think about context generally, what's what do we think about as the life cycle or the the the longevity of a piece of context?
And when we think about that, what what are the things that we need in place to keep up with the changes that are required to keep up with the uh the update the refresh of that context?
The memory life cycle requires a mechanism for forgetting
3 Highlight · The memory life cycle requires a way to forget
I'm going to I'm going to answer your question, but one thing is I'll answer I'll answer it by talking about the life cycle of memory. Well, you can switch out memory for context, right? So um life cycle of context this answer applies to the life cycle of memory. Mhm.
The first thing when we think about the life cycle and I'll now I'll speak from a technical perspective is we need to ingest data right so ingest context ingest memory and we have that in typical most data science and data analysts will be familiar with this you ingest data you do some bunch of data cleaning um then you start to do a bunch of encoding this is where we start to pass that data through embedding models and generate different representation and then we go into the storage of this data and then you store it in an Oracle database and then we start to think about how can we retrieve the data. Do we want to retrieve it using vector search? Do we want to retrieve it using normal lexical search or maybe a bit of both which we will call hybrid search.
But then this is where you start to see a difference between traditional data pipelines is you have to have a way to forget.
Mhm.
And that's very important
when you and this is where it becomes very crucial to understand why naming is very important. If you work with context forgetting or suppressing information doesn't come naturally. But when I speak to developers and I say if you think about things from the perspective perspective of memory you immediately start to it becomes almost natural to know that you need to implement a way of forgetting information.
Mhm. And in that life cycle you need a way to suppress information a way to at least uh make the way uh information is being recalled um be affected by other information that is within the storage. Now there's a paper called generative agents by some folks in Stanford came out 2023 or something where it talks about ways to forget information or forget memory and they have this weighted score you can add it to the attributes of each memory unit but this is the life cycle here. So we ingest the data, encode the data, store the data, retrieve the data, forget or remember or reinforce the remembrance of the data.
Then we just go through that cycle again. And there is an augmentation
aspect of it. So not so long ago in computer vision or or or deep learning, we have a technique called um data augmentation. So this is where we we basically I guess now data is is plentiful but in in deep learning computer vision we used to have a bunch of images and the way that we actually um introduced a bunch of diversity into our data set was to augment the image. So we rotated the image to let the convolutional neural network see a different perspective of uh ways that an image could be presented to it in production. This is called data augmentation. Mhm. we can leverage those techniques in um memory engineering or in agent engineering today because the information that you get out of an LLM can actually be augmented
by if an LLM looking at the domain and looking at the information and and you can actually um prompt an LLM to
put in more information that might be missing or might be important to include and then store it again which will improve
the way that information is recalled or forgotten. Yeah,
I do this with either MCPs or um scripts that I have is where I have functions or MCPs uh within um my system resource and I use an LLM to actually augment the description of the function
and understand the function itself. And then I use uh an embedding model to encode this information to generate an embedding representation, a much more richer embedding uh representation of the script so that I can then do something like um use semantic discovery for some of the tools I have within my system whenever I'm working with an LLM.
Yeah, really interesting. And and I think when we we have talked about single user Yeah. When we move to multi-user like the the the thing that redu that that that makes this problem kind of like a little bit smaller for the single uh individual is when there is context that goes out of date it's the individual that can kind of identify it and they can probably fix it or you know prompt things to to to update and fix the data when we get into the multi-team perspective and you have a team of 10 20 30 I I hear Oracle just beyond a startup now is now what was it small to mid Well, how big is Oracle these days?
It's it's bigger than you can imagine, but it still operates at the speed of innovation that you would see at any startup today.
Good answer. Good answer. The uh so so when we talk about bigger teams um you then have the problem whereby different people could have actually different context if they're holding things locally can get stale and stuff like that. I guess there's the the problem then of discovery and sharing across teams. What would you say are kind of like some of the other use cases or things that we need to be mindful of when thinking about a multi-team uh AI using you know developer organization whereby context is important and context
Omnipresent agents capture workflows and prevent knowledge loss
needs to be shared. How do we how do we go about that? The difference between now and the days of before where you had uh large companies and you had people that had tribal knowledge and then when they left then they're left with the knowledge is this agents can be omniresent in the sense that you can have an agent that is used on Slack. You can have the same agent on maybe your Google workspace. You could have the same agent in other tools you're using. Now, when you start to see success, when the agent is going through maybe um processes or workflows or messages and it's starting to go through successful events or see other workers do successful events, what the agent can do is document that for you
and store that within some form of skill. maybe generate a new skill.m MD for this specific workflow that wasn't documented by the person that just did the successful task.
Um or you could just put it in some form of I skills I they're just workflow memory essentially. So agent are agents today are omnipresent. They can go through different systems and understand uh different systems and they can see interactions within a secure environment. Therefore, we actually don't have the problem of loss of knowledge.
If you do this properly, you start to have like a scribe that's following you around, always writing down things you're doing successfully or even things you're doing not successfully and then shared ways to improve. That's the difference. I love I love that loop essentially of constantly trying to optimize text by maybe even how we react or how the agent does uh you know finds issues uh as as well.
Let's go let we've talked a little bit about the database actually. Let's talk about a little bit about about file system as well. Um because a lot of the time agents agents love to like see what's on the file system. Yes. and and sometimes even when we say oh can you use this MCP server over here if it has
File systems offer fast builds but lack enterprise security
4 Highlight · File systems offer speed but lack enterprise security
something locally it can sometimes just grab that and if it's still valid context that might be okay but what would you say are the kind of like differences or benefits of the approach in file system versus like um you know I guess uh context that is from a database
the key benefits of using a file system that I've seen with AI developers today is the speed at which they can build
mh when you don't have to worry about infrastructure components and tool selection have to worry about oh what database should I be using or um what stack what should I have in my stack and you're just using files it you remove the thinking of tool selection
the speed is there
but that speed comes at a cost
and the cost is security
right the cost is what we've been spending over four decades really solving effectively and file system is a good interface for LLMs and agents in general because they're trained on a bunch of shell commands and bash commands and all of this information on how to read and write files, right? That's part of their training data. So they have this natural affinity for working with files that we're taking advantage of today. But it shouldn't stop there because who again we've come a long way from the 70s and
I wasn't alive in the 70s.
I was just just
alive. Yeah. So maybe um maybe you remember I don't know but there was a time in the 70s where there was this phrase from the Unix philosophy everything is a foul or everything is a foul descriptor
and whenever I look into the space of technology it's it's almost like groundhog day because we the same things keep repeating now again in 2026 I'm seeing articles where everyone is saying every files are all you need I'm like yeah we did that in the 70s and I think we've come a long way from there. We realized that you actually need um concurrency, you need asset transaction, you need security, you need data privacy and oh wait, when you start to actually implement all this in file systems, you start to realize that you've just built your own database
on the file system. Yeah,
exactly. Um so this is what I tell my developers.
Yeah. Awesome. Don't experiment with your tool selection.
Right?
The same reason why file systems are very useful in terms of the the natural affinity with the LLM or how easy it is to interface with it. What would you say looking forward now to wrap up I guess where would you say context and memory management are going it you know as models improve because I remember
what was it a couple of years ago when we were talking about prompt engineering all the time um and you know gosh prompt engineering I don't think I've said prompt engineering as much ever than I have done today in this in this last hour or so but um when we talk about context engineering so much now context engineering is the hot topic Memory engineering is is the hot topic for today to make agents, you know, more accurate, friendlier to work with, uh, uh, less frustrating.
What's the future path of this? Do you feel as me as models get better? Is there is there a space where actually we rely on context a lot less? Or do you feel like actually there's no way models can really truly understand what we as individuals or we as an organization or team want to do without this data?
I think where the space of context and memory engineering
you're putting me into that prediction thing, right? Yeah. We're going to
prediction in AI is so bad because they're usually wrong. But
we'll have you back. We'll have you back in a year. Thrill you on what you say. Whatever you say next.
So this is what I would say. Right. Over on Oracle, we there's this principle that we try to operate by which is we always try to be six months ahead of our customers, especially within AI.
So, everyone's talking about context engineering. We were talking about that before.
Mhm.
We've been talking about it for loads of years. Like, yeah, you need data. Okay.
Mhm. Being six months ahead of our customers, we start to realize that we need you don't just need context, you need a way to ensure that context is retrieved efficiently, right? We want this systems to work in near real time or realtime scenarios. Now, how do we start to make that happen? How do we let this agents process data in back in the background and also work in real time simultaneously?
It all comes to infrastructure. It all comes to scalability and that's what we pride ourselves over at Oracle both Oracle database and Oracle cloud.
I I'll give you where things are going or where I see things are going. We
Future agent systems will merge agent loops with training loops
spoke about agent memory. We spoke about memory engineering. The way things are going is we're going to go into a world where continuous learning is the norm.
Where you're no longer building a system where you're thinking how do I get the right context. you're more thinking how do I get the right context or the right information out of this agent loop that I can then pass into my training loop of the actual model and I could then replace it maybe two weeks down the line because now I've retrained this model and the core latent memory aspect of it that allows it to work efficiently has been improved
with the new data that I've just collected And we're already seeing traces of this. For example, a few months ago, cursor, they wrote about how they were taking all the agent traces that all the traces that you that um they were collecting from ideides and they used that to fine-tune the embedded model to improve the performance,
right? And that is a form of continuous learning. So where we're going in the next 6 months is looking for how we can merge this agent loop with the training loop
efficiently.
Yeah,
that's where things will be.
It's interesting because I guess there's there's context which is very specific and will change depending on who's using it and there's context which is almost like that that learning like you say where it's like actually 99% of people are doing it like this. this is what they need.
And I guess it's that piece that can kind of like always get pushed back into that into that cycle of learning.
And then it's almost like the customization style context of hey, like the skills almost, right, where it's like this is a specific skill for me and there's other skills out there for for other teams, organizations or individuals. And if they want to do it other ways, they can do that. Um, but I I love the I love the idea of that continuous learning.
That's where it's going. We're just going to get the agent loop and the training loop together. Yeah, Richmond, it's been an absolute pleasure. I really appreciate you coming down and uh and also actually we didn't mention it at the start, but you're of course were uh one of our speakers at AI Native Dev in New York. Uh and actually for those for those who are listening, of course, we have the London event coming up soon. I think it's going to be announced by the time we're we go live. So, I'll say it's June 1st, 2nd in London. And maybe see you there as well, Rich. Maybe it'll be a pleasure. Awesome. Thank you very very much for for for for this episode and really really appreciate everyone tuning in. So thanks very much and uh tune in next time.