“You cannot expect deterministic outputs, but can you expect consistent outputs? Yes,” said Diwank Singh Tomer, co-founder of MemStore (formerly Memory Store), a shared memory system for teams and their AI agents built by the founders of Julep AI.

Tomer and co-founder Ishita Jindal spoke to MediaNama on November 2, 2026, as part of research for MediaNama’s upcoming report. They explained how agent memory is organised into episodic, implicit, prospective and semantic layers; how contradictions between records are flagged rather than silently resolved; and how guardrails decide what enters and leaves the store. Jindal spoke about what is worth remembering inside a company and about memory for the processes a team follows every day.

On deletion, a question that matters under data protection law, Tomer said that when a user asks for a fact to be forgotten, the system drops “the weight of connections to 0” so that it never shows up in queries. That is because “it’s non-trivial to just kind of delete nodes from the knowledge graph”, Tomer added.

Note: The quotes have been edited slightly for clarity and brevity.

What memory does

MediaNama: From a regulatory perspective, I treat memory as separate from the rest of the harness because memory, to me, is one of the most impactful parts of an agent’s functioning. I see it as a three-body problem: the harness is variable, the memory is variable and compounds, and the model varies, either depending on the use case or on how you’ve set up fallbacks. Because we have three interdependent variables, you essentially can’t get a deterministic outcome. You can get a better outcome, but you can’t legally hold something liable for that outcome. Most people just see it as software, assuming that input leads to output deterministically, whereas we know that it doesn’t. So what does MemStore do for an agent that an agent can’t do on its own? And how did the work at Julep lead you to focus on memory?

Diwank Singh Tomer: Memory Store, by the way, we’ve kind of rebranded a little bit as MemStore. But it’s the same product. And the idea is: how do we collect and organise knowledge so that we can give agents long-term memory? Modern AI depends on large language models, and they have context windows which act like really powerful short-term memory. Within that short-term memory, they can manipulate ideas, they can solve problems, be creative, and then they give you the output. Now, this context window is both finite, small, and also expensive. Putting stuff there means that you’re basically doing a forward pass of the model, which is very expensive.

So the job of long-term memory (human cognition is a lot more complex, actually, but at least for models) is to figure out how to give models the ability to tell us which parts of their context window were important so that we can store them for later. We then organise this information so that, when needed, we can inject it back into the model’s context window. We can say, “Hey, this is relevant context for you to work on this task,” or, “Write a letter for this person,” or, “Implement some kind of logic based on certain constraints.”

Ishita Jindal: So what we do is collect all this information from across the entire organisation. If we were all part of the same company, we would all have MemStore accounts, and there would be MemStore memory for Nikhil, Ishita, Diwank and others. All of that goes into a single, quote-unquote, “company brain”, which can access each other’s work. Let’s say I have to send an email to GitHub to request access to something, and you depend on that. As soon as I send that email, MemStore will notice and let you know, “Hey, Nikhil, by the way, Diwank’s done with that. You can go on and do this next thing.” This becomes even more powerful when it is given to agents. Agents can now collaborate across team boundaries, and they all have this shared long-term memory to work with. So we basically provide shared team memory for everyone in the organisation.

Why memory fails

MediaNama: How fallible is memory? From my experience, I’m frustrated with the number of times I have to say, “Listen, I’ve already given this information to you.” Retrieval constantly needs to be prompted, and quite often, the agent acts based on the context window instead of memory, even if instructions exist in the soul.md file. Is that a function of the model or the memory architecture? Where does it fail? Can you expect deterministic outcomes?

Diwank Singh Tomer: The short answer to your last question is no. You cannot expect deterministic outputs, but can you expect consistent outputs? Yes. And it depends on the memory architecture. All memory systems are bound to be somewhat lossy. There will always be some details that get missed. And it’s a little bit of a catch-22 because we don’t have access to the raw activations or the model’s raw processing. In specialised research situations, you can get access to the underlying model while it’s running. In a typical situation, you basically just give an OpenAI model some context and tools, and it tells you at the end what it needs and doesn’t need. But you can’t predict in advance what it’s going to need. And it doesn’t know the breadth of everything available in the memory store. You can imagine that when GPT-6.1 starts working on your task, it is hearing about you and the task, everything, for the very first time.

Everything it knows has to be within that context window, whereas the memory store built up over the last couple of weeks or months contains so much information that, of course, we can’t fit it all into the context window. So it’s a chicken-and-egg problem that you have to solve. The way we do it is by providing the model with tools. One of the core tenets of the design is that we engage the model in a back-and-forth process: it gives us information about what it’s working with, we update the current status of that thread, and then we provide relevant information. We keep doing this throughout the task. If we simply say, “Hey, here’s a tool, search memories,” the model doesn’t know what to search for. It doesn’t know what information is available. So it’s very sensitive to how you design it, and it’s a very limited design space.

The second thing I would add is that, depending on how you’re designing the memory architecture, you have to try and do a bunch of things at the same time. You have to be consistent. Let’s say some part of the memory says that there is a meeting between Nikhil and Diwank, and they have a topic that they would like to discuss. A couple of hours later, there’s a new memory which says Diwank and Ishita did this call with Nikhil, and they talked about such-and-such thing. If both of those memories coexist in the memory system, then it’s inconsistent. Did that call happen or did that call not happen? So in order to make everything consistent, you have to constantly be updating the memory, logically, across time. That’s really hard to do. And finally, you have to be able to condense this information and give it to the model fast enough when it needs it.

Layers of memory

MediaNama: We also see that there are different levels of memory. Can you explain what those levels are and what each level does?

Diwank Singh Tomer: The exact design for memory architectures depends a little on the domain. In a specialised domain, let’s say you wanted to implement coding memory, there are a whole bunch of things that you don’t need to worry about, and there are some specialised things, like the code architecture and the layout of the repository, that you have to keep track of. For a general-purpose system like ours, we took inspiration from cognitive science. So in our case, there are a few different layers.

We have episodic memory. This is memory that is time-stamped. There are events that are happening, sequences of real-life events, and there could be people involved in them, there could be situations, and there is hierarchy in that. For example, what happened throughout today is an event, but this call is a sub-event of that event, and so on. So you have to keep track of all of that. That’s episodic memory.

Then you have implicit memory, which is the implicit beliefs and world models of each of the participants involved. What does Diwank currently know? What does Ishita currently know? What are they working on? Then you have prospective memory, which is everything that we have to remember about the future: what are the tasks that we have, what is a goal that you’re working towards. And lastly, there is semantic memory, which is static facts and information, like, “Who is Nikhil? What is MemStore? What is the definition of implicit memory that MemStore uses?” These are static facts, all connected together in a large knowledge graph.

MediaNama: How do embeddings work with memory, and how do they impact the functioning of a memory?

Diwank Singh Tomer: In our case, all of these different types of memory that I just mentioned have embeddings in our system. At the end of the day, these are all different ways of modelling information, but each of them has different rules for how they get created and how they’re managed. The links between them tell us, “Okay, if this changes, then everything that is downstream of this particular episode has to be updated,” and that’s how we track changes.

What embedding lets us do is basically two things. I’m going to assume basic knowledge of embeddings here. If we embed all of these events and entities, then, one, if a query comes in, we get to find episodes that are similar to what the query is looking for. The second thing it lets us do, which is even more interesting, is find clusters. For example, MemStore is recording stuff for each of us, and let’s say Ishita is working on product, you’re working on sales, I’m working on engineering, and there’s a lot of overlap between all our ideas. Naturally, work that is related to each other emerges in that semantic space. No one might have said, “Hey, that bug is actually coming from customer XYZ,” but we can figure that out because of all of the things it’s connected to. So that’s how embedding is a retrieval and clustering methodology in our case.

Memory over years

MediaNama: You said two weeks or a few months. What happens when the memory has two, three, four years of data? Initially it compounds to benefit you, but does it then become a problem of prioritisation when it scales to such a large store? I’m assuming company information across maybe a decade could be stored and become institutional knowledge. How does prioritisation happen then?

Diwank Singh Tomer: For one thing, we’ve been dealing with really long time horizons. We use MemStore ourselves, and before we pivoted from Julep to MemStore, we had already worked for two years on Julep. One of the challenges was how to keep old, relevant insights and information of different team members who came and went across such a long horizon. And even more complicated is that we have to do it for all of the employees combined. For every person, we have to cross-reference and figure out what’s important and how it fits into Diwank’s point of view or Ishita’s point of view. The honest, full answer is that the only way to manage really large time horizons is spending a lot of tokens on the problem. Lots of agents have to actually work and organise, classify, figure out what is not important, what is important, and how it fits together. That’s why non-agentic memory systems have a very hard time scaling up, because there’s just so much noise and so much overlapping information.

Ishita Jindal: If I could add one point here, I think it’s easy to forget how new these systems are. The way we built memory, in the first version, we added a load of integrations and we just indexed all of that data, just for ourselves, and we realised that it was getting noisy. Some part of it was that it was our first version of memory, and that was also contributing to the noise. Eventually, when we scaled up, we redid our system and added integrations one by one. We’ve still not opened up every integration. Now imagine looking at the event analytics or notification system of a company, how much data there is. Is all of it worth remembering? Probably not. But it is worth knowing and remembering, inside a memory store, how a tool should be searched and how a company uses that tool. Maybe everything that’s sitting inside my HubSpot, or inside my event analytics tool like PostHog, is not worth remembering. But as a company, I need to provide information to my Claude on how we use that tool, what information I will find there, who updates it, who uses it. That kind of information still needs to be in MemStore. So I think there’s a nuance there in terms of memory inside organisations, and we’re still to figure out the exact shape and form of it.

MediaNama: For context, I created embeddings of 20 years of my social media posts, and now my agent has access to them, so I understand the value. I’m just curious how it knows what exactly I want when I want it, because getting a truckload of information where 90% of it is useless doesn’t help. How can it be deterministically correct at any point in time? If outputs are being given to a customer, they have to be correct. And I don’t see this as hallucination: it’s a model perhaps retrieving something that might not be true anymore. In a customer interaction, could it by mistake give a price that existed two years ago?

Diwank Singh Tomer: This is a really good question. Like I said earlier, you can’t be deterministic, because at the end of the day the questions and the inputs could be arbitrary, and the interpretations might also be arbitrary. But what you can guarantee, and what MemStore, for example, guarantees, is that it will always be consistent with all given inputs. Meaning, you will never get an output from the system that is inconsistent with another related question. For example, the question, “Does Diwank know Nikhil?”, no matter how you ask it, that answer will always be yes, depending on the input that MemStore has been given before. That’s what we can guarantee.

MediaNama: That sounds like a decision model framework. But beyond decisions, what about information?

Diwank Singh Tomer: Can we guarantee completeness? We cannot guarantee completeness. We can’t guarantee that we can represent every possible fact or remember everything from all of the inputs. But MemStore won’t give you two facts that are inconsistent with each other without flagging the contradiction. That much we can get.

Who controls what is remembered

MediaNama: Who decides what gets written? Is it the developer’s schema, a rule, the model? Can a developer require approval before something becomes long-term memory? What controls does a developer or deployer have?

Diwank Singh Tomer: One clarification I would make is that MemStore now is intended for teams, rather than for developers adding memory into their own agents. You would basically add MemStore as an MCP server in your tools, into your Slack, and so on. But even then, the question remains, of course. MemStore tries to remember and efficiently organise as much of the information as possible, and it tries to make connections. If there’s already information about Nikhil, it will try its best to connect everything, connect the dots and create insights. So we try to maximally record everything, within the guardrails defined by the user. Now, can you control what gets in? Yes. And you can also control what gets out by supplying us guardrails. At every interaction, when memory is coming in from the outside world or leaving MemStore, we run models, a quick guardrail that checks, “Hey, is this information allowed to go into MemStore?” And vice versa, when a memory is leaving MemStore, is it allowed to leave MemStore? As an organisation or a user, you can give us both of those.

MediaNama: How do you handle time and contradictions? When is an old fact overwritten, flagged as no longer true, or kept alongside? Which record wins at retrieval?

Diwank Singh Tomer: There is a lot of prior research in this space. There’s something called deontic logic, which deals with what happens in a more realistic environment where you can have conflicting information. What we basically follow is something called prioritised belief bases. What it means is we keep track of every contradiction, because contradictions happen all the time. An email might say something, a person might misremember, and so on. We identify them immediately, and if anyone is asking for information with which we have a contradiction, we deterministically make sure that the information does not go out without the contradiction attached to it. So it’s always, “Hey, we recorded this, this is what we know, and here is a contradiction.” It says here that Diwank already had a meeting with Nikhil, but another document says that they did not, and here’s the information on both, so that the agent or the person can figure it out. And then whenever new information comes in, let’s say another email comes in, or Ishita says, “No, no, no, we have had that meeting,” we resolve it, and that’s gone then.

MediaNama: Have you had to re-embed after changing embedding models? Different models have different numbers of parameters. Has the behaviour changed after you changed models? If better models come up and you have to re-embed, does that change the outcomes? Is it an evolving scenario rather than, “Hey, this is done, and this is how it’s always going to work”?

Diwank Singh Tomer: Yes, we have. And there are three variables. One is, of course, accuracy. Better models, and storing longer embedding dimensions, give you better retrieval, and they also give you better clustering. You can do a lot more with it. But that comes with not only the model cost but also storage costs, because saving, let’s say, 3,072 dimensions versus 128 dimensions is very, very different. It also changes how long it takes to build the index and how long it takes to search the index. So you have to optimise for cost, accuracy and speed. In our case, we end up doing both. We use Google’s Gemini Embedding 2, and we store both 3,072 and 128. The 128 we store for quick searches; there are use cases within that we need quick searches for.

MediaNama: In a team store, can one user’s writes reach another user’s agent? How are read and write permissions scoped, by user, agent, task or source?

Diwank Singh Tomer: This is related to the answer I gave previously. A lot of the value comes from the fact that teammates’ memory in MemStore keeps getting updated by each other. So if your memory gets updated about a topic that I care about, mine will also get updated, and we share that automatically. That’s actually one of the superpowers of MemStore. The way we control access is, again, via guardrails. There’s a default set of guardrails. For example, there’s a guardrail that personal and sensitive information never goes between each other. And then you can also add your own guardrails. For salespeople, for example, a guardrail could be that their leads and performance numbers should not leak to other salespeople on the team. And the last thing I would say is that we have explicit approval systems. There will actually be a request that pops up on your dashboard saying, “Hey, by the way, Ishita wanted to know this. You can approve it or you can decline it.”

Poisoning, deletion and export

MediaNama: Have you seen memory poisoning, either deliberate or accidental? What would detect it: write anomalies, provenance, or nothing yet?

Diwank Singh Tomer: I think the best long-term solution is provenance and repair. In the background, overnight, there is an agent that samples memories randomly and looks for errors like that. Or if any jobs were skipped, it looks again for anything that might not have been updated that should have been. So there are strict provenance and repair jobs that you have to keep running. Provenance alone doesn’t solve it. That is the best that we have so far. But yes, we’ve seen a lot of it.

MediaNama: So this is a continuous process of managing the memory. It’s never done.

Diwank Singh Tomer: Yeah, 100%. It’s constant.

MediaNama: If a user asks for a fact to be forgotten, which copies get removed: the store, the index, the summaries, the logs, the backups? Is it deleted-deleted, or does it still remain?

Diwank Singh Tomer: This is a little more complicated in the case of a fully connected knowledge graph. The way this works out is that we drop the weight of connections to 0, so in queries that would never show up. And the repair agents will see the change in the graph and go and update other documents. But it’s non-trivial to just kind of delete nodes from the knowledge graph.

MediaNama: Can a user or a developer export memory with its sources, timestamps and scope intact, in a form that another provider could import? Is export scoped to a user or to an organisation? And can this create risks for an organisation?

Diwank Singh Tomer: That’s also a really good question. We’re working towards SOC 2 (and Google’s CASA Tier 2 security assessment – added post-interview, via email) and on GDPR compliance. India’s DPDP Act is coming into force as well. I think, even in a fully connected graph, there are some complications, like how do you define the difference between a user’s memory and the organisation’s memory in a shared graph? That being said, we are planning to just let users download their data. It’s their data at the end of the day. If they want a copy of it, they should have access to the copy of it. There’s no shared, universal memory architecture at the moment, so I don’t think it would be directly importable into something else. That being said, at the end of the day, it is semantic information, and if you point Claude Code at it, it should be able to reconstruct some of it, at least.

Clarification: After the interview, Jindal said MemStore is also working towards Google’s CASA Tier 2 security assessment, and is not pursuing CCPA compliance.

Co-created and personal data

MediaNama: I once asked Nick Clegg, who was heading public policy at Meta at one point in time, how social media platforms deal with co-created data, because the right to erasure exists. He said that’s for governments to decide, which means no one knows how co-created data can be dealt with. How do you think about co-created data?

Diwank Singh Tomer: Honestly, I would just piggyback on that answer. If it comes to that, we would be happy to comply with the law.

Ishita Jindal: Can we go one step down from that? Since we’re working with individual companies, first, we have to comply with the laws of the land, wherever the data is processed and stored. But after that, it would depend on the company’s preferences. Let’s say the executives want that co-created data is not available to individual people; then we would not make it available to them. Or if, let’s say, a customer service rep and a product manager, like me and Diwank, are working on something together, a new memory is formed from that. If the requirement is that they both have access to it, I think we would try to do that. So I think, law of the land, and then the customer is king.

MediaNama: Actually, you are effectively data processors. Under Indian law, the company is the data fiduciary and you are the data processor, and even under the GDPR, you’re only processing it on behalf of a company. So it’s their problem, not yours.

Diwank Singh Tomer: The one thing I would like to add is that on the one side you have the co-created data, but on the other side you also have a more sensitive matter of personal data mixed with company data.

MediaNama: Let’s say in a Slack conversation I talk about my family to a colleague. What happens, and can I ask for it to be removed?

Diwank Singh Tomer: That’s something that we’ve spent time thinking about. We’ve made product and architecture choices such that we honour the individual’s right to control over their information. For example, if you use a Claude team account, your organisation admin can export all of your chats and go and look at them. One thing that we don’t want is that. Anything that a user’s personal guardrail does not allow into the team, the organisation should not and will not have access to. One of the reasons we want it that way is that if users fear that MemStore is going to be used to surveil them, they’re going to actively avoid sharing things with MemStore, reducing its efficacy.

Secrets and standing instructions

MediaNama: What happens when a user pastes a password, an API key, an Aadhaar number or a social security number? Do you actively detect and redact those secrets before they’re stored or embedded?

Diwank Singh Tomer: Yes. And more importantly, we try to make sure that it doesn’t enter the MemStore boundary to begin with, because we have the guardrails up front. The model is actually going to inspect that and say, “Oh, wait, you are pasting in a PAN number or an Aadhaar number, and that is not allowed to go in.”

MediaNama: But the model does read it. When a model reads it, doesn’t it store it somewhere? Is forgetting a function of not documenting it, or does the weight go down to zero while it still gets documented?

Diwank Singh Tomer: What I meant by the zero weight is that once something is added to MemStore and established as part of MemStore, then we do the zero-weight thing. But before that happens, it first has to be accepted into the system. A model sits between the outside world and any request coming in. So a request comes in, “Hey, record this information,” with five lines or whatever, and it has a PAN number. First, a model from an external provider will look at it and say, “Hey, no, this contains a PAN number or an API key,” and it rejects it. Behind this boundary there are MemStore agents that will go and file information in the right place, but it is not given to them. And the APIs that we’re using are zero data retention APIs, so it just doesn’t get logged anywhere inside MemStore. MemStore agents never see it. It’s as if that request didn’t happen. It just errors back saying, “Hey, this was not accepted because it failed the guardrails.”

MediaNama: One last question. Can a memory ever act as an authority? Say, “Always approve refunds under Rs 5,000.” Can a memory refuse to store standing instructions like that? I’m thinking of the Air Canada case, where a chatbot fabricated information and offered a discount that wasn’t honoured, and the customer went to court. Instructions like these can also be given in a customer-facing scenario.

Diwank Singh Tomer: It’s a good question. I don’t know of a use case so far where we’ve encountered something like that. There is some natural protection in MemStore from this. I’m assuming these instructions are either malicious or unintended. If an unintended instruction is getting stored, it’s quite likely that it contradicts or conflicts with existing knowledge in the company, so it’s automatically going to be flagged: “Hey, this is coming in. Is this correct?” We’ve not really encountered this as a business case yet, so we’ve not explicitly built a feature. However, we have this explicit approval system. If information comes in that’s contradictory, let’s say I mistype something, or the model hallucinates and sends something wrong to MemStore to record.

MediaNama: And with transcription tools like Wispr Flow and Granola.

Diwank Singh Tomer: Oh, yeah. This already happens. There are always, like, 10 different versions of it. So we have this placed on our dashboard, which highlights all of the conflicts and asks me to approve them.

Ishita Jindal: If I could just add a point there, the kind of examples we have encountered involve a model very often sitting between the context from MemStore and the person using it. I might be using context inside my Claude, for example. We do something called standup updates, and we follow a very different format for the way we write standup updates as a company. The first time, when we did not even have a system for this and weren’t optimising for it, it remembered the format in which we write standup updates. Stuff like that. I don’t want all of the admin stuff, like my HR stuff, to go inside my standup updates. Now, these are things not really related to just memory; they are process things that you remember. So we are trying to actively build systems which remember things around processes that one does every day.

MediaNama: And that becomes institutional memory. People change, but the processes remain.

Ishita Jindal: Yes. So I think it’s more a question of how a system is built rather than just how memory is built. This information, I think, we can’t keep just inside MemStore. We keep it as skills in different places, and whenever MemStore sees information which points to updating a skill, it is able to go and update that skill. I don’t think it answers your question from a governance point of view, but from a business one.

MediaNama: It does. What this answers for me is how complex this entire thing is to set up, and how much variance there is. Any regulator looking at this and saying, “This is how it should work,” needs to know that you can’t be deterministic about how something should work, because there’s so much variance.

Also read: