Mem0 gives AI applications persistent user memory

Mem0 supplies a memory layer for AI applications and agents. It extracts reusable information from interactions, stores that information and retrieves relevant context for later requests. The job is narrower than running the whole agent: Mem0 helps an application remember, while the application decides what to ask, what to do with the result and which information it is entitled to retain. That separation is especially useful for products with repeated conversations.

01 / ProductA memory service between conversations

The platform overview describes a managed service that accepts conversations, extracts useful facts and retrieves relevant memories. It operates across sessions rather than relying on the current prompt to contain everything. The underlying product idea is selective context: an assistant should receive the information relevant to the present question instead of replaying every historical message.

The Platform versus Open Source guide distinguishes the hosted management surfaces from a stack a developer operates. Both support core operations such as adding, searching, updating and deleting memories. The hosted service adds organisation and project management and some capabilities that are not available in the same form in the current OSS package. Do not treat a managed feature description as a promise about every self-hosted installation.

Memory is also different from a source-of-truth database. A remembered preference can guide the wording of a response, while a current account balance must come from the system that owns that record. The product is useful when it reduces repeated context gathering. It becomes risky when an application promotes a historical statement into present authority without checking whether the underlying situation has changed.

02 / AudienceProducts that need continuity without replaying everything

A tutoring assistant might need a learner’s preferred explanation style. An internal project assistant might need the decision behind an earlier design choice. A support product might remember a user’s preferred contact method while still retrieving live order status separately. These are concrete reasons to add memory: recurring context has value, but loading every past conversation into every request would be inefficient and difficult to review.

The team needs the ability to define a stable user identity and a clear retention policy. A product that cannot reliably distinguish tenants should resolve that problem before adding personalisation. A one-off classifier or summariser may have little need for persistent memory at all. Start with the information that a user would reasonably expect the application to remember, and make the reason for retention understandable.

Compare Pinecone when the central requirement is retrieval infrastructure over a deliberate document collection. Compare Letta when the agent’s continuing identity and editable memory are part of the broader runtime design. Mem0’s role is a memory component that can be attached to an existing application. Choosing it should simplify a specific continuity problem rather than introduce history merely because storage is available.

03 / WorkflowProposed workflow: remember preferences, verify current facts

Consider a proposed project assistant that helps the same employee over several weeks. After an interaction, send only the portion relevant to a durable preference or project decision to Mem0. Attach the authenticated user identifier and the application’s own project metadata. The add-memory guide describes extraction, optional metadata and identifiers used for later scope. This is a proposed design, not a tested deployment.

The current add documentation describes an additive pipeline: adding new memories does not itself overwrite or delete earlier ones. This matters when a person changes a preference. The application should not assume that sending the new statement automatically removes the old one. Design an explicit correction path and test what retrieval returns when both statements exist. A coherent-sounding response can hide an unresolved contradiction in stored context.

Before generating a later answer, search using the present question and a server-derived user filter. The search guide documents filters, result limits and relevance controls, and explicitly recommends user scoping. The authenticated application should choose that scope. Allowing the model or an untrusted client to supply an arbitrary user identifier would make correct retrieval depend on behaviour outside the identity boundary.

Return relevant memories as context with their provenance and time information, then ask the application to retrieve any changing operational facts from their authoritative system. For example, remember why a project chose a design, but query its current release status separately. Evaluate sessions with conflicting preferences, renamed projects and deliberate deletion requests. The outcome to measure is appropriate continuity, including occasions when the assistant should ask whether an old preference still applies.

04 / PricingNew accounts now use Free or Custom pricing

The live pricing page presents Free and Custom plans. New free accounts receive an initial period in which Mem0 pays for model calls; connecting the organisation’s own supported LLM key increases the published add and retrieval allowances. This is different from older search results advertising Starter or Pro subscriptions. Those historic amounts should not be used to quote a new deployment.

The pricing FAQ confirms that legacy Starter, Growth and Pro plans are no longer sold to new accounts. It also says that, after the initial period, new adds require a connected provider key while existing memories and limited searches remain available. Provider calls using that key are billed by the model provider. The absence of a Mem0 subscription charge therefore does not establish that extraction is free to operate.

For extra usage, the FAQ says the rate is displayed when usage-based billing is enabled and a monthly cap can be set. This assessment did not enter an account or inspect that activation screen, so it does not quote an unverified overage price. Organisations created through the Vercel Marketplace follow a different billing path and cannot use BYOK, according to the same FAQ. Match the budget to the actual signup route.

05 / DistinctionsMemory extraction is a separate application capability

Mem0’s distinctive contribution is to make extraction and retrieval an explicit service boundary. A team can decide what to submit, inspect what was remembered and build a correction experience around identifiable records. This is more deliberate than assuming a larger model context window will solve every continuity problem. A larger window can hold more text, but it does not determine what should be kept or forgotten.

The graph-memory documentation describes a native graph over entities extracted from memories, with those connections contributing to retrieval ranking. It distinguishes semantic entities from the identifiers used to scope users and agents. An entity such as a company name can connect related facts; a tenant identifier controls which records should be considered. They serve different purposes and should not be confused in the application design.

There is a commercial ambiguity to resolve: the graph guide describes the capability as built in and always on, while the pricing page lists graph memory under Custom. The article therefore does not promise it on Free. Confirm the relevant account entitlement before relying on graph behaviour in a product specification. Clear documentation of a mechanism and clear permission to use it at a particular price are separate pieces of evidence.

06 / QuestionsRetention, stale context and failure handling need design

Expiration is not necessarily deletion. The add-memory guide states that expired records are normally hidden from search and get-all operations but can still be fetched by ID. A product promising erasure must use an appropriate deletion path and verify its effect across the application’s stores. Hiding a memory from a typical retrieval result is a different outcome from removing the retained information.

The quickstart and detailed operation pages illustrate different levels of abstraction around adding memories. The detailed guide describes pending operations and completion checks. A production integration should follow the endpoint and SDK version it actually uses and confirm that accepted work finished before reporting a preference as saved. If a provider key fails, build a visible retry path; silently losing updates can make an assistant appear to remember inconsistently.

Finally, test whether retrieval helps the task. A relevant old statement can still be wrong today, and a highly ranked memory is not independent verification. Include examples where no memory should be returned, where a corrected preference should supersede a previous one and where two users discuss the same project. Those cases reveal whether the application treats memory as useful context or as unchecked authority.

07 / DecisionAdd memory only where continuity has a clear benefit

Mem0 is worth evaluating when an existing AI product repeatedly loses useful context between sessions. Start with one kind of memory, one authenticated identity boundary and a way for the user to correct or remove it. Compare the resulting answers with a no-memory baseline. A successful pilot improves continuity while making remembered information easier to explain and control.