Latent Space: The AI Engineer Podcast
Original podcast
Watch the full show on YouTube: https://www.youtube.com/watch?v=Io0mAsHkiRY
5,160 words · 2 speakers
Okay, here we're here in a remote studio with Dravia Shah of Supermemory. Welcome to Lanespace.
Thanks for inviting me.
Yeah, obviously you've been blowing up on the timeline for multiple years now. I just found out you launched Supermemory in 2023. It feels shorter than that, but also you've been doing this for a while.
Yeah, I've been in this space for way too long. Supermemory has been many different products, but now it's everything at once. I'll get back into that, but yeah, lots of thanks.
So what is this, Laura? We looked back at your first product launch. You can show us, what was it originally?
Let's walk back from there. So Supermemory launched as this consumer app that was supposed to be your kind of
better bookmarking or note-taking tool with a few other features. So like, for example, you can take your memories across LLMs, and this is from very long ago. So we had an MCP launch, and then we had another launch for the app itself. So earlier, obviously, it was just the app, which was like a save. You can save things to the app. You can get things from the app, very simple as that. And then we were like, okay, MCP is a thing now, so we should probably make an MCP out of it. And this was a time when I personally was doing internships. I was working at Cloudflare at the time, and this was a side project that I did as a part of this thing called Buildspace. And Buildspace, you might know about Buildspace.
It was like this place where a lot of builders used to build things nights and weekends, and they really pushed you to building something and like talking to users and stuff like that.
Yeah, it's like a Gen Z accelerator that like they, the founder just gave up and just like moved on.
Exactly. So I was in both season three and season five of Buildspace. And I open sourced Supermemory during Buildspace, and it like the project absolutely blew up. It got like, you know, it was one of the biggest projects, like fastest growing projects of 2024.
And I I kept tweeting about how I'm running this on Cloudflare on five dollars a month budget. And it was still a consumer app, but then I kept adding features to it. So earlier, the way we, the world used to think of memory and how we used to think of memory was just rag. So you just embed it, put it in a vector database, and that's all you need to do. And now then I like dug down the rabbit hole and so so vector databases like at that time and even now, except a few like like Turbo Popper and Chroma. Were not really scalable for the scale I was getting to, where they were either getting too slow or too expensive to run. And so I had to, you know, find other creative ways of making it really cheap for me to run.
And I kept tweeting about all this. So my tweet was like, I run Super Memory on five dollars a month and I have a hundred thousand users. And this is my architecture. So it was like an entire diagram. And that blew up. That was the first kind of, you know, uh, famous Super Memory event. And that led to not people being interested in the app itself, people being more interested in the infrastructure that I was building.
Yeah, I remember you open sourced it and now I was like, oh yeah, I need to start and fork this because I'm like, if I ever need this, I need, I need this setup.
Exactly, exactly. So after starting it and like after that open source, you know, it blew up to like ten thousand stars in a few weeks. But then I realized like, you know, a lot of companies were reaching out to me. They were like, hey, can you help us set up our memory thing? And I also went and worked at other memory companies. And it became like this entire thing that like I was doing pretty much a lot of consultation work around context engineering. Um, I realized like all of these have very similar use cases, but with slightly different flavors. Where they they not only need retrieval, they need like like true user understanding and we'll get get to that as well. Like what is modern memory, you know, like how should AI remember? And then I was like, okay.
So to make an L L M truly good at understanding a user, you have to handle four things. One is knowledge updates. So you have to invalidate stale knowledge and build on top of it. Which is different from the storing vectors. You have to have some sort of temporal reasoning. So you have to have like give the agent an understanding of time and how things have passed for personalization. And you need some sort of forgetfulness to forget things that are not relevant anymore at all. But you also need this concept we call user profiles to always like memory is not just a retrieval call. The L L M has this very small profile of the user that it will utilize on every single turn. So I I was building all of these components into super memory and on all of these apps.
And I realized that, okay, there are some really difficult infrastructure challenges to be solved here, which is both on the extraction layer, which is how do you truly like, you know, how do you train a small model that can extract things about the user and maintain the second layer, which is the knowledge graph. And the way we we built our knowledge graph is different from how people usually build knowledge graphs. So people usually have this concept of triplets.
Triplets.
Where they have.
Object predicate object, yeah.
Exactly. Object predicate object or entity relation entity. And we think that triplets actually give to worse performance because you have to traverse them a lot to get to any information and like you can just think of this.
This is the learning of every graph guy ever.
Exactly. Exactly. So you have to like to to to find out like, okay, what the what food does Dravil like? You have to first get to the entity Dravil and you have to traverse one or two layers deep to find out like, okay, Dravil likes food, Dravil enjoys this thing, et cetera, et cetera. And that leads to extremely slow and like this is just unnecessary. So we built our own knowledge graphs, we built our own extraction pipeline and I was like, this consumer app is probably not useful anymore. This core infrastructure is more useful now and that is our core business now and that's what we offer.
Amazing update. Um, I think one of those things where like, I think we can get more into it. Uh, what what is super memory today? Like, is it a cloud business? Is it a V C backed company? Uh, you know, you're you're a young founder, like, tell people more just about the company itself and and what it is today. Because obviously we spent a bunch on the backgrounds. Yeah.
Yeah, uh, well, I I should have done this before, but uh, all right, I'll give you a little bit of an intro about myself first. So I'm Dravil, I'm currently twenty years old. Before this, I was working on agents and databases and a bunch of other things at a few companies, including Cloudflare, HiveFury and others. I had two companies acquired and came to the U S. So I built SuperMemory again as this thing, raised three million dollars um last year. And since then, we have been a VC-backed cloud business that's mostly open source, actually. And we are trying to build the context infrastructure for the AI era. And so what do I mean by context infrastructure? Whatever external context or like that the agent would need, including just retrieval to like user understanding, memory, et cetera.
Like self-improvement, self-learning, personalization. We provide all of these in this one single tool, which is SuperMemory. Because the way we structure the data, we can automatically provide all of these facets. Because again, every single memory use case would require a different way of implementing it. Um, and so we do that for developers. We provide an API for people to use, but we also still have a consumer-facing app, which the the idea is that you have your own memory that you can utilize across everything you use. Or you can add SuperMemory to your agent to make it much better at remembering things. So for example, the OpenClaw thing was blowing up, or Claw code blew up as well. It got like two million impressions.
Um, both of them were kind of this consumer-facing like plugins that we offer.
Yeah, it's a it's really impressive to watch. I think a lot of people, I'm gonna put OpenClaw in the in the title of this thing. Let's let's go right into the OpenClaw thing.
Let's do it.
You know, there's there's there's more to go into SuperMemory. I think more people can check it out. You've published a lot of stuff, but the topic of the moment is, I think, was it Peter Levels or something? Somebody is having problems with OpenClaw memory.
Everyone, everyone has been.
And then they're like, wow, okay, how do you do it? And then and then there's like all these different answers. And I'm like, wow, this is really not solved.
Yeah, exactly.
Okay, so so tell everybody what what's going on.
All right, so let's first talk about how OpenClaw currently handles memory. And I have like this little Claw artifact that I prepared.
For my article, but so the way OpenClaw has with Q M D or with whatever memory plugin you use, it inherently relies on tools to search through these memory dot M D files that it prepares. So you know, like what did I decide about the API, then agent will decide to search and sometimes it won't decide to search, which is probably the biggest problem here. And then it will get some results, it will do some scoring and then it will return it back. So, and the search right now is through the memory dot M D files or the memory folder. So if you, if the agent decides to not remember things explicitly, it will never show up in the results. Because you don't know what to remember at ingestion time.
So there's a bunch of issues here. And because these files are static, they don't handle updates, they don't handle uh like the forgetfulness I was talking about, there's no temporal reasoning, you cannot look at particular parts of the file because you don't know what is there and other problems like that. This like, you know, this is the reason why everyone is complaining about OpenClaw's memory.
This to me is surprising because when people complain about OpenClaw's memory or when OpenClaw even did the memory, people didn't like look into how exactly and why it's bad. So we did all of this digging in and we were like, okay, what is the right way to do memory? And we already had these plugins for Claude code, for open code. So we had a lot of learnings about how agents should be set for them. So we basically turned the tools based approach to hooks based approach that actually is reading from the super memory graph, which keeps the content fresh. So it handles updates, et cetera, et cetera.
So now, you know, for every tool call or for every user message, a hook automatically will put less than two thousand tokens worth of information dynamically. Um so the entire context will not have more than two thousand super many tokens. And optionally, it could also do a tool call if it needs more information.
And we have like contradictions, resolution, we have temporal reasoning and all of that built in. So the information is always truly fresh, no matter what. That's the gist of it, but we can dive more into it. Uh, because like there's some things that are not in this diagram that we also do. So yeah, uh, that's kind of the simple why super memories is better.
Q M D is is from Toby Luka, which is like really super impressive. I think it's a very interesting, is that basically Toby wants to do everything locally. You obviously are Claw Flare Maxi, so you're gonna do a Claw Flare.
Yeah.
So obviously that's like a fundamentally different thing. I think Hookbase is probably right because obviously models make mistakes. And I get very, very frustrated when like I use Grok in X A I and it doesn't search tweets. Like I'm dude, there's only one reason I use Grok is to search tweets.
Yeah, you have to like ask it like, please use these tools. And most of the open claw users don't even know that tools are a thing. So they don't want to think about the tools. So, yeah.
You think, do you perceive that they're not technical? I mean, it's, you know.
Especially, you know, a lot of people have been seeing they are technical in the engineering sense, but they're not technical in the agent's world. I think we're in a huge bubble right now. And like they won't know that, okay, this is exactly what's going on behind the scenes. Like they would not even look into it. Um, so, yeah.
It's just curious because as an engineer, you should, this is, obviously you and I think that this is the only thing that's interesting. But, uh, you know, there's many other engineers who have realized. Yeah. So, so, okay. I, I think other than this, there's another memory discussion. That I think Cursor and Claude, those guys have been saying, which is like sort of file system based memory, right? Like where you just, you put, you dump a bunch of whatever dot F D to your file system and then you grab over it. And Open Claw has some compaction, right? Like some, some, some heartbeat stuff. What are your takes on all those things?
So I think file system memory is actually the right way to do things in a lot of cases. Like for most Claude code users, that is probably the right thing to do. But you still have the same problem of you have to know what to remember in order for it to remember things. So you have to explicitly mention that, okay, please remember this or please bring this up. And it's limited by the files themselves. So the files can get longer and longer. So that becomes a problem. So you have to split between many files. And the files still don't have any update logic, et cetera, et cetera, unless you explicitly have the agent do that. They are also really slow to traverse through. So you'll have to do agent discovery to find out any context to answer any question. Like for example, if I have something like implement its workflow.
It will have to, you know, first look through everything it knows in the memory, all the workflows, et cetera, et cetera. And then it comes with the answer. Now, I think this is a very hot take, but I think that they could like one is personalization, which I'm talking about. But then there's also code indexing and they could index the code and cursor does, but Claude code does not. And I believe this is also because they are not incentivized to utilize less tokens by the end user. Because they're just offsetting the cost of indexing, et cetera, et cetera, to tokens and time that the user takes to run the agent. Which is, which is what they want. So theoretically, you could add like code indexing, you could add personalization.
It would be much better and faster. And I'm not just saying it. We actually ran a benchmark just yesterday. I published this blog as Shermanskin again. I published this like extremely technical report, which also kind of blew up. But we ran a benchmark on long memory against three things. Oh, the screenshot is in one of the quote tweets, I think. Uh, how do I view quotes? Twitter UI keeps changing here.
So the Claude code one performed the worst and OpenClaw slightly more than that and SuperMemory is the highest. And you can see that, you know, it's like a pretty significant difference, like almost fifty percent.
Let me, let me clarify. This is your reproduction of the Claude code method and your reproduction of OpenClaw? Or you actually use Claude code?
No, it is our reproduction. So it's like pretty much.
I think it's important to say, yeah.
Yeah, it is pretty important. And you know, we also think that benchmarks should not be trusted and cannot be trusted. So like, you know, you should not listen to me, actually. So we built this open source kind of benchmarking evaluation platform like Grok's Open Bench. It's called Memory Bench, which I also share my screen. So we, like, this is our implementation of exactly how it's doing. In fact, we also literally like went into it. We implemented OpenClaw's hybrid method with the same formula, with the same everything.
And you can just view the P R to find out exactly what's being done. But in short, this memory bench is a way to benchmark any providers against any benchmarks, against any judge on the same kind of the base rules. And this lets you quantify all the things. So not only the quality of how the memory system performs, but also the latency, cost and other like, you know, uristics like the top K recall, N D C G, et cetera. So this is like our really good way of doing, you know, benchmarks for memory. And it makes it really simple as well. I actually asked every single competitor to use this because it actually makes it easier for our competitors to compare against SuperMemory as well.
Yeah, I think that's a very good infrastructure. Okay, yeah, people should try that out. Other than, uh, just, just while we're on the topic of benchmarks and all that, there's long memory valve. Um, what's not so good? Whatever you want to say.
Yeah, so I think we are still not there in the memory benchmarks space. And there's a lot of reasons behind this. I might also write a detailed post about this, but I think that Long Memeval is a very good benchmark because it calculates, it tests for the right things. It tests for the right things, the data set is great, everything is really good in Long Memeval. Except for the fact that you can win Long Memeval by remembering as many things as possible. Like there's a direct correlation to the number of memories extracted and the score you get on Long Memeval.
Okay, that doesn't seem bad.
Because, yeah, it's not too bad, but like in real world, you would spend more cost. Like in real world, you don't want to extract everything because extraction is not free to win against the benchmarks. So it's good for like some use cases, but in the real world, that's not how people expect memory to work. So we think that that's fine, but Long Memeval also does not test for forgetfulness. Because how would you test if something should be forgotten or not? It tests for updates but not forgetfulness. And a few other things. So we still use Long Memeval because that's the best we have. Then there's Locomo and Locomo is like really bad because like and and people actually, it's not just me like pretty much everyone knows that Locomo is not the right thing to to judge on.
No, no, I don't know why.
So the the reason is like Locomo is essentially testing for retrieval capacity. And it's not testing for the real memory things. Like you can essentially just context dump everything in Locomo and get like hundred percent in the latest models. So one is the, there's only thirty questions, like the the data set is really small. Second is it does not test for like knowledge of great temporal reasoning, multi-session, all of the the other things, like the important things. Like preferences, it doesn't test for anything but retrieval. And and like in Gemini slash or whatever, like you can just literally the the questions, the sessions themselves are short enough that you can put the entire session in these context lengths and it will work right away.
So I think and it's also very old now, like in that age, it it probably did make sense, but now it's been three, four years since that and the models have gotten much better. There's also Convo Mem, which I actually like. It's a really good one. It's by Salesforce. And it tests for more assistenty use cases, like like assistants should do both RAG and memory, et cetera, et cetera. So that's pretty good. And Sometimes you need both, which I also want to come to actually. But that's what I think about the benchmark space. There's one important thing, which is there's no concept of benchmarking user profiles. So all of these benchmarks are very retrieval heavy.
Like factual information.
Yeah, like you, you essentially want to, you know, fetch something, get an answer, answer the question. But that's not all use cases. I'll show you one, a slide here quick, which will make this very clear. I have it already right here, luckily. So traditionally, you have this retrieval thing that happens. So you get a question, you retrieve something and an answer is generated based on that. But we think that it will not work for most non literal questions. Like find the best monitor for me. If I've never spoken about a monitor, which I probably have not, it will not return anything. It'll be like, oh, it'll give some generic answer. But agent probably needs to know a lot of default things about me at all times.
Like user is a C E O. But it also needs to know some episodic information, like user recently raised fundraising, moved into a new office last week, et cetera, et cetera. And in which case it will be like, oh, you code all day and you just moved into an office. So this is probably the one that you should buy. It's a little expensive, but this is the one for you. And this can only be done if you really have like a very extremely small, like 500 token information about the user that captures both the static things and the episodic things, like some recent episodes that's been going on. And we also have this built into Superman, but there's no way to benchmark it.
Yeah, it's basically personalization, right? It's a bit hard. Okay, uh, you know, I just want to close the loop on anything open claw related. I think people are using a lot of things. Why their issues crop up, like things like secrets, things like context confusion, if they've done like similar things, you know, like there's a, there's a trade off between retrieval and accuracy or recall and accuracy, right?
Do you, do you, do you find these kinds of things and like, what are people doing?
Yeah, so I think like, so the way OpenClaw does it is it essentially sends back the last fifteen messages in the conversation. And it essentially uses that back and forth. And I mean, the approach itself is not ideal because you will, like, you are not doing any, like, you're not utilizing any cash tokens. And because you're not utilizing the cash, you're essentially paying like insanely like ten X more than if you would do it the right way. So that is always a problem. So like, we think that, but that's like an open flaw issue, you know, we cannot really do anything about that. The other thing is people are giving it access to their secrets and stuff like that.
And we have to like, as a memory system, we have to like, make sure that no secrets end up to us, like in any case, um. A lot of users in OpenClaw also have like really, like browsers attached and stuff like that. And heartbeats and heartbeats are all going on, you know, every hour and the heartbeats are also ending up in memory, causing some pollution. And some people want to use their open claw memories along with their claw code memories and we actually want, don't want to do that. Like it should be siloed, like it's their own things, but people want that. So we are offering configuration. Recall wise, like, you know, super memory sometimes does not end up giving the right results.
And that's why we recently shipped a new thing for OpenClaw. So it was a, a huge learning experience for us. It's called hybrid mode. There's always a state of between what you want to remember in a memory system. You always have to choose exactly what you want to remember. Which is important because you want to keep them updated, you want to keep them fresh, you want to forget things. But sometimes the user, you don't know what the user will ask about. Sometimes the user will say something that was not remembered, or was not very significant. So how do you handle those cases? So the way we do it is we have, because we do both memory and like managed rag. We can show up the memories if they exist, but we have a fallback to rag answers, like it will just return the raw chunk if.
So many did not remember it. And then in the background, it will add that to the memory as well. So this, this essentially gives you like, you know, like we say that so many should almost never forget anything. Because of the fact that we are always giving the agent the right context as long as the user is asking for it. Um, so yeah.
Amazing. Are we going to the hybrid stuff?
Yeah, so this was the hybrid stuff. So essentially, you will return the memories first. And then if there's any raw chunks that match up, we also return those to make sure the agent knows just enough information to answer the question. And no other provider does this right now. So, yeah.
How so? How important is cost? Like, my perception is people are very cost insensitive. But you obviously, like, anyone who's like a real engineer, um, does care about caches and all that, uh, I don't know.
Do people care?
Yeah, I I think people care a lot about cost, actually.
Okay.
Like, I think, again, we are in a huge bubble and a lot of our users, especially, like, you know, they do care about the cost because, like, because people would compare a memory system against the L N M they use. So if the memory system is, you know, ten dollars for a million tokens, and L L M they use is two dollars per million tokens, it will be like, oh, like, this does not make sense to you. It's too expensive. I should not use this. And this happens to us. And we want to make sure that, like, we're giving them a lot of, you know, a lot of satisfaction on, like, they should be happy about using super memory and should not be something that, you know, they have to be concerned about. So for us, we have optimized our infrastructure down to it costs us two cents
for a million tokens, because we have our own model, our own database, our own everything. So we have to price our users also really low, which we do. So, yeah.
Okay, cool. It's a really good sort of masterclass in everything, sort of memory, uh, state of memory, in- including a side tangent on on evals and all that. What's next for Super Memory? Like, what is sort of the open directions, uh, for twenty twenty six that people should think about?
Yeah, so twenty twenty six was the year we realized that the prosumer aspect of super memory is something that people are really excited about. Like, this idea of having this one memory that you can connect everywhere, you can interrupt between providers and stuff like that. And we are continuing to do things like that, like, we're going to launch the plugin with Cursor today. And we already have the claw, open claw, open code, all of those. That's good. Next up, we are going to do a launch on voice agents partnering with pretty much every voice agent company because of the fact that Supermemory is so fast at the work it does. So it's really good for voice. That would be amazing. We are doing more on evals. We are building our own eval.
We are going deeper into personalization because we think that no one has done a lot of work in personalization yet and a lot of other like we are building a new version of our database. So yeah, it's going to be really exciting.
Cool. Well, thanks for jumping on. I think this is a great introduction, at least for Liz's listeners to Supermemory. Obviously, like you've been plenty famous on your own with your with your projects, but I think I already invited you to World's Fair. I will see you like do more talks for that kind of stuff. And I think just generally, I'm starting to see real startups and people taking memory seriously compared to two, three years ago when it was all like vector data.
That was a joke.
I think it's really good. There's more coming, you know, like the Langchain has their own take.
You know, I think all the others.
There's Leta, Langchain, Memzero, Zap. Yep.
Both Leta and Zap have done workshops, so I think it's your turn.
Yep. Amazing.
Looking forward to that. Okay, cool. Good to catch up and I'll see you online.
Great. Thank you so much.
Page updated October 24, 2026 · transcript and summary are machine-generated
