# Agent Memory Architecture and Context Engineering Strategy

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-03-03

## Transcript

Agents can be omnipresent.
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 are the kind of like differences or benefits of the approach of 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 out of cost.
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've got to invite you around to the podcast studio.
So, Richmond, let's give a little bit of background to yourselves.
Let's talk a little bit about your career and things like that.
You work with many companies such as NVIDIA and Neptune AI in the past, and you previously worked for MongoDB before joining Oracle.
Now, I'm a big Java person in my background, so Oracle, I work with a lot on the Java side and things like that.
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 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 again, thanks for having me on and 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 or 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 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 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 one of the key folks within Oracle Database that helps shape our products and features around reaching developers.
It's pretty cool, actually, that you went from Mongo to Oracle as well, because I remember back in the day, of course, when document-style databases came out, you saw the big rush to folks like Mongo and stuff like that.
But obviously, Oracle is so present in so many different organizations.
It's a big area.
Now, if we think about...
one area that you're very familiar with today, agent memory.
In fact, why don't we start by defining a few things.
When we talk about agent memory and memory management, things like 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.
as simply as I can keep it.
But if we just 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 so when we talk about context management, context engineering, what's the difference, I guess, between context management and memory management?
So we have prompt engineering as a role that people are 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, it's trying to understand the job to be done.
And because we're moving so quickly, we tend to just latch onto something that we think is something and then start to define roles around it.
Prompt engineering emerged probably.
two years ago, which is nothing.
Yeah.
Although it feels like about two decades.
It feels about two decades.
In AI terms, yeah.
And prompt engineering was meant to describe the key job to be done that developers were doing, which was actually using a bunch of linguistic patterns to actually steer the LLMs into a desired outcome, right?
We wanted the output to have a certain...
representation that will 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 robustness of the prompt itself.
So we went into context engineering, which is actually 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?
It's all context engineers.
It's something we're yet to see.
But memory engineering, I could speak to because it's nothing new.
Memory engineering is just a cross-section between a couple of disciplines, which includes database engineers, 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 the latency of the retrieval pipelines within a GENSEC systems.
And that's what they solely focus on.
But they need to understand software engineering and database as well.
Absolutely.
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 I'm very biased, right?
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 non-technical people.
So when I use human analogies.
folks understand me the general populace understands me yeah so memory actually is a good way to bridge the gap between people's knowledge of non-technical 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 they don't have the context yeah they don't have the there we go there we go but our memory really brings people into that same understanding um 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.
So it starts to allow you to think about ways you can improve 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 why I see everything as memory.
But you can argue maybe everything is context.
It's an interesting way to frame it.
I guess it massively depends on your perspective.
Exactly.
In terms of how you look at it.
One thing I'd love to chat about, we've talked about skills now for the last...
gosh, three, four weeks on the podcast.
I'd love to kind of like hear your thoughts in terms of, okay, skills, where do they sit in relation to context?
And even at Tesla, we have that question like, when we put stuff on the website, should we say skills and then context?
Well, you know, the kind of part overlaps as well.
Where do skills sit in?
It's very important to get the naming right within this space.
It's very hard.
Because it moves so quickly, you're like, okay, we can't use that anymore.
This month, we'll say skills.
We'll say skills.
Next month, we'll say something else.
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.
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 tasks 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, step by step 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.
It's just a way of telling an agent there is a task and I'm going to.
give an arbitrary name to the task then i'm going to describe the task 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 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 can do a backflip, where that knowledge actually 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 or 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 a marketing team here who don't don't tell them i i like marketing messages because 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 A human, let's call it.
If you had a human join the team, you'd have to onboard them.
And one of the things that we're doing, obviously, with context is we are onboarding, onboarding agents.
And so it's about, you know, humans need onboarding, 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 how organizations already have those procedures.
the standard operating procedures, they already have them written down.
If they're, you know, 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 a procedure, this is how you do it.
All you really need to do is take that, skillify it, if that's a word, and provide it to the edge.
It is now.
If we use it enough, it will be the Oxford English Dictionary.
So 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, a new developer to do that without giving them that information, we'd think, are we 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?
Let's talk a little bit about what leads on to what do agents need to be successful?
And I think a lot of the time we blame agents unnecessarily whereby actually we're not dealing with the agent.
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 need you 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.
It satisfies what you asked.
I say, no, we need to do it this way.
Where are the tests?
We need to follow this style guide, et cetera, et cetera.
We wouldn't do that to a person.
So what do we need to provide to an agent so that it can be successful?
We'll start a very simple answer to that is information.
We need to provide agents as much information as we can.
Then the second thing, the answer to that, 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 i happen to work in oracle and it'll be no surprise that pretty much all the fortum 500 companies or most of them are using an oracle database i heard you oracle do some work in data yeah i heard it did yeah 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 oracle has existed for over four decades and across our four decades we've seen different crucible moments and paradigm shifts.
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 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 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 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 Oracle customers is that they will have so much data.
I guess my two questions are, how do you get an agent to the right data, 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 much that it overwhelms it, but it's not, you know, so little that it doesn't have 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 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 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 firstly, it scans through all the tables.
in a database to understand 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 or Java code that is used to actually construct these tables and manage these tables.
Now, the agent understands the thinking that went behind the generation of these tables or what sort of data is stored or the transformation that happens.
So how do you get an agent to the right data?
It's by giving, it will be the answer to the last question, which is 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.
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.
This is what I would say.
In production, the data you encounter has a heterogeneous nature.
So you have vector, you have JSON data, you have unstructured, semi-structured data, you have knowledge graphs, 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 aspects 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 one shot 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 get?
It's such a huge room for us in Oracle, because again, we've existed for over four decades.
And you can imagine.
the amount of times we've seen the nature of privacy change.
the requirement to actually secure data change as well.
Different regulations from different governing bodies on how data should be stored, retrieved securely as well.
And this is embedded in Oracle.
It's embedded in Oracle database.
You have all the usual kind of like role-based access built in.
So it's about the agent.
So when I speak to developers and AI developers today, I'm going to be very honest.
security on a list of things we care about comes in...
You surprise me.
You surprise me.
Second to last.
I thought you were 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 last.
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?
The popular thing we have now is OpenClaw or Claudebot or whatever the name is now, or Moabot.
The security issues with that open source framework, and that's all I'm seeing on my timeline.
Because AI developers, 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 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 the 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 it's 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 an older user and team as a single user What do you see as the typical context that will make a single user more effective?
A single user.
So when you say a single user, you mean a single user interacting with an agent or an agent understanding?
Exactly.
Single user interacting with an agent outside of a team.
So let's say a single user interacting with an agent.
And I will speak from the agent perspective.
Go on, let's role play.
You be the agent.
I'll be the agent.
You be the agent.
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 front load this information of Simon because you have data.
in all the tools you're using and we can just ingest that into the agent's memory and it's able to then create a persona of you within his entity memory.
That's what we're going to store it.
We're storing it in his entity.
Humans have this as well.
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 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 of that.
We evolve what we know about Simon.
And this would be things like my preferences, my way of working, my stack, my getting to be with certain languages, the libraries I like to use.
Exactly.
And it's very important we start to identify the distinction of these different types of memories because...
We don't need to reinvent the wheel here.
Neuroscience has been trying to do this for decades, right?
Neuroscience has 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 role for Simon.
and it has all its likes and preference and you have different forms 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 chat gpt i always get this box that says do you like this personality yeah I'm like, no.
I'm joking.
Do better.
But you see that even people on the frontier of this space are trying to understand how we start to make these agents and computational entities believable.
We're trying to understand a persona and we're trying to modify this.
And this is entity memory.
You know the agents are being asked the same questions, right?
They're like, do you like the personality of this user?
No, I would like a new user, please.
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 user is the reviewer there, right?
The user is the person where when the agent provides something, the user goes, it works, but I want it to work like this.
And so knowing and understanding those ways of working the personality, how a person 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, this is the API.
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 accurately.
And so there's...
When we think about things that will, if we think about a lifecycle of 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 you get updates that the agent needs to be aware of.
So when we think about context.
generally.
What do we think about as the life cycle or the longevity of a piece of context?
And when we think about that, what are the things that we need in place to keep up with the changes that are required, to keep up with the update, the refresh of that context?
I'm going to answer your question.
But one thing is I'll answer it by talking about the life cycle of memory.
Well, you can switch out memory for context.
Yeah.
Right.
So life cycle of context, this answer applies to the life cycle of memory.
The first thing when we think about the life cycle and 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.
Then you start to do a bunch of encoding.
This is where we start to pass that data through embedded 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'll 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.
And that's very important.
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 of...
perspective of memory, you immediately start to, it becomes almost natural to know that you need to implement a way of forgetting information.
And in that life cycle, you need a way to suppress information, a way to at least...
make the way information is being recalled 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 in 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 lifecycle 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 deep learning, we have a technique called data augmentation.
So this is where we...
We basically, I guess now data is plentiful, but in deep learning computer vision, we used to have a bunch of images.
And the way that we actually 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 ways that an image could be presented to it in production.
This is called data augmentation.
We can leverage those techniques.
in memory engineering or in agent engineering today because the information that you get out of an LLM can actually be augmented by an LLM looking at the domain and looking at the information and you could actually 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.
I do this with either MCPs or scripts that I have is where I have functions or MCPs within 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 an embedding model to encode this information to generate an embedding representation, a much more richer embedding representation of the script so that I can then do something like use semantic discovery for some of the tools I have within my system whenever I'm working with an LLM.
Yeah, really interesting.
And I think...
When we have talked about single user, when we move to multi-user, the thing that makes this problem kind of like a little bit smaller for the single 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 prompt things to update and fix the data.
When we get into the multi-team perspective and you have a team of 10, 20, 30, I hear Oracle, Just beyond a startup now, isn't it?
What was it?
Small to mid?
How big is Oracle these days?
It's bigger than you can imagine, but it still operates at the speed of innovation that you would see at any startup.
Good answer.
Good answer.
So when we talk about bigger teams, you then have the problem whereby different people could have actually different context if they're holding things locally, it can get stale and stuff like that.
I guess...
There's 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 AI using developer organization, whereby context is important and context needs to be shared?
How do we go about that?
The difference between now and the days of before where you had large companies and you had people that had...
tribal knowledge and then when they left then the left of the knowledge is this agents can be omnipresent 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 can have the same agent in other tools you're using now when you start to see success when the agent is going through maybe 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.md for this specific workflow that wasn't documented by the person that just did the successful task.
Or you could just put it in some form of...
Skills, they're just workflow memory, essentially.
So agents are agents today are omnipresent.
They can...
go through different systems and understand 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 that loop essentially of constantly trying to optimize.
Exactly.
Maybe even how we react or how the agent does, you know, finds issues as well.
Let's go, we've talked a little bit about the database, actually.
Let's talk about a little bit about file system as well.
Because a lot of the time agents love to see what's on the file system.
And sometimes even when we say, oh, can you use this MCP server over here?
If it has 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...
you know, I guess, 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.
When you don't have to worry about infrastructure, components, and tool selection, you don't have to worry about, oh, what database should I be using?
Or what stack, what should I have in my stack?
And you're just using files.
You remove...
the thinking of tool selection.
The speed is there.
But that speed comes at a cost.
And the cost is security.
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 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 the 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, again, we've come a long way from the 70s.
I wasn't alive in the 70s.
I was just, just.
You were just alive, yeah.
So maybe, 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 almost like Groundhog Day because the same things keep repeating.
Now, again, in 2026.
I'm seeing articles where everyone is saying 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 concurrency.
You need ACID 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.
Exactly.
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 natural affinity with the LLM or how easy it is to interface with it.
What would you say looking forward now to RavPath, I guess?
Where would you say?
context and memory management are going, as models improve, because I remember, what was it, a couple of years ago when we were talking about prompt engineering all the time.
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 last hour or so.
But when we talk about context engineering so much, now context engineering is the hot topic or memory engineering is the hot topic for today to make agents.
you know, more accurate, friendier to work with, less frustrating.
What's the future path of this, do you feel?
As models get better, 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 what 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?
Prediction in AI is so bad because they're usually wrong.
We'll have you back in a year.
Yeah, exactly.
We'll grill you on what you say, whatever you say next.
So this is what I would say, right?
Over in Oracle, there is 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.
We've been talking about it for loads of years.
Like, yeah, you need data.
Okay.
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 these systems to work in near real-time or real-time scenarios.
Now, how do we start to make that happen?
How do we let this agent's process data 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'll give you...
where things are going or where I see things are going.
We 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, all the traces that they were collecting from IDEs, 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 six months is looking for how we can merge this agent loop with the training loop efficiently.
That's where things will be.
That'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 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 cycle of learning.
And then it's almost like the customization style context of...
Like the skills almost, right?
This is a specific skill for me and there's other skills out there for other teams, organizations or individuals.
And if they want to do it other ways, they can do that.
But 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 also, actually, we didn't mention it at the start, but you, of course, were...
one of our speakers at AI Native Dev in New York.
And actually, 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 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 this episode.
And really, really appreciate everyone tuning in.
So thanks very much.
And tune in next time.