THE WRAPPER QUESTION
Most memory products are JSON blobs in a vector store.
Published Updated
A lot of the cynicism here is earned. Plenty of "memory" is a JSON blob in a vector store with a logo on it. Frameworks ship a default vector database, a quick cache that quietly becomes production, no schema, no access control, no audit trail. If that is your reference point for AI Memory, being skeptical is the correct response.
So let us not defend the category. Let us separate from it. The difference between a wrapper and a memory system is the work you cannot see in a demo. It is whether the system resolves entities, whether it handles two facts that contradict each other, whether it knows what is stale, whether it scopes what each agent and each user can read, and whether it forgets on purpose. That is the iterative depth work that is hard to get right, and it is the reason a benchmark number is not just marketing for us. On LongMemEval we are at 92%, and that gap is the difference between memory and a cache with good branding.
If the wrapper criticism makes you check what is actually inside, good. That is the check we want you to run.
How can developers give an AI agent persistent memory?
There are three routes and they differ in where the work sits. Write to files and you own the whole lifecycle. Put a vector store behind your agent and you own retrieval quality, entity resolution and conflict handling. Use a memory layer and those operations arrive as a service. The choice is not about storage; it is about which of capture, retrieval, consolidation, conflict resolution and forgetting you want to build yourself.
The proof, in numbers
Questions people ask before deciding
Five, in a loop. Capture decides what is worth keeping out of a conversation. Retrieval selects what is relevant to the current turn. Consolidation merges new information into what is already known. Conflict resolution decides which of two contradictory facts wins, usually on recency plus source. Forgetting removes what has expired or been revoked. A vector store does one of the five.
A vector database is a retrieval index. It returns the nearest neighbours to a query embedding, and it holds no opinion about whether two of those neighbours contradict each other, which of them is more recent, or whether the user asked for one of them to be deleted last week. Those are the operations that make memory behave like memory.
Entity resolution is deciding that "Priya", "Priya S." and "my co-founder" refer to one person. Without it, memory fragments across aliases and the agent holds three partial pictures instead of one. It matters more as history grows, because the number of ways a person can be referred to grows with it.
Less than teams expect. Loading more raises cost linearly and raises accuracy only up to a point, after which retrieval quality falls because the relevant fact sits in the middle of a long context and gets read past. The useful target is the smallest set that changes the next action.
The API call is the easy part. What differs is everything on the write path: deciding what to keep, merging it with what is already there, resolving the contradiction when the user changes their mind, and honouring a deletion across every derived artefact. A layer that only offers store and fetch has handed all of that back to you.
It adds a retrieval hop before the model call, so the honest answer is yes, by the latency of that hop. It usually removes more than it adds, because an agent that already knows the context skips the clarifying turn, and one avoided round trip costs more than one retrieval.
Runnable examples for every supported framework live at docs.maximem.ai, covering LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, the OpenAI Agents SDK, the Claude Agent SDK, Mastra, the Vercel AI SDK, Pipecat, LiveKit Agents and Semantic Kernel.
See the operations a wrapper skips.