In this presentation, Taranjeet Singh, co‑founder and CEO of Memzero, explains why AI agents suffer from "amnesia" and why a dedicated memory layer is essential. He differentiates true memory from vector databases and retrieval‑augmented generation, arguing that memory must be model‑agnostic, write‑capable, and more than just storage. Memzero offers a minimalist API (add, search) keyed by an entity ID, handling token efficiency and cost. The technical core consists of deterministic extraction and update pipelines powered by LLMs, a proprietary algorithm for balancing freshness versus staleness, and a graph extension for relational memories. Internally, Memzero uses a hybrid datastore that combines a vector database, a graph database, and a Redis‑style key‑value store. Research on the Locomo dataset shows Memzero (and its graph variant) achieving higher accuracy with lower latency and cost compared to pure vector DB or full‑context approaches. Real‑world integrations include BrowserUse, Revision Dojo, AWS Agents SDK, Mastra, Langflow, and Diffy, with notable token‑cost savings and longer agent task execution. The company’s vision is a universal "memory passport" and an Open Memory Container that lets developers carry memories across models. The team’s background (founder of the first GPT store, ex‑Tesla AI infra lead, researcher) underscores credibility. Key takeaways: every AI agent needs memory like every app needs a database; memory is dynamic understanding, not static storage; building it is deceptively complex. In the Q&A, Singh details the hybrid datastore architecture and the scoring system (relevancy, importance, recency) used to manage stale memories.
Chapters
Hello everyone, I'm Taranjeet Singh Singh. I'm the co-founder and CEO of Memzero, not Memo. That's a common misconception that we see people pronouncing us. And we are the number one memory layer for AI agents. And we have already been serving like a lot of agentic frameworks and customers out there. But let me first tell you, you know why memory is needed and why memory is important. Everybody is trying to create an AI agent, and in the flow that they are, you know, creating an agent, there is a critical limitation which AI has, which is like AI has amnesia. And due to this amnesia, there is a lot of problem that comes up. The first problem is, you know, models and agents tend to forget everything that you tell them, and this leads to user frustration. User have to tell them again and again. In this example, you can see that this user who is vegetarian is getting a non-vegetarian recommendation as an answer. And in real-world scenarios, when the agent is running over multiple days and week, even if you use full context window, that doesn't work. It will increase your cost and it will increase your latency. So I mean, our belief is memory is a default primitive in an agent. It's like every AI agent needs a memory, like every app needs a database. And now that I've talked about memory and database, the first doubt that comes to everybody's mind is, isn't memory a vector database or isn't memory a retrieval augmented generation? The doubt is valid, but the answer is no. Here in this case, you can see that a user who is diabetic and is looking for dessert as the answer. Will get ice cream because of semantic similarity. Whereas in case of memory, memory will understand that this user is diabetic and will suggest a less sweet option, most likely a fruit out there. And the next doubt that we hear from the market is, like, won't you get commoditized, or isn't this something that big labs can build it themselves? Sure they can, and they've already started building in their UIs, not in the API. But even if they build in the API, developers are using multiple LLMs, as evidenced by the growth of orchestration frameworks. Now, since they are using multiple LLMs and memory is just not read-only, memory is also write, it doesn't make sense to lock in your memory to a single model provider. It should be decoupled. So developers need model-agnostic memory. And the third thing we hear, you know, repeatedly across is like memory is very easy to build. It is not. It is deceptively complex. These are like minimum 5 pieces of system that any team who is building a proper scalable memory system has to build in-house. And due to this, a lot of product teams' focus shift to infra and they lose their core engineering cost and time. So keeping all of these factors in mind, we built Memzero. Memzero is the state-of-the-art solution. In just 3 lines of code, teams of any background can add memory to any AI agent or LLM application and we provide production-grade memory performance. You can see like it's just.add and.search. These are two API primitives and we need one entity ID in a lot of the scenarios that we have seen so far. The entity ID that, you know, developers and companies use is a user ID, but it can be custom, it can be team ID, it can be project ID. It depends on you as a developer or as a company. Of how you want to maintain the memory. And we also help you save cost because of efficient token management. Now let me explain you how we work and what's the, you know, technical sweet sauce behind Memzero. So behind the hood, there are two important pipelines that we have built in. The reason I'm calling pipeline because it's like deterministic in nature. We'll use a combination of the current message that you send it to us we'll go back and we'll figure out the relevant summary from past. We'll also go back and figure out the previous messages and we'll try to extract everything we consider as a memory out there. So that's the extraction phase. Now, since once we have extracted the memory, we will go back and we'll try to find out what are the previous references of this memory that needs to be updated. Now, that seems very easy, but that's hard as the system scales, as you get more and more information. And one thing with memory is like you have to consider what is a memory that should be considered as fresh and what is a memory that should be considered as stale. That makes it more tricky. So right now the entire pipeline, like for the extraction and the update phase that we have built in, relies on LLM. And we have like some proprietary algorithm built in which helps us keep the balance in check on whatever we are extracting. So this is like architecture 1. Wherein like we use these two pipelines. We also have a graph extension wherein in scenarios wherein we want to maintain memories which spans across like a relationship, like, you know, me talking to my friend or any entity relationship that, you know, the business or the developer want to maintain, we use a graph. Same logic goes there as well wherein we try to extract the nodes, wherein we try to extract the edges, and then we go back and we properly make sure that the graph is updated and we try to, you know, do all the checks and balances over there. All of this is available. We recently published a research paper. All of this is available on memzero.ai/research. And this is like one table snapshot from the research paper that we published a few weeks back. Here you can see we've used Locomo dataset. Locomo is a very common dataset released by Snap and USC. In that there are 4 sets of, you know, data types like, you know, conversational pairs, single hop, multi-hop, open domain and temporal. MemZero and MemZero Graph tends to perform better on, you know, mostly all the scenarios out there. And this is another table represented in a graph wherein we are trying to show you that if you use like vector database, first of all, vector database and RAG is not memory, but in the market they are positioned as memory. So even if you try to use or mimic memory via them or via full context approach, in both the scenarios, you will be on the higher side of the latency, on the higher side of the cost. You can notice the last blue bar, which is full context, which is 72.9. That's the accuracy that you will get from full context, whereas the bar just below, like before that, like Mem0 and Mem0g, you will get the same accuracy and that too at like a lower latency. So, you know, if you're running a highly scalable production app, Memzero, like a memory solution, makes much more sense. And tying it back to like why and like where can I use memory. So memory is a default primitive in agent. I think the market is now realizing that whenever you're building an agent and you want to, you want the agent to contextualize with respect to any entity out there, you need an agent. But these are like some high and bigger use cases that we have seen wherein like memory is relevant in healthcare, memory is important in education, memory is important in sales, customer support, and e-commerce. And giving you two examples of real-world impact. So we are the exclusive memory provider for BrowserUse. BrowserUse is the leading OSS memory— OSS browser agent framework. And there we are creating a direct business impact wherein we are first of all enabling their agents to run longer. It means that their agents initially, if they were able to complete like 5 tasks, now they're able to complete like 9 or, you know, 8 tasks out there. And we also help them save cost because of efficient token management. And on the right is a company called Revision Dojo. They are a YC-backed personalized AI tutor. We power the entire personalization piece for them and we also help them save token cost. So we are the number one memory layer in the market. We are, you know, powering a lot of agentic frameworks. We are the exclusive memory provider in the Agents SDK released by AWS a few weeks back. We power the memory for browser use, we power memory for Mastra, Langflow, Diffy, etc. And we recently crossed 1 million Python package downloads a month, and we're big on GitHub. And our vision is to build a memory passport which is going to be as universal as email, which will allow you, me, and everyone in the room to carry our memories, to own and carry our memory across any app or device that I interact with. And to do that, the first step that we have taken is we built in Open Memory Container. That's for engineers, wherein we allow any engineer to seamlessly own and carry their memory across Claude and Windsurf or Curser. So that's like maintaining conversation continuity for engineers out there. And all of this is achieved by a very small team. I built the first GPT store right when ChatGPT was launched and scaled to 400,000 monthly active users. Deshraj, who is my co-founder, used to lead AI infra at Tesla Autopilot. And Prateek, who is a founding engineer, is a strong researcher in agent memory. And, you know, just summarizing the entire presentation for you, there are 3 key takeaways from this presentation. First is every agent needs memory like every app needs a database. Second is memory is not just storage. This is super important. Memory is not just storage. Memory is Understanding, you know, what's happening and evolving over time. It's like dynamic understanding. And memory looks easy to build, but it's not. It's deceptively complex. Thank you.
Awesome. Awesome.
Starting off strong. I think we have a few minutes if you want to do some questions. Anybody has questions? Sure. I'll pass around the mic.
So I'm not familiar with your project, so maybe naive questions. But in the classic computer, memories have a lot of different architecture, has cache, and also has memory retrieval algorithms. Can you talk a little bit about your memory architecture? And do you have any kind of similar schemes as the classic computer memory?
Yeah, I think it's a good question wherein people who are not who are not so deep in AI have this doubt. My answer is, if you are talking about classic computer architecture, you can consider memory as something that there is a smart script that is taking information from like your hard disk or SSD, putting it into RAM so that the next action can be done, and then flushing it back. So that's what memory is. In like, in a real-world scenario, when like you're building an agent, consider it like a human. And as a human is progressing in his life, a human is learning information, that's like adding memories, and human is sharing information, that's like retrieving memories. So you can refer back from that. And just like on the basis of these two principles, the first architecture that we have built in is a hybrid data store approach wherein we use a combination of a vector database, a graph database, and a key-value store like Redis. So our first, you know, learning was that instead of putting everything into a vector database, if you you try to organize the information according to the database that it suits in best, half of the problem is solved. So we try to organize relationship in a graph database. We try to organize semantic and episodic types of memory in like a vector database sort of scenario. And we try to keep like facts and like, you know, things that most likely won't change in a Redis. So that's like, you know, first architecture that we have built in. And it relies on the understanding of— I mean, as I said, on the human and the computer principles out there.
Yeah, totally agree. So the combination of vector plus graph is probably going to be it. So are these architecture descriptions in your paper?
Yes. OK, great. Thank you. Thank you. Perfect. I think we do one more. You mentioned a problem with memory getting stale. Do you mind discussing some approaches that have worked and have maybe failed? Yeah, I think that's a very hard problem because since we are a horizontal layer and we interact with a lot of developers, every developer has different expectations. So the way we have built in— the way we have solved this problem, which is the first and second attempt, is we are using this concept of how many times a memory is getting accessed. So it's a combination. It's a scoring layer. That we have built in on the cloud version, which is using a combination of relevancy, importance, and recency. And we have a lot of background jobs running on the cloud, which will help us, which will go back and which will understand that, okay, today these many memories were accessed and these memories touch upon these past references, so we should increase their last access time so the next time they become more important. So that's what we tried and we initially tried doing like a lot of approaches around, you know, re-ranking. But so far, this is what we have. We are building our own custom re-ranker, which will help us in understanding what is something that should be prioritized. But the hard part here is that every domain or every business that we interact with has some custom logic.
