Latest / TeqTalk with Jas / Your AI Agent Is Missing These 4 Memory Layers

Transcript

Your AI Agent Is Missing These 4 Memory Layers · TeqTalk with Jas

• speaker-0: Thank you so much, Ajay, for coming once again on Tech Talk. Really a great pleasure to have you here. speaker-1: Thank you, Jess. ⁓ great to be back here again and ⁓ good to again talk about some of our favorite topics. speaker-0: Before we actually go ahead and deep dive into today's topic, tell me a little bit about your initiative. speaker-1: Sure. I would say probably I'm still very much deeply plugged into all things AI at Salesforce. The larger shift of focus has been more around how do we really get the go-to market and adoption up and running for a lot of our customers. Because what's happened is over the last 36 months or so of the agent force or the agentic journey at Salesforce, we've really been successful in getting a lot of customers on board the platform. But then beyond that first use case, we're really looking at how do we scale up them and that's where most of my time is going on go to market and ⁓ adoption driven. speaker-0: Great, very interesting. And today's topic, I know it's core to your heart, it is AI memory and the stacks around it. So I think the entire field of agent memory rests on one sentence. ⁓ it's the first principle of the paper, Koala, out of Princeton, and here it is. They say that language models are stateless, they do not persist anything across calls. You call the model, it answers it, it forgets. The next call again starts from zero. So the model never remembers anything, it forgets. So agent is what it adds memory around the model. Memory was never a property of model. It's always the architecture, what we build around it. Does that match what you see when any company says that we want to have AI to have memory? Do they realize they are actually asking you to build The whole system around the model that forget. speaker-1: Yeah, yeah, I think you hit the nail with it on that topic. One of the ⁓ definitely the more mature conversations happening right now is how do you really make AI ⁓ systems remember? everything that you've been talking to them and so on. So memory is almost assumed comes as a part of the model offering. People often tend to relate it to what they see on their left pane or the right hand side pane of the chat history in chat GPT or ⁓ cloud, but that's not what it is. It's much more. It's much more than the memory Associated with enterprise requirements. So think of this as like an enterprise agent, as like somebody that you hire in a company. Let's call them as the chief of staff or a ⁓ human executive. A memory that they can remember when you're talking to them, which is a current sentence. Of course, ⁓ think of the chief this chief of staff carrying like a notepad. For today's meeting. And then they would also have probably recall memories of some of the past meetings in their head. They also come from a domain knowledge. Somebody is in banking, somebody is manufacturing. As a chief of staff, there is a certain operating procedure. And then there is, of course, all the knowledge associated with that company that's stored somewhere. So what happens with an enterprise AI memory stack is simply these layers that is to be seen around this. And most of our customers, when they come to ⁓ Brand like Salesforce, they almost imagine Salesforce would provide these layers to them without actually looking at this as multiple layers. They assume that AI systems or agents almost offer these layers. And that's typically where we'll have to peel the layers of the onion one by one. And that's that's typically what ⁓ really opens up the more memory conversation. speaker-0: In this conversation, we are going to touch on two things. One is context, and the other one is memory around it. So let's start with our pillar one, which is context. I want to be clear, disagree with it, but context is not the memory. Lot of people blur this context is simply what AI can see at the exact moment. So your question, your goal, whatever we have handed it for one task. So context. To me, it is attention. Memory is what it stays behind after AI fades away or looks away. It stays a bit. And also there is a famous ⁓ Stanford study from 2023 that is called as Lost in the Middle. That says that they found that if you put something important information in the middle of a long context, the AI's accuracy drops more than 30%. I'm talking about 2023. And even in twenty twenty six, this has not changed much. The concept is still there. It's something called as context rot. So stuffing more than actually needed can really make AI worse. So what do you think about it? What context is, and what do you think are the disadvantages of having more context? speaker-1: Sure. You simplified the definition of context there. So the origins of context was basically because as you said, LLMs were starting off to be as stateless functions. We we'll talk about where LLMs are heading, will they have memory in the future and all of that later? But LLMs are s as of today, even still today, are mostly stateless, right? They do not remember anything between the raw API calls. What is context window is the active working space where computation really happens between you asking a query and think it is exactly what it is. It is the attention head, it is the prompts that get formatted and it is the cache that hits the LLM. And that is exactly what context window or active context is. Now if you move away from the topic of context window, which is where once it has actually come back from the model in terms of the response, ⁓ you're probably need to look at the other layers of memory, which I think we'll get into the discussions of. And context is probably, I would say, ⁓ tip of the iceberg. speaker-0: So I say that context is a budget, not a bucket. You shouldn't just fill it with a lot of data. What is your take on this lost in the middle? speaker-1: ⁓ what you brought up there is very interesting and it sort of is relevant to the adoption journey that we are seeing at Salesforce and many other companies also today. But to the point of what has really happened, context windows, if you look at the last 24 months, 36 months have expanded into millions, billions of tokens, right? The bigger context doesn't necessarily mean one thing better reasoning. Never bit big bigger context is never better reasoning. That is one definition I would almost put as like a textbook heading chapter. And as you rightly said, larger contexts often suffer from the lost in the middle phenomenon, which is exactly what the Stanford paper highlighted about. But there is also very much the other things that people don't talk about is the highest latencies and ⁓ cost of ⁓ exponential repeated prompts, right? So just to get to the more accuracy level, you'd probably continue to ⁓ stuff more prompts into the context printer and try to get more out of it. So from an up operating best practices perspective, I think not just us at Salesforce but also the whole world probably realize that context similar to language has always has to be very optimized. You can convey the same thing in a line, you can convey it in 10 lines, a paragraph, but it's about what you want to get out of that message or communication. And one thing that we'll always have to remember is these models are going to use the context, vectorize it, and then convert it back into embeddings. And embeddings are going to go back into what people call back as the spatial models and then try to find, ⁓ this text means this, hence the reference could be is this. So it's still going to be still very probabilistic. It's not ⁓ deterministic. So The more deterministic you want it to be, the better context or the better formatted context. So there are there are tons of best practices that companies try to put in. I know everybody's trying to optimize their prompts, ⁓ but over the period of one, one and a half years, everybody's realized let's put more deterministic controls closer to the execution workflow. And that will naturally smoothen out the context curve. If somebody's bloated up, bloating up the context, the deterministic layering that you will build around your workflows will pull the bloat down. And I think a company like Salesforce has already implemented this in terms of the agent script, for example. ⁓ Others outside are still thinking about it, how to do this. As a result of which, whenever I talk to ⁓ customers who are not yet using Salesforce, Agent Force, probably still struggling with accuracy levels. They still feel There's a lot of hallucination. Afterwards they realize, ⁓ maybe we need to give up on this project because it's not really adding value, but they don't realize the then they're messing up the context itself. speaker-0: Yeah, absolutely. That's a perfect setup and to have a great context we definitely need to have a good memory behind it. ⁓ so let's talk about different layers of memories. Again I'll refer to Koala ⁓ paper and ⁓ the first memory is the working memory and that is a short term memory. So tell me a little bit about that memory for the audience. what it is, where it should be located and ⁓ yeah, the best practices. speaker-1: Yeah, so good good point or good segue. So think of the short term memory as like ⁓ if you go back to that ⁓ scratch pad that we talked about of the chief of staff, right? It is the one that tracks the state of the current user interaction or the one loop today because everybody's writing loops ⁓ and as they're white coding. ⁓ it's that execution loop. And what an agent that anybody is building today needs is to have that memory or set of instructions. Which can perform those steps of multi-layer reasoning. Or let's say it can go and call five different functions, or it maintains a conversation between multiple systems without dragging useless artifacts that was probably interacted with this agent three weeks ago. So short-term memory is very, very well refined. It is very, very session specific, and it has always been very summarized, stripped of the ⁓ you could say transient noise around it and avoids going into the deeper layers as we said, doesn't go into what what happened one week ago, for example. And usually the best way anybody would architect a short-term memory is let's say technically if I switch the gears now, ⁓ if you go and use platforms like Redis, ⁓ in memory key value pairs, where you maintain the session states of what exactly changes. That's exactly what short term memory would look like from a technical architecture standpoint. And you bring it back to a business layer like Salesforce or any other application, you'll ne always need to think about it as very, very task specific, job specific. speaker-0: Yeah, I completely agree to it. So working memory is AI's train of thoughts. A lot of time people get confused with the context and working memory. So do you want to differentiate these two for the audience? speaker-1: When you say context, ⁓ you're typically even ⁓ looking at what is being asked. It's the prompt that you're actually typing in right now. The working memory could be the in session memory of what actually has happened in the agent's current interaction, like probably what you discussed with it five minutes ago. ⁓ a good example is if you open up chat GPD today or Gemini today, and let's say you put in a PDF and you want to ask some questions associated with it, summarize this for me. It is a context. Beyond this thing, it doesn't know what summarizes for me means because you're s asking this in the context. The the working memory is when you go down five minutes later when you're asking a lot of other questions, you can still go back and say, Can you rewrite the summary again? It'll continue to use whatever you've discussed and make up the the summary all over again because it uses the working memories output and then it can ⁓ re f come back with the final ⁓ answer. So that is how I would see as a difference for somebody who is just looking at ⁓ what is context versus working memory as a bare bone difference? speaker-0: Absolutely. And ⁓ once the session is off, so the working memory it is still active or it doesn't persist. Would you like to talk about this for talk? speaker-1: Good question. technically, by definition, the working memory shouldn't persist after the session is off. But today we could engineer it in such a way that the working memory could go back to becoming like the episodic memory, a saved session state. ⁓ that's typically how we end up saving a lot of session states for our agents as well, where we can look back on what happened? Why does this agent behave this way? So ⁓ by default it should end and that is a session state for that ⁓ particular agent's content. speaker-0: So if you have to get anything which has happened before, you can refer this as episodic memory. The question it answers is what happened last time I did this. And a simpler version could be episodic memory is AI's diary. Not the facts, ⁓ actual experiences or with a sense of what just happened and when kind of thing. I know that you have built this ⁓ before. What's the hard part? Is it deciding what is worth writing in the diary or it is finding the right entry later when you actually need it? speaker-1: It's the I think I think it's the latter. It's the latter. Because the moment we get into that zone, you'll start going into the next memory topic, which which I know we we'll talk about, semantic memory, because that's typically where more mature companies are wondering how well should we refine this? Particularly when they are in, let's say, a regulated industry like healthcare and banking. They have to deal with all these compliances, SOC2 and certain timeline beyond which the audit log shouldn't be maintained or shouldn't expire. All of this is very important. And none of this is written anywhere. And now the industry is now coming back to say, ⁓ maybe we should think of this is what episodical memory should look like. When we start extending the muscle of episodical memory and make something else on top of that, that's where semantic memory starts emerging. So we'll we'll we'll we'll ease into that topic as we go. speaker-0: Do you think this this layer is still getting matured? ⁓ speaker-1: I think so. Yeah. Yeah, I think so. It's almost like ⁓ people are trying to evolve from their maturity. speaker-0: About it. It's it's so you said that episodic memory is ⁓ really the raw material. The experience that later became knowledge and skill. Episodic is what happened to me. Next kind is completely different. It is not experience, it is plain fact. So you know what it is. It is semantic memory. And we keep hearing about a lot on this semantic. I think this is one of the mature layers, but instead of me saying that I would like to know more from you. speaker-1: I w I would say the one that we are about to talk right now is the one where companies and research labs are also paying a lot more attention and diving down. ⁓ because what's happening here with semantic memory is it's purely starts to become more fact-based. It's detached from general knowledge, right? It's in this case starts to become the agents, ⁓ you could say encyclopedia of ⁓ jargons that is very specific to that company, the domain knowledge that is very specific to that industry. ⁓ the standards that you talked about product specs. ⁓ And when an agent needs to remember certain things where you don't have to hard code a lot of that into the instruction. Like nobody needs to type in what really should be the limits of SOC2 compliance, for example. Right? It should be part of the semantic memory of that agent. That agent should be able to recall. Like if you talk to a an agent that works in a legal industry, it needs to know that ⁓ You cannot do a certain ⁓ appeal after a certain date of expiry from the ⁓ initial filing and so on. That need not have to be an instruction or given in the context. It should be part of the instructions at a system prompted level, if you could go to that. And you know, in certain sense, it's almost like the absolute ⁓ truth when you are trying to build an agent from the grounds up. What is happening there and why this is important is This is the basis on which the whole ⁓ retrieve augment generation even started, right? ⁓ that is typically where you have a lot of documentation structure that gets stored, and knowledge graphs are getting built out of that, and hybrid search has evolved from it. So I would say semantic memory has developed a lot of legs today. It's no longer just one box, it's got multiple other sub-branches. And There are many companies that have come up with different interesting product lines just be using semantic memory as a concept. speaker-0: Yeah. So episodic memory is what happened to me. ⁓ semantic is what I know to be true. One is experience, another one I would say is the fact. like how you mentioned that a lot of companies have started building the semantic layer or semantic memory and ⁓ they might not even call it a semantic memory, but something is already existing in this practice where AI looks up your documents and knowledge and provide all the information. speaker-1: I think the semantic layer in itself, ⁓ largely the first time we started thinking about semantics was ⁓ how do you deal with certain types of data? How do you handle certain types of ⁓ data types, for example? ⁓ that started way back when we were defining the relational databases of the world, RDBMS. And from there on, we started to build cloud systems and semantic ⁓ Layering became an important aspect of how you architecturally were building applications. Now ⁓ that semantic as a terminology is pretty much the it's carried the same meaning. It's the fact of how to do this, ⁓ how do you invoke this? And it's it is very, very topical, and some of it is very much embedded in how every company thinks. I would I would never put as there's a universal semantic memory available outside. Semantic memory. For Salesforce could be very different from the semantic memory layer or a semantics for SAP, for example. And I think that's where the protocols of the world are evolving. ⁓ we've now started to see beyond MCP, A to A, agent to agent protocol. Agent is agent to agent protocol a handshake between those semantic layers? Maybe. We don't know. The answer is it's still speaker-0: So the next one, ⁓ any guesses, Ajai? speaker-1: I I would almost say it's ⁓ either a a customer associated or ⁓ you would probably put it as procedure oriented. speaker-0: Yes. So the next layer or pillar I'm thinking to talk about is procedural memory skills. It is about how do you really do it? And it is the skills. These skills can either live in AI on its own or inside the model itself. Yes. So now we have got the full set. Episodic is what happened. Semantic is what's true. Procedural is how do I do it actually. And ⁓ some skills are written by the engineers and some the AI picks up and learn over the time. Okay. Explain from your ⁓ vantage point on what level of development are you seeing in the procedure. speaker-1: So as you rightly said, procedural memory is about all about the knowledge of how to do things, right? Like it's the it's the schemas and ⁓ standard operating procedures and so on. and the question of like why did we even think of another yet another memory layer? Because ⁓ semantics is about knowing the facts as we talked about. And episodical is about remembering the past actions. But it isn't enough for an agent to know which API to call. in order when to issue a refund without violating a corporate policy, for example. So this is where typically the procedural memory comes in. One thing that is often very important and that people forget is this is the memory layer that's often or most of the time deterministic. And you don't want and the reason why this was even thought of in the first place, going back to the AI research papers from Hart. Stanford and ⁓ a couple of ⁓ Oxford researchers, is you didn't want AI to hallucinate on how to write your SQL database function call. So that was the first time where I just started thinking about this. And some of the examples of what is being brewing in this space, like have we talked about ⁓ Salesforce's ⁓ implementation of agent script, which is this skill set now well defined to be more deterministic. That's where you are almost giving out that procedural memory of how to do this invocation. So there are tool calling, there is function definitions, open if you go and look at if you're working with OpenAI ecosystem, the open AI is function calling schemas, that's actually a procedural memory now model providers are providing. And if you go and work in an open source environment, like if you're using somebody is using like Langgraph, the state machines that Langgraph provides, that's a procedural memory. And ⁓ if somebody is using system and level instructions, that is also a procedural memory. So and if somebody is creating a model, for example, somebody's coming up with their own ⁓ small language model, large language model of their own, the fine-tuned ⁓ weights that you actually associate with the model, that's also a procedural memory. So it can take different shapes and forms, but ⁓ I think ⁓ to the use cases and examples that I talked about. ⁓ the OpenAI or Anthropic, for example, are working on, hey, how do we build our own long-term procedural memory for our customers, for ⁓ people using the models? In the same way, application providers like us are thinking about our own procedural memories too. speaker-0: Where do you think this memory maturity level is? speaker-1: I I would say it's still in infancy, ⁓ because it's not truly autonomous today. ⁓ it still does tend to make ⁓ poor choices in certain aspects where you have given ⁓ complete control of choice and authority back to the model. ⁓ you you will almost have to see it ⁓ going back to I would what I would love to see is procedural memory having a very strong dependency on ⁓ the episodical memory and semantic memory to go and make the best decision. It doesn't always do that today. ⁓ and ⁓ I think that's why I was saying it's still very much in its infancy. speaker-0: Yeah. So as you mentioned that an AI that improves its own methods sounds ⁓ very exciting. But are the companies really providing all the authority to this memory to rewrite its own steps by learning what has happened or people are human is still there in the loop? speaker-1: Yeah, I I would I would definitely say ⁓ human is still at the I I'll I'll probably ⁓ I've matured on from the last eighteen months to not say human in the loop anymore. I I would almost say human at the helm. Humans to be at the helm of it. ⁓ it's it's interesting to see which parts or which organizational elements could actually use this to true be truly autonomous because you don't want some Very random action to be taken because an agent loop decided this would be good for this particular business unit. A good example would be when somebody comes to Salesforce, for example, on help.salesforce.com asking for, hey, ⁓ I'm trying to use this product, but I don't see this feature turned on. I I'm not able to see this menu option available in my What our help.selves.com agent does is basically is indexed over 800,000, 900,000 documents. And it's a very, very semantically driven memory. But now, if this customer, it the agent also asks, would you like to connect your org? Or will you will you be able to willing to authenticate using your org ID? If the customer is willing to give their org ID, the agent can go in and further check if This feature capability is even available in their org because maybe it's available behind three other many options that they have not even hit yet. Right. So the memory here is very important where you can define is this agent having access to this memory to go and make these changes on behalf of the customer without them even asking. So in this case, a a mere lookup is also going and doing that lookup even without guiding the customer. Ten steps, right? So that's a simplest use case that we s often see in our day to day on our Salesforce. speaker-0: Public website. Yeah, and I would also like to share some facts. ⁓ those are very hard numbers, and I'm sure it is not surprising to you. You might be hearing that almost daily that Gardner expects more than forty percent of the AI agents project to be cancelled by the end of 2027. It's nothing new to you and me, right? Because of cost, unclear value, weak controls. Another one, IDC says 88% of AI agent test projects never make it to real world. And grant Looked over 2000 projects and found that more than 80% fail, about twice the failure rate of normal ID projects. But here's the line that matters most. In almost every case, the model is not failing. Teams don't fail because they have picked the wrong AI model. They fail on data, they fail on plumbing, they fail on the memory around it. Right? The gap between great demo and working. Product isn't the model gap. It it's a kind of gap which also includes memory gap. Does it what you also see with the customers working along with you? speaker-1: I think all those facts that you said is ⁓ almost turning out to be quite a reality in a lot of lot of customer scenarios, right? ⁓ the way it is being interpreted in a lot of ⁓ C suite boards is like intelligence is a utility now. But the context slash memory is your biggest enter biggest mote of any company. Models will come and go every week we there's a new model, but what will not change is the context memory relationship and the procedures that you have built around your how your companies works with your end customers. And that is the layer that everybody wants to control. And I almost see that as like the next exciting field. Like there is a which we'll talk about in like what are the future opportunities here. There's definitely ⁓ new career roles that will be created, new industrial ⁓ industrial opportunities that will be created around the technical stack as well. So it's an it's an ex a very exciting time. speaker-0: Yeah. So from your experience what are the problem people don't see coming until it is already live? speaker-1: Yeah, I would say not having a well defined semantic memory, what that means is you haven't spent time cleaning up your data of what is the right data set that has to go into an agent. speaker-0: A huge and I think everything is related to data only, right? speaker-1: So true. That that is probably ⁓ a good example. I don't know if we talked about this last time, but I'll ⁓ give a a really interesting example. ⁓ I won't name the name the customer, but ⁓ they were they were actually self-implementing ⁓ the platform that they bought from us. And ⁓ they are a car rental company. ⁓ they you can rent cars ⁓ get chauffeurs and things like that from them. ⁓ pretty much a a 30, 40, 50 year old business, I think. ⁓ spre spre spread across a few regions across the globe. Not not truly global, but f ⁓ regionally global. And ⁓ they implemented the agents working well, ⁓ quite happy. They come back to us six months later saying, hey, ⁓ our ⁓ agents has given out over 500k USD worth of discount vouchers, which should have actually been given to premier customers only. It's actually randomly distributed to everybody and anybody by giving them 80% discount, 90% discount on their current bookings. On one side, the company was very happy because they were getting customers by the word of mouth marketing. People were sharing, ⁓ I'm getting 70% discount, just go and sign up here. But they didn't realize. They were burning down on the discount team department. The discounting team audit only came up six months later, and they decided to pull the agent down, saying maybe something bad is happening here. And our teams had to go and investigate, and it was basically the way the instructions were hard-coded for this agent. ⁓ And that is the semantic memory not being well defined. It's a real-world bad actor example of what an agent could do when It is given real financial motivation to go and do our discount watchers. speaker-0: even a small thing can make a difference, right? In the in the revenue. speaker-1: It does. It does. And I'm sure all the CFOs are writing over. speaker-0: Wonder why it took them six months to identify speaker-1: The discount team is probably often seen as like a marketing expenditure. And as long as they were generating leads, I don't think they were paying attention. And the discounting team's budget for the year hadn't turned red. And it turned red mid of the year, where they had already overburned the budget. And that's what caught their attention. And then everything was like reconnected back to ⁓ it's this agent that is causing the issue. But it's not just the agent, it's actually the context and the semantic ⁓ mentions. speaker-0: Yes. Yeah, so see s as we spoke before that human in the loop is really needed. So where do you think most of the enterprises are struggling? One is defining the semantic layer. Is there anything else you want to touch base on? speaker-1: Yeah, I think I think what is still immature is many of them are yet to fully refine the episodical memory. ⁓ because what you can still go and get production grade ready tools and platforms today is around your ⁓ working memory, you know, the ⁓ procedural memory couldn't be sorted really well. There are tools and platforms, but episodical memory is very, very much yours. And companies who do not know how to even get started in that direction are struggling quite a lot. And ⁓ as we discussed, bad data in is only going to give ⁓ bad data out. And many companies do not know the quality of data. ⁓ then one of the many reasons why you would assume Salesforce invested quite a lot to acquire a company like Informatica in the first place. Because we realized there's a lot of customers out there who still are operating with poor quality data, which can actually get better. And we are thinking, how can we actually make it better for them while the agent is in action? Can the data cleanup happen in the flow? ⁓ not not not everybody's thinking about it. So I think people need to think about the data cleanup pipeline stages before something even goes to the agent because otherwise you're just probably burning tokens and spending a lot of unnecessary prompts and context for ⁓ Wa data that could have been better called. speaker-0: We have been seeing working with ⁓ regulated customers, regulated industries, and the kind of data they are holding, it's from years and years and decades, they do not have the visibility. They do not not even single person has the whole architecture of what is my full data looks like from where it is coming and all of that. So I think it's gonna take a while, but you're absolutely right that Bad data in is only going to give you garbage data and output. Let's ⁓ fast forward to maybe three years from now. I'm not taking five years because every day is a new day. How will enterprise memory you think is really going to evolve? Even if it is a imagination, it is okay. speaker-1: I'll I'll I'll take a practical approach to look at like what what's about to happen next year and then we'll re we'll reimagine the future two years from now. Like the next year or so, if you look back at what's happened five last five years, right? Like with the models evolving, the whole field of ML ops ⁓ evolved, right? There nobody had thought of ML ops as a as a vertical that people need to go and think and build and ⁓ even have roles and career opportunities. There's a new category emerging called as Memops and Memory Ops. And memory ops will be amazingly giving out problem statements that will be around how do you handle the lifecycle of memory changes? How do you do garbage collection? How do you do security audits for what is changing and what is not changing by the agent memory? ⁓ and ⁓ the ⁓ the questions that I keep hearing from ⁓ builders around is should we Again, go back to putting it back on a blockchain because we can audit it better, versus should it should there be a different way to audit it? and I think that's what the next year looks like. There's a lot of engineering problems that are about to open doors, which people had not thought about before. ⁓ the two years from now, I would almost see ⁓ the self-healing capabilities for memory, ⁓ which may include ⁓ the capabilities that I've talked about Informatica. Informatica does back within it a lot of power like ability to do data cleanup, data duplication checks, ⁓ data lineage checks. A lot of these are feature parities today, but imagine these being available within your memory's capability. That every time a new data is being inserted, the agent that lives within the memory layer is able to automatically say, Hey, don't don't bring this inside because This already exists. So even before the context journey is complete, it might just prompt the user ahead of time, say, just wasting your time and effort. It's already flagged up upstairs to you. So self prompting and self-healing capabilities for the agent or the agent episodical memory, for example, I think is definitely on the horizon in the next two years. ⁓ the real, real distant future is ⁓ Ma memory that can actually continue to exist on the edge. I think that's what I'm excited about. That actually can be on the flight, that doesn't have to really depend on the large language models in a way. And ⁓ everybody is looking forward to what does that small, on the edge ⁓ memory look like. There are different ⁓ providers coming up with different contexts. If you're working with like devices that can actually record your voice and transcribe meetings today, ⁓ that is only unidirectional. It's not telling you what not to do. I think that there is a future state where it will complete the other side of the loop as well. speaker-0: Very very interesting. ⁓ last question, Ajaya, what should leaders begin to invest today? speaker-1: Yeah, I I would say simplify the use case. ⁓ with the most complex one, you're actually bound to ⁓ s l get to the less successful path very easily. And that's one of the ⁓ scenarios that we've seen after having rolled out thousands of agents from a Salesforce's perspective, customers who start with the least complex use case journey and then take the success blueprint and then expand. are most likely to advance and be very successful in the future. ⁓ the disaster stories that we keep hearing through the MIT reports or the Gartner stories are all because they started through the inverted funnel approach. They went and did the Big Bang approach of the use case and only to realize 90% of the plan had to be thrown out. Yeah. So ⁓ that includes the data strategy. That includes how do you come up with the right memory architecture? That comes up with do you even have the right Upskilling for your people who are actually going to be working on this project. And how do you keep that ongoing continuous loop of upskilling as well? Because models are changing. Memory architectures are in a way evolving. So you need to keep on with that pace. So I would say it's a a combination of several things, ⁓ but it all comes down to the right investment and the right use case. speaker-0: Great. Amazing. Thank you so much, Ajay, for your time. It was wonderful talking to you again. speaker-1: Thank you very much, Jess.