DEV Community: MemTensor

How to Keep Bad Assumptions Out of Agent Memory

MemTensor — Wed, 16 Sep 2026 13:45:13 +0000

Standfirst: Retrieval quality cannot repair a memory that was wrong when written. Production agents need an admission layer that distinguishes user statements, environment facts, model inferences, procedures, and high-impact state before any of them become durable memory. MemTensor's MemOS provides an operating-layer architecture in which those lifecycle controls can be made explicit.

An agent may carry a mistaken assumption from one task into the next. Checking what it learns, keeping the source, and revisiting memories when conditions change can help prevent that mistake from spreading. MemOS gives developers tools to support this work, from processing new information to correcting existing memories.

When an agent gives a wrong answer, it is natural to inspect what it retrieved. The problem may have started earlier, with a memory built from an incomplete observation or a conclusion that was never checked.

In Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents, Microsoft researchers gave a memory curator read-only access to the environment after a task ended. It could check uncertain claims and revise or skip records before later tasks used them.

In the paper’s 40-question CLBench experiment with schema changes, using GPT-5.4 in a GitHub Copilot SDK harness, the system with memory and environment probing reached a mean pass rate of 73%. The system with memory alone reached 70%, while the no-memory baseline reached 39%. Adding probing to the memory system also reduced average queries per question from 5.6 to 4.7 and task-agent cost from $1.99 to $1.68. These costs exclude the separate distillation and curation stages.

Those results describe the researchers’ setup. They raise a practical question for developers building with memory: what should an agent check before passing something it has learned to the next task?

A useful observation can become a misleading rule

Consider a database agent that finds the records it needs in a table called customers_current. It finishes the task and saves a note saying, “Use customers_current for active accounts.”

The query may have worked for one region or reporting period. The saved note leaves those conditions out, so another agent could apply it to a much broader question. Checking the table definition and the relevant business rules would help establish where the advice holds.

Even a carefully checked note can become outdated. A month later, the table might be replaced by a compatibility view that updates less frequently. Future agents need a way to recognize that change and update the memory.

Similar problems arise when an agent keeps recommending an API workaround after a fix, saves a temporary approval process as a permanent procedure, or records a failed command as a successful solution. A policy can lose its effective date during summarization. A rule for one customer can become advice for every customer.

In each case, the memory is missing something a future task needs: evidence, conditions, or an update. Retrieval can find the note, but the agent still needs enough information to judge whether it applies.

Check the claim before making it reusable

A memory workflow often starts with a conversation or task history, extracts useful information, and saves it for later retrieval. A verification step can check the extracted claims before they become reusable advice.

The original conversation and tool results can still be retained as evidence. The decision is which conclusions to make available to future tasks, and with what limits. Keeping that distinction also allows a team to inspect how a summary was produced if something goes wrong.

The check should match the information being saved.

Information	What to check
A user statement or preference	Keep who said it, when, and the relevant context. “I prefer concise weekly summaries” can be recorded directly and changed when the user updates it.
A fact about the environment	Check the relevant system, such as a schema, repository, API specification, or policy document. Record the version or time observed.
An agent’s inference	Preserve the evidence and identify the conclusion as an inference. “This customer may be price-sensitive” should remain distinguishable from something the customer explicitly said.
A procedure or skill	Keep its prerequisites and the evidence that it worked. Use a test or acceptance condition appropriate to the procedure.

Sensitivity and impact apply across these categories. A preference about report length needs less review than a remembered procedure that could change access permissions or authorize a payment.

Read-only checks are often enough to resolve uncertainty. A coding agent can inspect a symbol definition, and a database agent can examine a schema or query a limited sample. Procedures with side effects need a suitable test environment or other evidence of a successful result.

How MemOS supports the workflow

MemOS provides operations for adding, finding, correcting, and removing memories. Developers can use these operations alongside checks against their own business systems. The application chooses the authoritative source and implements the environment checks described above.

Keep the source with the memory

In the open-source service, MemReader processes conversations, documents, and images into memory items with source information. Developers can use the Add API’s info metadata to attach details such as the source location and application-supplied validation results.

For the database example, this could include the schema version, the time it was checked, and the business context in which the table should be used. If a later answer looks wrong, the team has a starting point for investigating it.

The verification step needs to cover the extracted claim. Checking an input document alone can miss an error introduced when the system turns that document into a shorter memory.

Keep preferences and inferences distinguishable

MemOS Cloud’s memory extraction API distinguishes explicit preferences from preferences inferred from behavior and returns the reasoning behind them.

That distinction helps an application handle “I prefer budget hotels” differently from a guess based on one booking. Developers can decide whether the inferred preference is useful for a recommendation or needs confirmation before affecting a more consequential action.

Update memories as information changes

MemOS Cloud supports conflict and duplicate handling as part of memory maintenance. Its time-aware memory handling preserves changing states so retrieval can distinguish a current fact from an earlier one.

These features help process changes that reach the memory system. In the database example, the application still needs to detect the schema change or provide the new evidence. It can then use feedback to correct the remembered advice, or update or remove the affected entry through the relevant memory operations.

Choose where a memory can be used

The open-source service organizes memories in MemCubes. Requests can specify cubes to read from or write to, allowing an application to keep project memories separate or make selected information available across agents. The application must connect these choices to its authorization rules.

Session context has a different role. In the open-source Search API, session_id helps prioritize relevant memories; it is not a hard boundary between sessions.

Check the result of background work

Memory writes and corrections can run in the background. The open-source service provides scheduling and status operations to track that work. With MemOS Cloud, the task-status API reports processing status and, on completion, the affected memory IDs and a summary of what changed.

This gives applications a way to follow a submitted operation through to its result. They can inspect the affected memories and check what subsequent searches return.

Put the checks into a working flow

Start with one kind of memory whose accuracy matters to the task, such as database guidance or a frequently reused support procedure.

Extract the candidate. Identify the claim or procedure worth keeping and retain its source.
Check the evidence. Inspect the authoritative system and test the conditions the candidate depends on. If the evidence is incomplete, narrow the claim or hold it for review.
Save the conditions with it. Include where it applies, when it was checked, and what should trigger another check. Make only approved candidates available for reuse.
Inspect the result. After writing or correcting a memory, check the operation’s outcome and the records available to later tasks.
Revisit it when its source changes. A schema migration, policy revision, or API change should prompt a review of memories that depend on it.

For customers_current, a useful record would include the applicable region and reporting period, the evidence behind the recommendation, and the schema version checked. A migration affecting that table gives the application a concrete reason to review the record.

Follow the memory into the next task

Teams also need to see whether the process is helping. The following questions can guide monitoring across the application and its memory service.

Stage	What to inspect
Candidate review	Which sources produced candidates, what evidence was checked, and why a candidate was accepted, revised, or rejected
Write	Which records were added or changed, where they were saved, and whether processing completed
Retrieval	Which memories were returned and which were actually included in the model’s context
Use	Task completion, repeated errors, user corrections, and results compared with a no-memory baseline
Maintenance	Entries affected by changed sources, overdue checks, and corrections that have reached later searches
Deletion	Whether removal completed in the memory store and any application-managed copies or caches

Linking these records makes failures easier to investigate. A retrieved memory may never have reached the model, and a memory included in the prompt may not explain the action that followed. The trace gives the team evidence to examine; testing is still needed to establish the cause.

For a first evaluation, save a checked memory, use it in a later task, then change the underlying information. Confirm that the correction appears in subsequent retrieval and that the agent completes the task with the updated information. This exercises the part of memory that matters in ongoing work: carrying useful knowledge forward while keeping it open to correction.

About MemTensor and MemOS

MemTensor develops memory infrastructure for AI applications and agents. Our work spans Memory³ research, MemOS, agent-memory infrastructure, and research into models with native memory.

MemOS brings this work into applications through APIs, open-source components, and integrations for storing, retrieving, and maintaining information across tasks.

Claude Made Memory Editable. Production Agents Still Need a Governed Memory Layer

MemTensor — Wed, 16 Sep 2026 05:36:58 +0000

Claude’s memory updates are a meaningful marker in the evolution of AI products: memory is becoming visible, categorized, editable, and subject to an explicit sensitive-topic setting. That is a material improvement in user control. It is also a useful reminder that a production agent needs more than a model-specific memory feature. It needs a governed memory layer.

An assistant’s built-in memory helps it retain context within the app. Here, a governed memory layer means a service with explicit rules for what gets stored, who can retrieve it, and how it is updated or deleted. Applications with multiple users or tenants may also need access controls and change history tied to those boundaries.

Anthropic’s release notes make the product change concrete. On July 10, 2026, Claude memory changed from a daily summary to individual categorized entries that Claude reads and updates in conversations. On August 25, memory was extended across Chat and Cowork in the cloud; remembered items became editable or deletable as Topics; health and beliefs were excluded unless a user enabled sensitive topics; and the feature was listed as on by default for Free, Pro, and Max, and off by default for Team and Enterprise organizations. Those are real controls, not cosmetic ones. Anthropic’s release notes are the appropriate record of what has been publicly announced.

But editable memory is not, by itself, a portable enterprise memory layer. A production system may use multiple models, agent frameworks, tools, knowledge sources, identity systems, and deployment environments. It must retain context without turning every past interaction into an unscoped, permanent prompt attachment. The implementation question is therefore larger than “does the assistant remember?” It is “can the organization govern remembered state throughout its life?”

Why editability changes the conversation

Memory was often treated as a background mechanism: useful when it worked and hard to inspect when it did not. Editable Topics change that expectation. They acknowledge three operational truths.

First, a memory can be wrong. A preference can change, a project decision can be reversed, and an automatically generated summary can flatten an important qualification. Editing and deleting therefore make memory correctable rather than merely persistent.

Second, memories vary in sensitivity. Anthropic’s setting for sensitive topics is a product-level example of a broader design requirement: Applications need explicit rules for which information may be saved as long-term memory and which requires additional consent or should be excluded.

Third, organization-level defaults matter. A user feature may be helpful, while an enterprise still needs an administrator-controlled starting point, defined ownership, and evidence that retrieval respected the relevant boundary. The Team and Enterprise default described by Anthropic is an illustration of how memory decisions become organizational, not only personal.

This is a welcome direction. Yet production systems cannot stop at a settings page. They must answer questions that emerge when memory is shared across agents, connected to tools, or retained longer than a single conversation.

A feature is not a governed data layer

“Portable” here does not mean that every memory should be copied everywhere. It means that the organization can govern memory independently of any one chat surface or model runtime, using explicit interfaces and policy. A portable layer should make a memory’s boundaries and handling rules intelligible when the agent changes, the session ends, or the model provider changes.

Oracle’s developer guidance offers a useful separation: retrieval-augmented generation (RAG) retrieves documents or data to ground an answer, whereas agent memory persists useful state across interactions. RAG should preserve source evidence; memory may retain scoped preferences, decisions, summaries, task state, and tool results when they remain valid and allowed. Oracle also stresses that memory should be correctable and deletable, and that scope should use explicit user, tenant, agent, and conversation identifiers rather than a user ID alone. Oracle Developers’ “Agent Memory Is Not RAG” is direct on both the distinction and the operating implications.

That separation produces a practical design rule:

Use RAG for source-grounded evidence and live knowledge. Use durable memory for scoped state that has been deliberately promoted, remains useful, and is permitted to be recalled.

Neither component replaces the other. An agent preparing a customer response may retrieve the current policy document through RAG, recall a customer’s approved communication preference from memory, and query a live system for order status. Treating all three as “context” hides different update, provenance, and authorization rules.

What to define before adding persistent memory

The following is a reference workflow for application design, not a description of a specific MemOS deployment. Verify which controls the selected product provides and which the application must implement.

Conversation or tool result
        |
        v
Decide what to save
        |----> discard, redact, or keep for this session
        v
Stored memory
(content, owner, source, timestamps, status)
        |
        |----> update or delete under application rules
        v
Retrieve within the caller's allowed scope
        |
        v
Agent context

The capture path is not an invitation to store every turn. It is a filter. A production design should distinguish a transient observation from a candidate memory, and a candidate from an approved durable record. For example, “the user is having a bad day” may be transient and sensitive; “the user prefers a weekly project summary in plain English” can be useful, scoped, and reviewed under a defined policy.

The record itself needs more than text and an embedding. At minimum, it should carry a memory identifier; owner and tenant; agent, thread, or conversation scope where relevant; category; source or provenance; creation and last-confirmed timestamps; status; retention or expiry rule; and the permission context required for recall. A correction should create a discernible lifecycle event, not silently overwrite the reason an earlier fact was used. A deletion request should be testable from request through removal or tombstone, including derived indexes where applicable.

At recall time, relevance is necessary but insufficient. The retrieval path should first apply the caller’s authority and purpose, then retrieve within the allowed scope, then make clear which memory was selected and why. This is the difference between “the agent found a related sentence” and “the system can account for the state it injected into an action.”

A lifecycle, not a scrapbook

Long-lived agent memory has a lifecycle. Designing it explicitly prevents both accidental amnesia and accidental accumulation.

1. Capture. Receive a conversation event or tool result with the identity and session context that produced it.
2. Classify. Identify its type: preference, task state, decision, validated fact, summary, or sensitive/transient content.
3. Promote or reject. Apply a policy for durability, sensitivity, consent, and expected usefulness. Some information should remain session-only; secrets should not be stored as agent memory.
4. Scope and annotate. Bind the record to the permitted user, tenant, agent, thread, conversation, or domain scope, and attach provenance and timestamps.
5. Retrieve selectively. Match the current task against allowed memory; avoid broad, automatic retrieval that increases noise, latency, or cross-boundary exposure.
6. Correct, supersede, or provide feedback. Let authorized users and operators revise false or obsolete state. Preserve enough event history to explain the transition.
7. Expire or delete. Enforce retention rules and deletion requests across the memory’s usable representations.
8. Audit and measure. Record writes, recalls, policy outcomes, and lifecycle actions. Evaluate whether memory actually improved the workflow enough to justify its cost and risk.

Oracle makes two points that align with this lifecycle: promotion should be deliberate, and memories need provenance and timestamps. It also recommends defining storage scope and promotion, update, delete, and retrieval rules before wiring memory into an agent loop. Its implementation guidance is sensible even when the underlying platform differs.

What is public about Claude memory — and what is not established

It is important not to infer a product architecture from a release note. The following table separates announced behavior from questions a production buyer should still ask.

PUBLICLY ANNOUNCED BY ANTHROPIC	NOT ESTABLISHED BY THE CITED RELEASE NOTES
Categorized memory entries replaced daily summaries on July 10, 2026.	A cross-provider or cross-model export and portability contract.
Memory works across Chat and Cowork in the cloud.	An enterprise memory schema that an organization can operate independently of Claude’s product surfaces.
Users can edit or delete remembered Topics.	The complete retention, deletion-propagation, audit, and provenance semantics an external production workflow may require.
Sensitive topics are excluded unless the user enables the setting.	A general-purpose policy engine for every organization’s data classifications and business purposes.
Team and Enterprise memory is off by default.	How any particular organization should configure memory for its risk profile.

The right-hand column is not a claim that these capabilities do not exist elsewhere in Anthropic’s products or documentation. It is a discipline: do not represent them as established by the specific public release notes cited here. Architecture and procurement decisions should be based on verified product documentation, contracts, and a scoped technical evaluation.

Where MemTensor and MemOS fit in this discussion

MemTensor builds memory infrastructure for AI applications and researches long-term memory and continual learning. Its work includes Memory³ research, the MemOS memory system, and research into foundation models with native memory. The broader goal is to help AI applications retain useful context, support personalization, and make better use of information over time.

MemOS is a memory system for AI applications, designed to help them retain useful context across conversations and tasks. Its Cloud API supports turning conversations into memories, retrieving relevant information, updating and deleting records, and correcting memories through feedback. These capabilities can help applications remember preferences and carry relevant context into later interactions. MemOS also offers managed Cloud and open-source deployment options. See the MemOS Cloud overview and API overview for the public product record.

For users, well-managed memory can mean less repetition and better continuity as preferences and projects change. For the applications they use, a separate memory layer provides a way to manage that context over time, with explicit operations for retrieval, updates, and deletion.

A governance checklist for production agents

Before enabling durable memory in an agent workflow, a team should be able to answer these questions in writing:

Purpose: What decision or workflow does each memory category support? What must never be retained?
Scope: Which combinations of user, tenant, agent, project, thread, and conversation are allowed to write and recall it?
Promotion: Who or what can convert an interaction into durable memory? What review or confidence rule applies?
Provenance: Can an operator identify the source event, tool result, policy version, timestamps, and last confirmation for a recalled item?
Permissions: Is recall evaluated using the same identity and authorization context as the underlying business data?
Sensitivity: How are secrets, regulated fields, and sensitive personal topics rejected, redacted, or subject to explicit consent?
Correction: Can the subject or an authorized operator edit, supersede, or contest a memory without creating a new hidden inconsistency?
Deletion and retention: What is the retention schedule, and how is deletion verified in records, indexes, caches, and downstream representations?
Observability: Are memory writes, retrievals, and policy denials logged so that an agent action can be reconstructed?
Evaluation: Does the team measure both the benefits of recall and failures such as stale recall, irrelevant recall, and scope leakage?

The checklist is deliberately operational. A strong memory experience should feel simple to users; that simplicity is earned by precise handling underneath.

The implication of Claude’s update

Claude’s editable memory is news because it puts control over remembered state closer to the user and treats memory as a collection of items rather than an opaque daily artifact. That direction raises the baseline for every agent experience.

As AI becomes part of everyday work, useful memory can reduce repetition and keep relevant context available over time. Claude’s updates show the value of making that memory easier to manage. MemOS brings memory capabilities to other AI applications, helping them retain and reuse context across interactions. The practical question is what an application remembers, where it uses that information, and how users can keep it accurate.

Agent Memory Is Not RAG: A 2026 Production Field Guide

MemTensor — Wed, 16 Sep 2026 05:14:31 +0000

An agent can retrieve a policy PDF, remember that a customer prefers concise answers, keep a workflow alive across tool calls, and query a live order system. Those are four different jobs. Calling all of them “memory” makes production design—and vendor comparison—needlessly vague.

The useful distinction is simple. Retrieval-augmented generation (RAG) finds external evidence needed to answer now. Agent memory preserves useful state across turns, sessions, or workflows. A larger context window gives a model more working material for one inference; it does not itself decide what should persist, update an outdated preference, or enforce a deletion request. Oracle’s developer guidance makes the same operational point: durable memory needs explicit identity and scope, provenance, lifecycle rules, and permission-aware recall. Oracle Developers

That is why “we have a vector database” is not an answer to “how does our agent remember?” A vector index can be an excellent retrieval component. It is not, by itself, a policy for promotion, correction, expiration, isolation, or audit.

Choosing an AI memory solution starts with understanding what you need it to remember, where that information should be available, and how it should change over time. Different products approach these needs through memory APIs, temporal graphs, stateful agents, or broader memory-management systems.

In this guide, we compare Mem0, Zep/Graphiti, Letta, MemOS, and Supermemory across memory lifecycle, retrieval, deployment, and application fit. We explain where MemOS fits among these approaches and outline the questions that can help you choose a solution for your workflow. The goal is to make the differences clear enough to support a practical decision, whether you are exploring AI memory or evaluating a system for production.

Start with the four layers

Prompt context is the bounded set of tokens visible to the model for a specific inference. It can include the current user message, system instructions, tool outputs, a running summary, retrieved documents, and selected memories. Context engineering is the process of selecting, filtering, compressing, and refreshing that set at decision time—not merely writing a better prompt. Redis

RAG retrieves evidence from a corpus: source documents, records, tables, or other authorized materials. Its primary obligation is grounding: use relevant, accessible, current source material and preserve enough provenance for the answer to be checked. RAG may be stateless. A good RAG pipeline uses tenant and ACL filters, document versions, chunking or structured retrieval, and citations where the user needs evidence. It is the right mechanism for “What does the current policy say?”

A vector database or vector index stores embeddings and enables similarity retrieval; many products also provide filtering, keyword search, metadata, or hybrid retrieval. It is infrastructure, not an agent-memory policy. It can power RAG, semantic recall, or both. It does not decide whether “the user changed their preferred language yesterday” supersedes an old fact, nor does it supply a cross-session identity model.

Agent memory is durable, scoped state selected for later use. Its units are typically preferences, facts with timestamps, task state, summaries, decisions, learned procedures, or previously validated tool results. The hard problems are not only storage and search. They are promotion (what gets saved), scope (which user, tenant, agent, thread, and permission context may retrieve it), evolution (what updates or invalidates it), and governance (who can inspect, correct, delete, or audit it).

In a production stack, these layers often coexist. A support agent might assemble: current prompt instructions; a thread summary; customer memories scoped to the customer and tenant; policy citations from RAG; and real-time account status from a tool. Do not replace the last item with memory: live operational data should remain a live source of truth.

Where MemOS fits

We built MemOS to make long-term memory a manageable part of AI applications and agents. It provides a dedicated layer for retaining useful context, retrieving it when relevant, and updating it as preferences, facts, and tasks change. This supports applications that need continuity across conversations, personalized interactions, or reusable context across agent workflows.

MemOS combines memory storage and retrieval with support for multiple memory types and memory scheduling. Its Cloud API provides operations for adding conversations, searching memories, updating and deleting records, and incorporating feedback to correct remembered information. Filters, tags, asynchronous processing, knowledge-base features, and chat APIs support different integration needs.

You can access MemOS through our managed Cloud service, open-source framework, and supported agent integrations. These options let you choose how much infrastructure you want to operate and how closely you want to customize memory behavior for your application.

MemOS website · MemOS Cloud overview · MemOS API overview · MemOS GitHub

MemTensor is the company behind MemOS. We build memory infrastructure for AI applications and research long-term memory and continual learning, with the goals of reducing hallucinations, improving personalization, and helping AI systems make better use of prior experience.

Our work spans Memory³ research, the MemOS memory system, agent memory infrastructure, and research into foundation models with native memory. Across these efforts, we connect research with practical systems for storing, retrieving, and maintaining useful information over time. MemOS brings this focus into applications that need to carry context beyond a single conversation.

Product boundary: MemOS is not Memmy.

MemOS and Memmy address different needs within our product lineup. MemOS provides memory capabilities for AI applications and agents through APIs, open-source components, and integrations. It is suited to workflows where memory needs to become part of an application or an existing agent setup, with a choice of managed services and components you can operate yourself.

Memmy is our personal AI agent and local memory hub. It brings together a desktop app, a local memory service, a CLI, and integrations that help individuals reuse context across supported AI tools. Its focus is the day-to-day experience of maintaining personal context and continuing work across connected agents.

Choose MemOS when you want to add or customize memory capabilities in an application or agent workflow. Choose Memmy when you want a personal agent and local memory hub that brings supported tools together around shared context.

Memmy website · Memmy official GitHub

A production selection rubric

Before comparing products, write a one-page memory contract. Name the data classes you may store; the scopes that must never cross; who owns correction and deletion; the authoritative sources of truth; and the failure behavior when memory is unavailable. Then evaluate products against these seven dimensions.

1. Lifecycle

Can the system selectively add, update, delete, expire, merge, or roll back memories? Can the application keep a raw event, an extracted memory, and the rule that promoted it separate? Look for timestamps, source references, conflict handling, retention controls, and an explicit correction path. “We embed every message” is ingestion, not lifecycle design.

2. Retrieval and context assembly

Ask what is retrieved—documents, facts, graph edges, profiles, memory blocks, summaries, or a mix—and how filtering happens before generation. Test tenant, user, agent, conversation, time, memory type, and permission filters. Evaluate result quality and context budget together: a relevant ten-line memory may be more useful than twenty similar chunks. Retrieval should be measurable by task quality, leakage rate, recall precision, and added latency.

3. Deployment and data boundary

Choose an operating model before choosing an SDK. Does the public documentation show a library, a self-hosted service, a managed cloud service, or multiple paths? Identify each dependency: model provider, embeddings, database, graph store, object store, telemetry service, and outbound network path. A self-hosted package does not automatically establish a complete private-deployment architecture or every enterprise control.

4. Governance and isolation

Treat a memory read as a data access decision. Require explicit tenant, user, agent, thread or conversation, request, and permission identifiers where relevant. Define redaction and secret-exclusion rules before ingestion. Verify per-scope deletion, correction, retention, access control, and audit evidence in the exact product edition you will run. Cloudflare’s agent-memory discussion similarly frames scoped, durable state—not a growing transcript—as the operating problem. Cloudflare

5. Observability

For each model turn, record the retrieval request, filters, candidate IDs, selected memory IDs, source/provenance, timestamps, token count, model response, and user feedback. Instrument promotion, mutation, deletion, and rollback separately. You need to answer: “Why was this item supplied?” and “Why was this old item still present?” without dumping sensitive memory into logs.

6. Ecosystem and application fit

Evaluate the interfaces you will actually use: Python, TypeScript, REST, MCP, agent frameworks, tool calling, or cloud platform. Prefer an integration path that preserves your identity and authorization model. Availability of an integration is not evidence that it implements your organization’s governance policy.

7. Operational maturity in your environment

Maturity is not a star count, a benchmark result, or a product label. Test upgrade behavior, backups, disaster recovery, model-provider failures, rate limits, schema changes, migrations, and incident support against your requirements. Public sources can establish that code, docs, or a deployment option exist; they do not establish that a product meets your particular SLA or compliance program.

Five AI memory solutions compared

Mem0

Overview. Mem0’s official repository documents a memory library, a self-hosted server, and a managed platform. The self-hosted setup uses Docker Compose and documents default-on authentication, an administrator/bootstrap flow, API keys, and a dashboard. The same repository documents Python and npm installation and a CLI with add and search commands keyed by a user ID. Its repository is published under Apache-2.0. Mem0 repository · self-hosted setup

Best suited for. Consider Mem0 when a team wants a memory-focused integration surface and can choose among library, managed, or self-hosted paths. Its documented self-hosted path gives a concrete starting point for teams that will operate their own stack; the hosted platform is a separate operating choice.

What to consider Confirm how the extraction and retrieval configuration behaves for corrections, conflicting facts, per-tenant isolation, deletion propagation, and your own authorization model. Benchmark retrieval quality and cost with your model and data rather than assuming an SDK abstraction selects the right memory.

Zep/Graphiti

Overview. Graphiti and Zep are related but distinct choices. Graphiti is Zep’s Apache-2.0 open-source temporal context-graph framework; its repository documents episode ingestion, hybrid retrieval, graph-distance reranking, an MCP server, and graph-store options. Zep is a managed agent-memory service built on Graphiti. Zep’s documentation describes users and threads, context assembly, and deployment and governance options including Zep Cloud, BYOK, and BYOC. Graphiti repository · Zep versus Graphiti · Zep concepts · Zep security and compliance

Best suited for. Consider Graphiti when temporal relationships and graph-aware retrieval are central and the team wants to build and operate the surrounding memory service. Consider Zep when the same class of context-graph capability is wanted as a managed service with documented user/thread abstractions and enterprise deployment options.

Trade-offs to test. Graphiti puts graph infrastructure, extraction, entity resolution, temporal invalidation, concurrency, and authorization design on the implementing team. Zep reduces some of that operating burden but introduces a commercial service, contract, and data-boundary decision. In either path, test whether time-bounded relationships improve the real task enough to justify the additional graph and ingestion complexity.

Letta

Overview. Letta presents a platform for building stateful agents and documents an API, Python and TypeScript clients, self-hosted base-URL use, and memory blocks that can be attached to or detached from agents. The official repository is Apache-2.0 and calls Letta an open-source project; it also documents a local CLI and an API path. The official TypeScript documentation describes sharing a block by attaching it to more than one agent. Letta repository · Letta TypeScript documentation

Best suited for. Consider Letta when memory is closely coupled to the agent runtime and an agent-centric state model—rather than an independently selected retrieval service—is the intended abstraction. Shared blocks may be useful when shared-agent context is deliberate and access-controlled.

Trade-offs to test. Agent-attached memory can be compelling, but teams should test isolation, block sharing, edits, deletion, export, model behavior, tool state, and migration as first-class cases. Decide whether your system needs portable application-level memory independent of a single agent runtime.

MemOS

Overview. MemOS brings memory storage, retrieval, updates, and management into a dedicated layer for AI applications and agents. Our Apache-2.0 open-source framework supports multiple memory types and scheduling. MemOS Cloud provides APIs for memory extraction, search, updates, deletion, and feedback-based correction, alongside knowledge-based and chat capabilities. We also offer private deployment and custom integration options for enterprise needs. MemOS repository · MemOS Cloud docs · MemOS API overview · MemOS website

Best suited for. MemOS is a strong fit for applications that need persistent context across conversations and agent workflows, with explicit control over how memories are retrieved and maintained. Choose the Cloud API for managed integration, or explore our open-source framework and agent integrations to match your setup.

Trade-offs to test. Test the specific memory types and scheduling behaviors needed for your workload, the identity/scope fields carried through every call, lifecycle behavior under correction and deletion, integration fit, and the operational design of the selected edition. A broad memory abstraction can add flexibility; it also requires a clear policy for what is allowed to become reusable memory.

Supermemory

Overview. Supermemory’s official repository is MIT-licensed and documents a memory/context API, JavaScript and Python SDKs, container tags, document ingestion, semantic and hybrid search, and API-key authentication. Its public repository documents a self-hosting quick start with a local server and embedded engine, and says the SDKs can point to a self-hosted base URL. Supermemory repository · self-hosting quick start · SDK documentation

Best suited for. Consider Supermemory when a team wants an API-oriented path that combines user-context patterns with document retrieval, and wants to evaluate both managed-style API usage and the documented local/self-hosted route.

Trade-offs to test. Evaluate whether a container-tag design maps cleanly to your tenant, user, agent, and conversation boundaries. Test profile or extracted-memory freshness, document-versus-memory retrieval, deletion propagation, model/provider dependency, and the scale and persistence properties of the self-hosted design under your workload.

A short path from comparison to decision

Avoid a universal ranking. A product may be an excellent fit for one memory shape and a poor fit for another. A graph-first system can be appropriate for temporally changing relationships; an agent-runtime system for stateful agent control; a memory API for fast integration; and a broader memory operating layer for lifecycle and scheduling across several forms of memory.

Run a time-boxed proof of concept with your own data contract. Give every request tenant, user, agent, thread, conversation, and request identifiers as applicable. Create known-correct facts, deliberately stale facts, conflicting updates, sensitive values that must never persist, and cross-tenant near-duplicates. Measure retrieval precision, task success, latency, token cost, write cost, deletion completion, and the ease of explaining each selected item. Include a simulated provider failure and a restore exercise.

The decision is production-ready when the team can explain, for every memory: who it belongs to, why it was saved, what supersedes it, who may retrieve it, where it is stored, how it is observed, and how it is removed. RAG then remains what it should be: a companion system for source-grounded evidence, not an overloaded substitute for durable agent state.

Memmy LAUNCHED: Let every AI remember the same you 🍙

MemTensor — Tue, 08 Sep 2026 13:08:15 +0000

Over the past few months, Agents have quietly crossed a threshold — from conversation tools into actual work partners: reading codebases, calling tools, running tasks end-to-end, and plugging into increasingly complex workflows through Skills, MCP, and sub-agents.

But most Agents today still don't know you. Not really. They have no access to the knowledge and preferences you've built up over months — no continuity with your past projects. Switch agents, and you're rebuilding from scratch: task context, key decisions, working habits — all of it, gone.

And as the number of agents you use keeps growing, your project context, personal preferences, hard-won decisions, and accumulated experience get scattered across more and more tools and sessions — with no single thread connecting any of it.

Today, we're officially launching Memmy.

Memmy is your personal memory hub — and a local-first Agent that continuously learns to understand you. It distills your knowledge, preferences, and project experience into long-term memory, so Cursor, Claude Code, Codex, OpenCode, OpenClaw, WorkBuddy, and every other Agent you use can collaborate from the same shared context. It also ships with a desktop app, CLI, API, Skills, and MCP support — ready to plug directly into your daily workflow and get things done.

Accumulate once. Use everywhere.

Let every AI remember the same you.

(Create your Memmy account now. 2M tokens for free trial, zero setup, no API key needed.)

I. Not just a memory layer. Not just another Agent.

Memmy integrates 3 capabilities into a single local runtime:

Personal Memory Hub Knowledge, preferences, project context, and hard-won experience — scattered across agents and past sessions — consolidated into long-term memory that's retrievable, updatable, and reusable.

Local Agent Runtime Model inference, task orchestration, tool calling, Skills, and MCP support — built in. Analyze files, structure plans, query information, and execute multi-step tasks, directly.

External Agent Connectivity Memmy is natively compatible with any Agent. Cursor, Codex, Claude Code, OpenCode, OpenClaw, WorkBuddy — and anything beyond — can read from existing memory. Any Agent that can call the right interface can pull the context it needs for the current task, and write new decisions and experience back when the task is done.

II. How Personal Memory Keeps Growing

Memmy gives memory a complete lifecycle: recover what's been built up, make sense of it, surface what's needed, and keep updating as new work happens.

2.1 Scan: Recover the context you've already accumulated

With your authorization, Memmy reads existing Agent history directly from your machine. No manual copying, no re-organizing past conversations — your accumulated project context is already there. Choose which sources to import, and pause, resume, or stop at any time.

2.2 Organize: Distill what actually matters from your chat history

After installation, Memmy generates a personalized "First Impressions Report" from your imported content — a fast read on the project experience and personal preferences that have already formed.

And Memmy doesn't just dump your chat history into an ever-growing flat file.

Powered by MemOS, it understands, deduplicates, classifies, and structures your history — transforming key decisions, personal preferences, project progress, and hard-won lessons into long-term memory that can be retrieved, updated, and reused.

What gets retained: the decisions you made, the preferences you formed, where each task stands, and which lessons should carry into the next session.

2.3 Retrieve: Surface exactly what the current task needs

Flooding a model with your entire history doesn't just eat context — it lets irrelevant information pollute the signal.

Memmy matches the current task against long-term memory and surfaces only the relevant project context, key decisions, and prior experience — delivering just what the active Agent needs, nothing more.

For example, say you've already established in Cursor:

Backend: Fastify
Storage: local SQLite
No cloud database in this phase

A few days later, you switch to Claude Code to build a data export feature.

Claude Code doesn't need to re-read every past conversation. Memmy surfaces the relevant architecture and storage decisions — letting it continue along the existing plan, without re-confirming choices that were already made or accidentally reversing them.

2.4 Write-back: Let new experience flow back into personal memory

Importing history is just the starting point.

If new decisions and lessons from external Agents stay siloed in their own sessions, personal memory fragments all over again — fast.

That's why Memmy supports installing a memory Skill for external Agents. Via the memmy-memory CLI and memory Skill, external Agents can both retrieve existing memory and write new experience back to Memmy as work happens.

# Initialize the memory service and install the memory Skill for an external Agent
memmy-memory init --agent

# Retrieve existing memory
memmy-memory search "database decisions in this project"

# Write a new lesson
memmy-memory add "batch exports need concurrency limits to avoid memory exhaustion"

III. One Agent Runtime. Every Way You Work.

Memmy is a local Agent Runtime — and every surface shares the same Agent, memory, model config, and tool capabilities. Desktop app, floating desktop launcher, CLI/TUI, and OpenAI-compatible API. Start a task from one entry point. Pick it up from another.

3.1 Desktop Launcher: From understanding to execution, end-to-end

The desktop app is Memmy's most complete interface — task management, message threads, file attachments, voice input, slash commands, memory management, and tool connections, all in one place.

Use it to:

Analyze codebases or business plans
Organize documents and extract what actually matters
Chain multiple tool calls across consecutive steps
Resume long-running tasks mid-flight
Manage memory sources, model config, and tool connections

For anyone pushing complex tasks forward continuously — the desktop workbench is a personal AI command center that manages tasks, memory, and tools simultaneously.

3.2 Memmy Pet on Desktop: Delegate on the fly, without breaking flow

Writing code, reading docs, or mid-meeting — you shouldn't have to open a full window.

Memmy lives on your desktop as a lightweight persistent launcher. Click it to expand an input field and fire off a task via text or voice. Double-click to open the full launcher.

3.3 TUI, CLI & API: The same Agent Runtime, straight from the terminal

For the devs who live in the terminal, Memmy offers three interfaces: TUI, CLI, and an OpenAI-compatible API.

Type memmy directly in your terminal to launch the TUI.

Or drive the Memmy Agent Runtime straight from the CLI:

memmy onboard
memmy status
memmy agent --message "Oi, give me an overview of the current workspace"

Spin up the local OpenAI-compatible API:

memmy serve

Via Skills, MCP, and custom tools, Memmy also extends into file processing, shell execution, web access, image generation, and task automation — with native connections to GitHub, Gmail, Notion, Slack, Jira, and more.

IV. Memory Stays Local. Access Is Yours to Control.

The more personal preferences, project context, and working experience accumulates, the more valuable long-term memory becomes. That's why Memmy is local-first by design: memory lives on your machine by default, and you decide how it's managed and who can access it.

Out of the box:

Memory is stored in local SQLite
Config file lives at ~/.memmy/config.yaml
Workspace lives at ~/.memmy/workspace
Local API and Memory Service support token-based auth
API keys can be referenced via environment variables — no hardcoding in config files

You choose which Agents can access your memory. You can view, update, or delete anything at any time. Connecting more tools doesn't automatically open your memory to all of them.

On the model side, Memmy offers two modes:

Account Mode
Use the platform's free credit allocation out of the box — no API key required. Full Memory and Agent Runtime, zero config.

BYOK Mode
Bring your own model service. Choose your model, manage your own credits and API keys. Note: how your data is handled during model inference depends on the privacy policy of the model provider you connect.

Config example:

agents:
  defaults:
      model: openai/gpt-4.1
      provider: openai
      timezone: Asia/Shanghai
providers:
  openai:
    apiKey: ${OPENAI_API_KEY}

V. Benchmarked: Agents That Execute More Accurately

Under internal evaluation and corresponding test configurations, Memmy demonstrates consistent long-term memory capability — and leads across Agent reasoning, code execution, and cost efficiency.

LoCoMo: #1 in Single-hop and Temporal Memory

On the LoCoMo long-term conversational memory benchmark, Memmy scores 78.34 overall — taking the top position in both Single-hop and Temporal task categories.

Memmy doesn't just store more. It retrieves the right memory from a large history with precision, and correctly reasons about the temporal relationships between events.

EvoAgentBench: #1 Accuracy Across All 5 Task Categories

Across all 5 Agent task categories in EvoAgentBench, Memmy ranks first in accuracy — and achieves the lowest cost in Reasoning, Code, and InfoRetr.

Memory isn't just about looking back. It directly lifts task execution quality. From long-term memory to real-world execution, Memmy helps Agents do more than remember — it helps them perform more accurately and efficiently, grounded in prior experience.

Download Memmy and get started today.

Available via the Memmy website or GitHub.

Sign up and get 2,000,000 free tokens trial — no API key required. Full Memory and Agent Runtime, ready out of the box. Usage and remaining credits are visible directly inside the app.

Once your credits run out, switch to BYOK mode at any time and keep going with your own model API.

Official Website: https://memmy.bot

GitHub：https://github.com/MemTensor/memmy-agent