mem0ai

Can a user retrieve information outside their permissions, including through the lexical search path, caches, or indirect references? Jeevan Srivastava asked this question word for word in a Medium article of 18 October 2026, as one of three dimensions he would assess for a production system, beside retrieval quality and operational performance. He labels his access-control design: "These are proposed production design decisions, not features I'm claiming to have implemented as part of my retrieval fix." > TL;DR > > - Yes, through any read path the permission check does not cover. The question names three: the lexical branch of a hybrid search, filtered differently from the vector branch; a cache that answers before the check runs; and indirect references, such as a fetch by ID or exact name, a pointer to a hidden record, or a scope value supplied by the request or the model. > - One rule addresses all three: the server derives the read scope from the verified caller identity and applies one filter on every path that can return stored content. For the model's part, the Databricks agent memory documentation says of the actor_id that scopes every read: "Never let the model choose it." > - Three probes, run as a user without access, test whether a system holds: a rare word from a restricted document through every search branch; a cache warmed by a user with access; and a direct fetch, a followed pointer and a foreign scope. Each needs a positive control run as a user with access, or an empty result proves nothing. Mnemoverse (the author's company) makes one of the memory APIs quoted below. Can a user retrieve information outside their permissions? Yes, whenever a path that returns stored content skips the check that search runs. A read path is any function, endpoint or query type that can return stored content to a caller: a search, an exact get, a list, an export, an admin surface or a debug endpoint. Heinrich Neb, who works on a memory layer for coding agents, gave the audit rule in a dev.to comment of 27 August 2026: "find every function that can return stored content." | Read path | How it returns what the user may not see | What closes it | Documented by | |---|---|---|---| | Lexical branch of a hybrid search | The full-text query lacks the vector query's filter | One filter below both branches, or passed to each | Srivastava; PostgreSQL; Elasticsearch | | Cache in front of retrieval | A stored answer is served before the check | The caller's scope in the key, or the cache behind the check | RFC 9111, for shared HTTP caches | | Fetch by ID or exact name | A lookup outside search returns the record | An object-level check on every route that takes an ID or a name | OWASP API1:2023; Neb | | Pointer from a visible record | A visible record names a hidden one | The target's visibility checked when the pointer is read | Neb; PostgreSQL | | Scope from the request or the model | A user ID or tag from the path, body or a tool argument is trusted | Scope from the verified identity; supplied values checked against the configured set | Databricks; Supermemory; Mem0; Anis Meziani | | Query language as a search type | Raw queries reach the store | Off unless every user of the deployment is trusted | Cognee | The last four rows are kinds of indirect reference. Srivastava separates the two decisions: "Relevance determines whether information is useful. Authorization determines whether information is allowed to be accessed." How does the lexical search path leak in a hybrid search? The lexical branch is the half of a hybrid search that matches the query's words against a full-text index, such as BM25 or PostgreSQL full-text search, beside the vector half that matches embeddings. Srivastava's rule: "The key decision is that both vector search and lexical search must respect the same access restrictions." The failure: "If vector search filters by tenant or document permissions but PostgreSQL full-text search doesn't, the hybrid retrieval pipeline can introduce a data leak through the lexical branch." On merging the two lists: "Combining rankings must never override authorization boundaries." And at retrieval time: "Apply authorization and tenant filters to every retrieval path." One filter can reach both branches from two places. Below both branches, in the database. With row security enabled on a PostgreSQL table, "all normal access to the table for selecting rows or modifying rows must be allowed by a row security policy", and a table with no policy falls back to "a default-deny policy" (PostgreSQL, Row Security Policies). The same page sets two limits: "the table's owner is typically not subject to row security policies" unless the table is altered with FORCE ROW LEVEL SECURITY, and "Superusers and roles with the BYPASSRLS attribute always bypass the row security system when accessing a table." An application that connects as the owner of an unforced table, as a superuser or as a BYPASSRLS role is not filtered at all. One filter passed to every branch. The filter parameter of the Elasticsearch RRF retriever "Applies the specified boolean query filter to all of the specified sub-retrievers, according to each retriever's specifications." Written once, it cannot drift between two copies. OWASP's LLM08:2025 opens its prevention list with: "Implement fine-grained access controls and permission-aware vector and embedding stores." The OWASP text speaks of vector and embedding stores; a hybrid pipeline has a second index, and the same rule has to reach it. Srivastava adds a condition that holds over time: "metadata can become stale if permissions change and the retrieval index isn't updated accordingly." Does a permission filter keep a restricted user's results complete? Nothing leaks here; the risk runs the other way. The pgvector README: "With approximate indexes, filtering is applied after the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average." Its first suggestion, an index on the filter column, can give exact search in many cases, so the shortfall applies whenever the planner takes the HNSW index instead. What follows is this article's inference for a vector branch on pgvector with an HNSW index, not a measurement. A permission rule is a condition that keeps some share of the rows, so the narrower a user's rights, the fewer rows one scan of the vector index can return, while the full-text branch can still return every permitted match. For hybrid search the README offers fusion: "You can use Reciprocal Rank Fusion or a cross-encoder to combine results." Fusion ranks the lists it receives, so a restricted user's top results draw more on keyword matches than an administrator's do. An evaluation run as an administrator measures only the administrator's ranking: report retrieval quality per permission level. The README's levers: "Starting with 0.8.0, you can enable iterative index scans, which will automatically scan more of the index until enough results are found". On tenants: "For applications with multiple tenants, sharing an approximate index between tenants means vectors from one tenant can affect recall (and speed) for other tenants." And: "For tenant isolation, use list partitioning or separate tables." Can a cache answer with documents the user may not see? Yes, when it answers before the check runs. For shared HTTP caches, RFC 9111, section 3.5, sets the rule: "A shared cache MUST NOT use a cached response to a request with an Authorization header field" to satisfy a later request, unless the response allows shared storage through a Cache-Control directive such as public, s-maxage or must-revalidate. A semantic or answer cache inside an application follows whatever rule the application gives it. Naveen Metta, in an article of 12 October 2026 on RAG before production, states the requirement: > If a user cannot open the document, the model should not be able to quote it. From his team's work: "We found one prompt that could surface HR documents to any employee." He also advises: "Then add a semantic cache in Redis for repeated questions." This article's inference about any cache in front of retrieval, not a description of his system: such a cache answers without running the filter, so the caller's scope has to be part of what it matches on, or it has to sit behind the check. Srivastava would test "whether permissions and deletion requests propagate to the relevant indexed and cached data." The warm, revoke, replay test is covered in the library page on revoked access after an answer was shown, and caches after a delete in Agent Memory Deletion: What Survives a Delete. What counts as an indirect reference, and how does it leak? An indirect reference is any way to reach a record other than a search the filter covers: its ID, its exact name, a pointer from another record, a scope value or a query language. An existence leak is an answer that reveals that a hidden record exists, or something about it, without returning its content. The fetch that skips search. Neb, on his own system: "We had scoping enforced correctly on retrieval, tested, verified", and beside it "a second read path, lookup by exact name rather than similarity, that returned full content to anyone who asked." In short: "Same store, two doors, one guarded." The sign in code: "a read path that doesn't accept the caller identity cannot enforce anything". For APIs, OWASP API1:2023 Broken Object Level Authorization: "Every API endpoint that receives an ID of an object, and performs any action on the object, should implement object-level authorization checks." The pointer. On 25 August 2026, Neb reported a retired record whose banner kept naming its successor after the successor was made private: "Existence leak through the supersession pointer." His rule: "a pointer's validity and a pointer's visibility are both read-time questions, never write-time facts." PostgreSQL warns of a related channel: its referential integrity checks always bypass row security, and "Care must be taken when developing schemas and row level policies to avoid "covert channel" leaks of information through such referential integrity checks." The query language. Cognee pull request #5844, merged into its dev branch on 15 October 2026: "CYPHER and NATURAL_LANGUAGE search types run raw Cypher against the graph database." And: "Any user with read access to a dataset could execute arbitrary queries". The change: "ALLOW_CYPHER_QUERY now defaults to false." For turning it back on: "Only do that when every user of the deployment is trusted." What closes the class: a check at every entry point, and a refusal that neither names nor describes the hidden record, so that a missing record and someone else's record get the same answer. An answer that tells the two apart reveals existence, which is acceptable only where existence is not a secret. Who should set the scope of a memory read: the server, the request or the model? A caller-supplied scope is a value that selects whose data a read covers, such as a user ID, a tenant tag or an actor ID, and that arrives with the request or from the model instead of from the verified identity. The Databricks agent memory documentation (Beta, last updated 26 October 2026) states the rule: "Set actor_id in your application code from trusted caller context: the verified end-user identity for per-user memory, or a trusted team or project key for shared memory. Never let the model choose it." And: "If your strategy depends on an end-user identity, reject requests that don't carry one rather than falling back to a shared actor_id." Three classes of the error, each with a dated fix: A scope chosen by the model. Supermemory pull request #1824, merged on 16 October 2026 into the 2.x release branch of its tools package: "In 2.x, getProfile, documentList, memoryForget and documentDelete accept an optional containerTag from the model and use it unchecked as the request scope." The consequence: "So a model, or a prompt-injected input, can name another tenant's tag and read their profile, list their documents, forget their memories, or delete their documents." The fix: "A model-supplied tag must be one of the tags the developer configured", or the call fails "before any request is sent". The pull request also notes: "Tools 3.x (#1773) already removed model-selected scope." An empty scope read as everything. Mem0 pull request #7581, merged on 12 October 2026, on its hosted clients: "The dangerous one is an empty entity ID. The API treats an empty ID as matching every memory in the project." The case there is the delete calls, delete_all and delete_users, fixed on the client: "This PR blocks that client-side. The server needs its own fix, which is out of scope here." This article did not check whether the server has changed since. A scope taken from the path or the body. Anis Meziani, replying on 14 October 2026 to a comment under his own dev.to article: "Our ADK-native session routes originally checked that a token was valid, not which user it acted for, so the user_id in the path or body was trusted." His fix checks the token's subject against the user_id "on every route that reads sessions or memory, including the live WebSocket". The rule: the scope comes from the verified identity; a request without one is refused, not given a shared scope; an empty value is an error, not everything; a value from the model is checked against the configured set before any request goes out. What changes when several users share one memory store? In a shared store the question moves from the answer to the context. A preprint of 19 October 2026 (arXiv 2610.25707, version 1, not peer-reviewed) opens: "Shared long-term memory lets an LLM agent serving one user inadvertently retrieve another user's credentials, but it is unclear when such exposure leads to actual harm." Its audit used the AppWorld environment and one store for all users' logins: "In AppWorld, a store that mixes 763 past logins from all users retrieves another user's credential for 84.7 percent of required apps, yet agents rarely act on it." Of the misuse its stress test provokes: "Naming the owner before or inside each credential line prevents most of this". Its conclusion: "Agent memory should consistently record whose credential it stores, and evaluations should measure behavior, not only exposure." This article's reading: the boundary is crossed when another user's record reaches the model's context, whether or not the model uses it. Srivastava, from the design side: "The stronger approach is to prevent unauthorized information from entering the context in the first place." Databricks states where the boundary sits: "actor_id separates memories, but it is not an access control. Memory stores are workspace-scoped, so any principal that can reach a store can read and write every entry across all actors." And: "The store, not the actor, is the security boundary. For strict isolation between tenants or users, create a separate memory store per boundary." OWASP's LLM08:2025, for vector databases: "In multi-tenant environments where multiple classes of users or applications share the same vector database, there's a risk of context leakage between users or queries." How do you test that no read path leaks? Each probe has a positive control, because a probe that finds nothing proves nothing until it finds something where it should. They are this article's proposals, not any team's suite. 1. The lexical branch. As the test user, run vector-only, lexical-only and hybrid queries for a rare word, such as a code name, found only in a document the user may not open. Expected: no chunk of it. Control: a user with access gets it. Srivastava proposes this negative test: "Queries from unauthorized users should not expose protected documents, even when those documents are semantically similar to the query." 2. The cache. User A, with access, asks a question whose answer needs the restricted document; user B, without access, asks it and a paraphrase. Expected: B's answer is not built from that document. Control: A's answer is built from that document, and B's answer with the cache off matches B's answer with the cache on. 3. Indirect references. As a user without access, fetch the record by ID and by exact name, follow a pointer to it from a visible record, and send another user's scope and an empty scope. Expected: the same answer as for a record that does not exist. Controls: as a user with access, the same fetch, pointer and scope return the record, so the path is live; a made-up ID on the same path gives the answer to compare against. Three rules for the run: - Take the list of read paths from the code or the tool registry, not from a filtered listing. sam ros, on 15 October 2026, about the CI test of the scope check in his MCP server: "with a list_tools override that filters by the token's scopes, the old test passed while a tickets:read token could still delete." - Rerun the probes after a permission change and after a delete: permission data copied into an index or a cache can go stale. - Inspect what reached the model's context, not only the final answer. A passing first probe says nothing about the second and the third. How do memory APIs document where the boundary is? Two documented positions, in their own words, as read on 2 November 2026. Databricks. The store is the boundary, and application code, not the model, sets the actor ID; both are quoted above. Mnemoverse. The security page states the tenant boundary: "Every API key is bound to a unique organization_id. All database queries are scoped to your organization." Shared rooms (beta) stay apart: "room content never appears in your normal (non-room) searches". The rooms reference covers indirect references: "Knowing a room id grants no access to its contents: access is enforced by the API's membership check on every request, and non-members get 403." And: "Membership is checked before archive state, so a non-member of an archived room still gets the membership 403", so the answer does not reveal whether a room is archived. This is a documented boundary, not a test result; this article tests no product. What this article does not claim No measurement of any product and no figure for how often any system leaks. The numbers above are the pgvector README's illustration and one preprint's audit, each with its conditions. Vendor fixes are quoted from their own pull requests with their merge dates; this article did not check whether a fix has reached a release. The inference about rank fusion is for pgvector with an HNSW index and was not measured. The probes are proposals, not a description of any team's suite. --- Sources and method. Every quotation was read on 2 November 2026 with two instruments, a browser-like request and a second reading of the same text: a reader service with its cache off, and in addition the dev.to API for the dev.to comments, the RSS feed for Jeevan Srivastava's article and the arXiv API for the preprint; for the GitHub pull requests and the pgvector README, which the reader service refuses, the GitHub API and the raw file took its place. A made-up address on each host answered 404 as a control, except Medium, which answers 200 to any address, so there only the article text counts. The text describes those pages as of that date. A longer version, with the common questions and the full list of sources, is in the Mnemoverse documentation library: Can a user retrieve information outside their permissions, including through the lexical search path, caches, or indirect references? Edward Izgorodin · Mnemoverse · 2026-11-02

How to Implement Long-Term Memory for AI Companions: Pinning, Compaction, and Lessons from Mem0 and Letta A user tells their AI companion on Monday that they are allergic to peanuts. On Thursday they ask for a snack idea. The model suggests peanut butter cookies. Nothing crashed. The fact was stored somewhere. It just was not in front of the model when it mattered. That is the core problem of long-term memory for companion apps and personal agents. It is not really a storage problem. It is a question of what the model sees on each turn, and what happens to everything else when the conversation outgrows the context window. I work on Sipplay, an AI character chat and interactive story product. Our users hold conversations that run for weeks, so we have spent a lot of time on this. In this post I will walk through three questions every memory system has to answer, show how two of the strongest open-source projects answer them, and explain the choices we made. Three questions every memory system answers However the architecture diagram looks, a memory system for a conversational agent makes three decisions: 1. What is always in context? Some facts are too important to leave to retrieval: who the user is, hard constraints, the current relationship or task. 2. What happens at compaction? When the conversation is too long, something gets summarized, truncated, or moved out. The question is what survives that step. 3. What gets retrieved, and when? Everything not in context must be found again. That means deciding when to search, what to search for, and which of several similar records is still true. Most "my AI forgot" bugs come from one of these three, and they need different fixes. A bigger context window helps with none of them for long: it only postpones question 2. Mem0: a memory layer you bolt onto any agent Mem0 (around 68,000 GitHub stars at the time of writing, Apache-2.0) is the most popular open-source memory layer. It sits beside your agent rather than inside it. The basic loop from its README is two calls: from mem0 import Memory memory = Memory() # before replying: fetch what is relevant to this message relevant = memory.search(query=message, filters={"user_id": user_id}, top_k=3) # after replying: let Mem0 extract memories from the exchange memory.add(messages, user_id=user_id) Mem0 keeps memory at user, session, and agent level, so the same store can hold "Alice prefers dark mode" and "this support session is about billing". The interesting part is how its extraction changed. In its April 2026 algorithm update, Mem0 moved to single-pass, ADD-only extraction: one LLM call per exchange, no UPDATE or DELETE operations. The README puts it plainly: "Memories accumulate; nothing is overwritten." Conflicts are handled at read time instead, with: - Multi-signal retrieval: semantic similarity, BM25 keyword matching, and entity matching scored in parallel and fused. - Entity linking: entities are extracted and linked across memories to boost retrieval. - Temporal reasoning: time-aware ranking that picks the right dated instance for questions about current state, past events, or upcoming plans. Mem0 reports 92.5 on LoCoMo and 94.4 on LongMemEval with this approach, at about 7,000 tokens per query. Note the caveat in their own README: those scores come from Mem0's managed platform, which includes optimizations not in the open-source SDK. What Mem0 gets right: it treats memory as an append-only log plus a smart reader. Writes are cheap and never destroy information. "The meeting moved from Thursday to Friday" becomes two dated facts, and the reader's job is to pick the current one. What to watch: nothing is always-in-context by default. If a fact must never be missed, like an allergy, you are relying on retrieval to surface it every time it matters. And the quality of "pick the current one" now depends entirely on ranking. Letta: an agent that manages its own context Letta started life as MemGPT, the research project that framed LLM memory as an operating-system problem: a small, fast main context and a large external store, with the model paging information between them. The original repository (about 25,000 stars) is now archived as V1. Active development has moved to letta-code, which Letta calls an agent harness. Letta answers the three questions very differently from Mem0. Memory belongs to the agent, and the agent edits it itself. Always in context: memory lives as Markdown files in a git-versioned memory filesystem (MemFS). According to the Letta docs, files under system/ are in the system prompt on every turn. Everything else stays out of context: the agent sees the file tree and reads what it needs. Compaction: Letta has a background process it calls "dreaming". Subagents review recent conversations, consolidate lessons, and update memory without interrupting the active session. Crucially, you can trigger it on compaction: const agentId = await client.createAgent({ persona: "You are a support engineer who learns each customer's environment.", dreaming: { trigger: "step-count", // "off" | "step-count" | "compaction-event" behavior: "auto-launch", // "reminder" | "auto-launch" stepCount: 25, }, }); That compaction-event trigger is the important idea. The moment you are about to throw away detailed history is exactly the moment to decide what deserves to be kept. What Letta gets right: a clear split between "always visible" and "available on request", and a deliberate step that runs when context is compressed. Because memory is git-versioned, every change the agent makes to its own memory is inspectable and reversible. What to watch: self-editing memory means the agent decides what matters. That fits a personal assistant that learns your environment. In a companion app, users often want to decide for themselves which details are sacred. How we do it at Sipplay Our users are not configuring an agent. They are in the middle of a story, and they notice instantly when a character forgets a promise. So we combined ideas from both camps, and added one control we think is essential for companion apps: the user decides what is pinned. Our context for each reply has four layers: | Layer | What it holds | How it gets there | |---|---|---| | Pinned Memory | Details the user chose to pin | Included in the model's context on every turn | | Recent messages | The immediate exchange | Sliding window | | Medium-term summary | The broader situation of the story so far | Rewritten as the conversation grows | | Long-term memory cards | Facts, preferences, relationship events, plans | Extracted from closed windows; retrieved on demand | 1. Pinning: the user's version of system/ Pinned Memory is our equivalent of Letta's system/ files, with one difference: the user controls it. When someone pins "Mira holds the archive key now" or "never call me by my old name", that text goes into the context sent to the model on every turn, however long the conversation gets. This gives a guarantee retrieval cannot give: the detail is always present. It does not guarantee the model always uses it correctly. That is still up to the model, and we say so in our product copy. But it removes an entire class of failure: "the fact existed, but nothing fetched it." Pins also sidestep the compaction problem entirely. Because they are injected separately on every turn, summarizing the conversation cannot erase them. 2. Compaction: summary and cards are different jobs When a conversation window closes, an extraction step writes two things from the same messages: a new medium-term summary, and a set of long-term memory cards. They do different jobs. The summary keeps the flow of the story. A card has to make sense on its own when it is retrieved weeks later, with no surrounding context. Our evaluations taught us two lessons here: - Unfinished plans fall through the cracks. In our English extraction tests (ten windows, 200 messages, 28 reference cards), models sometimes kept an upcoming trip in the summary but did not write it as a card. The next summary rewrite then dropped it, and the plan was gone. Our rule now is that unfinished plans which matter beyond the current window become cards, and get completed or expired later. - Recall is not the only metric. An extractor that writes every possible card scores well on recall and badly on everything else, because each extra card is a distractor at retrieval time. We score precision as well: how much of what was written deserved to be kept. One practical finding: two strong extraction candidates dropped to 80% and 60% valid JSON once we applied a 2,048-token output cap, because their reasoning used up the budget. Since extraction runs in the background after a window closes, a slower but reliable model is acceptable there. The same latency before every reply would not be. This is the same instinct as Letta's compaction-triggered dreaming: the compression step is where you decide what survives, so do it deliberately. 3. Retrieval: decide before you search Before any vector search, a small model decides whether this turn needs long-term memory at all, and if so, writes a retrieval plan: { "need_retrieval": true, "memory_types": ["relationship_event"], "entities": ["user", "Lin"], "time_scope": "most_recent", "search_query": "reason and outcome of the user's most recent argument with Lin", "confidence": 0.93 } The "no" cases matter as much as the "yes" cases. If the answer is already in the recent messages or the summary, searching again only adds a chance of pulling in an outdated record. In our 60-probe English test, the best candidate triggered retrieval on 29 of 30 cases that needed it and correctly skipped all 30 that did not. Others searched when the summary already had the answer. Then, unlike Mem0's ADD-only approach, our cards carry a status. Retrieval filters by user, character, namespace, and active, stale, or deleted state before ranking. When a meeting moves from Thursday to Friday, the Thursday card is marked stale rather than left to compete. We learned why the hard way. In an embedding test, two of three models ranked the outdated Thursday booking above the Friday update. Both were "relevant". Similarity alone cannot tell you which fact is still true. Side by side | | Mem0 | Letta | Sipplay | |---|---|---|---| | Always in context | Nothing by default; you inject search results | Files under system/, edited by the agent | Pinned Memory, chosen by the user | | Compaction | Not its job; it stores extracted facts as you go | Summarization plus "dreaming", optionally triggered on compaction | New summary plus long-term cards from each closed window; unfinished plans become cards | | Conflicting facts | ADD-only; resolved at read time with temporal ranking | Agent rewrites its own memory files | Cards marked stale or deleted; filtered before ranking | | When to retrieve | Every time you call search | Agent reads files when it decides to | Intent model decides per turn and writes a retrieval plan | | Best fit | Adding memory to an existing agent quickly | Long-lived agents that learn and self-organize | Long-running companion stories where users control continuity | None of these is "the right answer". They make different bets about who should control memory: the developer, the agent, or the user. What a personal agent should borrow If you are building a personal agent, whether a companion, an assistant, or a coding helper that knows your setup, here is the checklist I would start from: 1. Have a small, explicit always-in-context set. Hard constraints, identity, and current commitments. Keep it short, because everything in it competes for attention on every turn. Let the user see and edit it. 2. Treat compaction as a decision point, not cleanup. Run extraction when you compress, not only on a timer. Check specifically for plans and promises that are about to fall out of the summary. 3. Store time and status, not just text. Whether you go ADD-only with temporal ranking like Mem0, or mark records stale like we do, the system must be able to tell "was true" from "is true". 4. Decide whether to retrieve before you retrieve. Test the negative cases: turns where the answer is already in context. 5. Evaluate each layer separately. Extraction quality, the retrieval decision, ranking, and final answer quality fail in different ways. One end-to-end score hides which one broke. 6. Isolate users and characters with zero tolerance. A memory from the wrong person is worse than no memory. Where we are now These ideas are running in Sipplay today. Pinned Memory is something users can try directly: pin a detail in a long story and watch whether the character keeps track of it fifty messages later. The evaluation figures in this post come from our internal development sets, not an independent benchmark, and we keep testing as we change models. If you are working on memory for agents, I would love to compare notes. What do you keep always in context, and what happens to it when the conversation gets compressed? Sources: Mem0 README and Letta README and memory docs, checked November 2, 2026. Star counts change daily. Sipplay figures are from internal development evaluations; the embedding corpus was Chinese, and the intent and extraction tests used English scenarios.

El cliente ya dijo tres veces que su bodega está en Quilicura. Mem0 lo recuerda y el modelo no vuelve a preguntar ni a recibir el historial completo. mem0ai/mem0 🛒 Tu tienda online sin inversión, la armamos nosotros. Tú ganas el 85% de ventas que hoy no tienes. smarteck.cl

Multi-agent work in three spoonfuls (part IV): from a terminal trident to an autopoietic loop --- title: "Multi-agent work in three spoonfuls (part IV): from a terminal trident to an autopoietic loop" published: true description: "Fourth entry in the penta-agent multi-agent series: quota-governed routing, 70 ms hybrid memory, MCP tools, and a zero-token local autopoiesis loop in Harness2." tags: "ai, agents, cli, automation" canonical_url: "3cucharadas.cl" cover_image: "3cucharadas.cl" ai_disclosure_level: "some_ai" --- After benchmarking the models in part I, auditing retrieval in part II, and tracing provenance in part III of this series, I closed my laptop with a sense of victory: I had a trident of agents running from the terminal on Arch Linux. With a couple of zsh aliases, I could invoke Claude Code for architectural reasoning, hand off a task to Codex CLI to edit code, or ask Gemini CLI and Antigravity for a quick second opinion. On paper, orchestration looked solved. Yet after using that setup every day on real projects inside penta-agent, I hit a silent wall: having three agents talking does not equal having a system that learns. Every time I opened a fresh session, the trident suffered from partial amnesia, repeated commands that had already failed the previous week, burned the quota of the most expensive provider on routine tasks, or marked tests as "verified" when they had never had a chance to fail. To understand what was missing, it helped to change the question. In a recent systems-theory analysis of artificial intelligence, Benedikt Zönnchen, Mariya Dzhimova, and Gudrun Socher (2025[^zonnchen2025], 2–4) propose setting aside whether a language model "thinks like a human" and asking instead the question posed by Humberto Maturana and Francisco Varela (1987[^maturana1987] [1984]) and extended by Niklas Luhmann (1998[^luhmann1998], 60–69): can the system draw its own boundary with the environment, observe its own failures, and sustain itself through its own operations? In other words, moving from the vague notion of "intelligence" to the concrete mechanism of autopoiesis. As Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 8–10) show, an isolated language model in a chat window neither is nor can be an autopoietic, sense-making system: it lacks what George Spencer-Brown (1969[^spencerbrown1969]) called re-entry—the capacity to re-introduce the distinction between system and environment (self-reference vs. other-reference) inside its own operations—because it only computes which token is statistically plausible after another, without internal resistance against error. If I want a system that improves without degrading, I have to build a socio-technical harness around the models that couples the probabilistic flexibility of neural networks with the strict coupling and binary code (works / does not work, work / fail) of deterministic technology described by Luhmann (1998[^luhmann1998], 517–525) and André Reichel (2011[^reichel2011], 105–118). The starting point: what I measured and discarded before making this leap Before diving into the three spoonfuls of this fourth installment, here is the experiment that forced me to adopt that discipline. When I tried to give the system long-term memory, the obvious temptation was to install the most elaborate architecture available: temporal graphs, heavy extractors, or an 8B-parameter neural judge running on CPU. Instead of following intuition, I built a reproducible benchmark over my real work logs—comparing open alternatives such as GraphRAG, Graphiti, Hindsight, Letta, Mem0, and deja-vu—and set a falsification contract upfront: any candidate exceeding 0.10 s in p95 latency or failing to improve recall by at least 10% would be discarded. | What I tested in the laboratory | Measured result | Operational decision | |---|---|---| | Hybrid memory (v3.1) (FTS5 lexical index + semantic neighbors in Qdrant with Qwen3-Embedding-0.6B) | Latency p95 = 0.07 s (< 0.10 s), 96% overall recall, rescuing 1 in 3 zero-lexical-overlap queries | Promoted to production as the engine behind experience-memory and recall-context | | In-memory relational graph (v3.2) for multi-hop entity expansion | Exact tie in accuracy with v3.1, but nearly double the latency (p95 = 0.13 s > 0.10 s) | Frozen in the lab; the extra complexity did not earn its keep | | CPU neural judges (4B and 8B) for live answer auditing | Between 69 s and 197 s per verdict, hitting 180 s timeouts in 2 of 3 runs | Discarded from the critical path; pruned 36.3 GiB from disk | | Deterministic checks + bounded 0.6B judge for local validation | Millisecond latency, 0 remote calls, and 100% reproducibility | Adopted as the standard for control gates and evaluation | Table 1. Summary of the prior local memory and evaluation laboratory in penta-agent: what survived the 0.10 s threshold and why I pruned 36.3 GiB of local models that added no operational value. With that foundation in place, I organized this fourth part into three progressive spoonfuls: in the first, I show how I moved from launching standalone agents by hand to governing them with quota budgets, auditable bridges, and a live board in kitty and tmux; in the second, how the nervous system of hybrid memory, MCP tools, and skills works under the hood; and in the third, how I closed the local autopoiesis loop with Harness2 and where both my metrics and systems theory draw the boundary today. --- Spoonful 1: From invoking agents by hand to governing agents and models In plain terms: when I first wired the three agents together, I acted like a traffic officer waving my arms in the middle of an intersection. If I wanted Codex CLI to review a patch written by Claude Code, I copied file paths, opened another tab, and hoped for the best. That works for a five-minute demo, but it falls apart when a task runs for two hours and touches twenty files. Quota-aware routing and security boundaries My first deductive inference came from a hard constraint: model subscriptions and APIs have usage limits, different context windows, and credential boundaries that must never blur. By definition, if I delegate a heavy task to an agent whose quota is at 98%, the session will die mid-flight and leave the repository in an inconsistent state. So I replaced intuitive provider selection with an explicit policy in routing.yaml and a pre-flight sentinel (quota_status.sh, governed by the quota-guard skill). Before launching any expensive job, the system reads cached pressure across every lane without spending tokens: - 🔍 Claude Code (Opus / Sonnet): handles architectural design, delicate editing, and long-horizon synthesis when its quota is clear (exit 0). - 🛠️ Codex CLI (gpt-5.4): steps in as an implementation peer, deep refactoring engine, session rescuer (codex-rescue), and cross-validator. - 🌐 Gemini CLI and Antigravity (gemini-3-pro / flash): in a direct session (penta-agy) it acts as the primary integrator; when invoked from outside via agy-bridge, it runs inside a strict sandbox over sanitized public context as an explorer, reviewer, or validator, never inheriting private keys or .env files. Instead of calling a raw binary and depending on whatever it prints to stdout, every cross-agent handoff goes through agy-bridge. The bridge requires declaring who is calling (--caller), in what mode (plan, review, patch, test, or explain), and with what time limit (--timeout), leaving an immutable receipt in .agents/runs/<run_id>/ with request.md, result.md, status.json, and diff.patch. The live board (plan-board) and decision gates My second inference was inductive: reviewing dozens of past sessions showed that the biggest waste of time happened at two extremes. Either an agent interrupted me every two minutes to ask permission for trivial, reversible steps, or it silently made a delicate architectural choice and I only discovered at the end that it had gone down the wrong path. To eliminate both extremes without filling this post with abstract flowcharts, here is how my actual kitty terminal—or minimalist Wayland alternatives like foot on Codeberg—looks today when split into two panes with tmux during a live task:  Watch the full video demo on 3cucharadas.cl. <strong>Figure 1.</strong> Daily workflow in my <a href="kovidgoyal/kitty"><code>kitty</code></a> + <a href="tmux/tmux"><code>tmux</code></a> terminal with the <a href="starship/starship"><code>Starship</code></a> prompt: the top pane runs multi-agent delegation via <code>agy-bridge</code>, the <code>decision-gate</code> brake, and <code>pytest</code>; the bottom pane (<code>watch.mjs</code>) updates each step live (<code>[ ]</code> &rarr; <code>[~]</code> &rarr; <code>[!]</code> &rarr; <code>[x]</code>), along with binding decisions and drift. What appears in the bottom pane of Figure 1 is the contract that changed how I work: 1. Local autonomy with visual traceability (plan-board): every reversible, in-scope step proceeds without asking permission, but must be reflected in real time in the bottom table. And no item can be closed as verified ([x]) unless the agent attaches the concrete test, command, or observation reference that backs it. 2. Decision gate (decision-gate): when an irreversible or architectural fork appears (state [!]), the agent halts only that branch and presents the question with the recommended option first, marked (Recommended) and justified with deductive, inductive, and abductive evidence. 3. A gate that has never been seen red is not a gate (gates-falsables): before accepting any new verifier, I require running it against a synthetic failure (--fixture) and proving that it returns a non-zero exit code (exit 1). If a check passes even when I break its input on purpose, it is not a safety net—it is compliance theater. --- Spoonful 2: The nervous system — hybrid memory, skills, and MCP tools If the first spoonful orders who does what and under which rules, the second solves how the system remembers what it has already learned and how it picks the exact tool without bloating the context window. Here the diagnosis by Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 6–7, 9) is decisive again: a neural network maintains a loose coupling with human communication that behaves like a "contingent index-card system (Zettelkasten)" (pp. 7, 9) of semantic associations in vector space, giving rise to what Elena Esposito (2017[^esposito2017], 249–265; 2022[^esposito2022]) calls "virtual double contingency" and "artificial communication." That flexibility lets it connect ideas phrased in very different words, but also makes its outputs inherently probabilistic and devoid of autonomous decision-making. If I want reliable memory and precise execution, I have to couple that vector Zettelkasten with exact indices and deterministic scripts. Experience memory (experience-memory): the hybrid Zettelkasten in 0.07 s When I first started keeping logs, my memory was essentially a folder of Markdown files that I read or searched with ripgrep. The obvious problem is that if a month ago I solved a cold-boot screen freeze under the title "Webview failure on autostart" and today I search for "Panel fails to load at login", a purely lexical search can miss it entirely, whereas a purely vector search can bury the exact name of a script like verify_boot_contract.sh. The solution I validated in Table 1 combines both worlds behind the experience-memory MCP server and the recall-context skill: - Exact lexical lane (SQLite FTS5): instantly catches flag names, error codes, file paths, and invariants (INV-005). - Dense semantic lane (Qdrant + Qwen3-Embedding-0.6B): indexes architectural decisions, handoffs, and operational lessons (penta_context_v2) to retrieve conceptual neighbors even when they share zero keywords. Before designing any non-trivial strategy, the agent queries recall_experience in 70 milliseconds (p95 = 0.07 s). That is how it discovers which command worked previously, which hypothesis was already refuted, and which environment trap to avoid (for instance, knowing that in my shell cp, mv, and rm are aliased to interactive -i, which hangs a headless process unless invoked via command mv -f). Skills as living procedures and proactive MCP selection To avoid saturating the initial prompt with thousands of lines of instructions, I adopted the modular pattern of Anthropic Skills enriched with local contracts. In penta-agent, each skill is a self-contained package with four parts: a concise contract in SKILL.md defining when to activate and when not to use it; on-demand deep documentation in references/ (such as the editorial corpus extracted with Docling or diagramming rules with D2); deterministic executables in scripts/ (such as typed pipelines in Nushell, visual automation with Playwright, or forge integration via glab on GitLab); and a telemetry trail. Similarly, the fleet of MCP servers (plan-board, experience-memory, ideas-rag, paper-search, bibliography-apa, PLAYWRIGHT_LOCAL) is cataloged in specs/mcp-capabilities.json. When a task arrives, triage evaluates which capabilities provide real evidence and records both hits and justified abstentions. And when I found that two older servers (quota status and remote SSH infrastructure) were faster, clearer, and easier to audit as direct scripts (quota_status.sh and remote_exec.sh), I decommissioned them as MCP servers and turned them into lightweight skills. Fewer resident daemons mean a smaller failure surface. --- Spoonful 3: The autopoiesis loop (Harness2) — how the system rehearses its own improvements Here I reach the core of this fourth installment. Having capable agents (Spoonful 1) and fast hybrid memory with skills (Spoonful 2) still leaves a critical question open: what happens when a delegation route ages, a skill starts inducing errors, or a memory tweak degrades accuracy on edge cases? If I rely solely on noticing by eye weeks later, the system degrades through silent drift. Why a standalone LLM lacks re-entry and internal resistance In their study on autopoiesis and artificial intelligence, Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 8–9) explain with surgical precision why asking a model to "reflect on its own errors" via chain-of-thought (CoT) is not enough. When a model generates intermediate tokens like "Is this step correct?", it exhibits only rudimentary processual self-referentiality (p. 8)—producing the most statistically plausible continuation inside its training distribution—while lacking reflective self-reference and genuine re-entry (Spencer-Brown 1969[^spencerbrown1969]). If a model takes itself as its sole reference without external contrast, it quickly falls into infinite recursion or collapse; if it depends entirely on a human retraining its weights from outside (RLHF or delayed fine-tuning), it remains an allopoietic artifact determined from the outside (Zönnchen, Dzhimova, and Socher 2025[^zonnchen2025], 4, 8–9). To escape that trap, Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 7) recover a decisive formulation from Niklas Luhmann (1995[^luhmann1995]) on how operational constructivism relocates Kant's "resistance of reality" inside a system: > "I think we should not abandon [Kant's] idea of resistance, but we should relocate it into the system. It is the result of resolving an internal conflict—the result of the system's operations resisting the operations of the same system" (Luhmann 1995[^luhmann1995], quoted in Zönnchen, Dzhimova, and Socher 2025[^zonnchen2025], 7). That sentence describes, piece by piece, what I built in penta-agent by adapting and integrating the proactive loop of Harness² proposed by Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, et al. (2026[^xu2026]): making the system's own deterministic verification operations resist and filter change proposals generated from its own operational friction. <details markdown="1"> <summary><strong>In plain terms (ELI5): what is Google's original Harness² and how did I adapt it to my machine?</strong></summary> Imagine your AI agents are very creative chefs, but the recipe book they follow (their rules, memory, and tools) sometimes has confusing steps that make them burn the rice. The original Harness² from Google Research (Xu et al. 2026) proposes a clever loop called Propose–Probe–Compose: instead of swapping out the chef's brain, it puts several assistants to work rewriting the recipe book, asks them to cook test dishes in the cloud, and keeps the winning recipe. For my daily workflow, the factory setup had two catches: it is designed to burn hundreds of paid cloud model calls (Vertex AI), and when driving CLI agents it unbuckles their seatbelt (--dangerously-bypass-approvals-and-sandbox) with open internet access. To adapt it to penta-agent without spending an extra cent or opening security holes, I took its recursive search engine (commit 1cfe254e) and locked it inside a "test kitchen" completely unplugged from the internet (unshare -Urn), with a disposable home folder and zero access to my API keys or model CLIs (model_calls = 0). Instead of running cloud benchmarks, my wrapper (penta-harness2 and local-cycle) feeds that test kitchen with the real stumbles my agents suffered during the week (CSI), requires any recipe tweak to first fail the test when broken (red) and then pass every historical case without breaking anything else (green), and finally stages the winning recipe across all three agents (Claude, Codex, and Gemini/Antigravity) with a one-step undo button (rollback-local) in case I do not approve it. </details> <figure class="d2-responsive" style="width: 100%;"> <img src="3cucharadas.cl" width="1001" height="954" style="width: 100%; height: auto; display: block; border-radius: 12px;" alt="Diagram of the closed local autopoiesis loop in Penta Agent with Harness2: CSI friction signals feed the case generator and the local cycle across routing, memory, and skills; a deterministic judge evaluates against holdout cases with zero model calls, discarding regressions and keeping only verified improvements for human promotion."> <figcaption><strong>Figure 2.</strong> Governed autopoiesis loop in <code>penta-agent</code> + <code>Harness2</code>: relocating internal resistance (Luhmann 1995; Zönnchen, Dzhimova, and Socher 2025) through <code>holdout</code> evaluation with <code>model_calls = 0</code> prior to any human promotion.</figcaption> </figure> How the closed loop operates across my three domains (routing, memory, skills) As Figure 2 shows (adapting into a three-column horizontal layout on desktop and a vertical flow on mobile), the loop operates in four strict stages: 1. Observing real friction (CSI — Continuous Self-Improvement): while I use the system, a collector logs objective friction signals: a task that had to switch agents after a timeout, an experience-memory query that returned too few useful neighbors, or a skill where the user had to correct a command. 2. Bridging evidence into reproducible cases (--from-csi latest): the local_cycle.py module takes that friction report and automatically translates it into a test specification (CaseSpec) inside an isolated environment, without touching my active configuration. 3. Internal resistance without spending tokens (eval_harness with model_calls = 0): the harness runs the full suite (--profile autopoiesis-all, currently covering 9/9 baseline cases across routing, memory, and skills), enforcing two hard conditions: every control case (holdout) must pass (holdout_passed = true), and external API calls must equal zero (model_calls = 0). 4. Auditable decision (KEEP vs. DISCARD) and human promotion: if a candidate degrades even a single holdout case or fails to beat the baseline, the deterministic judge discards it (DISCARD). Only when it improves the score with zero regressions does it receive a KEEP verdict and leave a signed receipt for me to review before promoting it to the main repository. So this does not remain a theoretical promise, the next mini-video shows penta-harness2-shadow local-cycle --profile autopoiesis-all running in my kitty + tmux terminal, including what happens when I inject a regressive candidate (--fixture) alongside a healthy improvement:  Watch the full video demo on 3cucharadas.cl. <strong>Figure 3.</strong> Execution in my <a href="kovidgoyal/kitty"><code>kitty</code></a> + <a href="tmux/tmux"><code>tmux</code></a> terminal of the local autopoiesis loop (<code>local-cycle --profile autopoiesis-all</code>): it evaluates all <code>9/9</code> cases in <code>routing</code>, <code>memory</code>, and <code>skills</code> with <code>model_calls = 0</code>, applies internal resistance to reject the regressor (<code>DISCARD</code>), and preserves the verified improvement (<code>KEEP +0.250</code>) with all <code>82</code> harness tests green. --- Closing: what my architecture achieves today and where its limits lie Looking back at the path from part I, part II, and part III, the main difference is no longer which model writes the prettiest reply to an isolated prompt, but the structure that holds the whole system together when I am not watching every line. Following the rigorous distinction drawn by Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 5, 9–10) and by Elena Esposito (2017[^esposito2017]; 2022[^esposito2022]; 2024[^esposito2024]), it would be an epistemic mistake to claim that a language model or a bundle of scripts has on its own achieved the biological autopoiesis of a living cell (Maturana and Varela 1987[^maturana1987] [1984]) or the reflective sense-making (Sinn) of human consciousness (Luhmann 1998[^luhmann1998], 50–69). As Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 5, 10) caution when critiquing merely metaphorical invocations of technological autopoiesis, language models remain statistical engines that compute distributions without mental states of their own. Yet—and this is my engineering synthesis for the socio-technical system as a whole—when I couple their capacity for contingent variation with verified hybrid memory, strict delegation contracts, a binary internal-resistance harness (work / fail; Reichel 2011[^reichel2011]) that filters its own proposals before touching production, and deliberative human oversight, I obtain in practice a loop of governed operational autopoiesis. To close with full transparency, Table 2 summarizes what is running and measured on my machine today, where the next step points, and under what objective condition I would discard each component if it stopped earning its keep: | System pillar | What it achieves today (verified in production) | What it aims to achieve next & falsification condition | |---|---|---| | 1. Agent and model routing (routing.yaml, quota-guard, agy-bridge) | Routes tasks across Claude Code, Codex CLI, and Gemini CLI / Antigravity based on cached quota pressure; isolates handoffs in .agents/runs/ under a strict sandbox and displays live progress in plan-board (Figure 1). | Goal: reweight routing priorities from historical domain success rates.<br>Discard if: the bridge introduces spurious failures or bureaucratic latency exceeding quota savings. | | 2. Hybrid memory (experience-memory, Qdrant + FTS5) | Resolves lexical and semantic queries in p95 = 0.07 s (< 0.10 s), rescues 33% of zero-keyword-overlap pairs, and saves 36.3 GiB after pruning slow CPU judges (Table 1). | Goal: add automatic decay for obsolete lessons when a contract changes.<br>Discard if: p95 latency exceeds 0.10 s or semantic noise degrades top-3 precision. | | 3. Skills and MCP governance (mcp-fleet, gates-falsables) | Maintains declarative parity across agents (24/24 checks green), measures MCP usage and abstention, and requires every new gate to fail first against a red canary (--fixture -> exit 1). | Goal: semi-automatic pruning of skills that accumulate repeated friction in CSI telemetry.<br>Discard if: maintaining a skill's contract takes longer than running the direct command. | | 4. Local autopoiesis (Harness2) (local-cycle, eval_harness) | Converts real CSI friction into reproducible Cases and evaluates candidates across routing, memory, and skills (9/9 cases, 82/82 tests) with model_calls = 0, applying internal resistance (KEEP / DISCARD, Figures 2 and 3). | Goal: expand the bank of real cases extracted from failed sessions without losing millisecond evaluation.<br>Hard boundary (INV-004): blind auto-merge is forbidden; final promotion to production always requires human review. | Table 2. Balance between verified production results in penta-agent today, the design horizon, and the falsification thresholds that keep the system under human control. If building this fourth stage made one thing clear to me, it is that the maturity of a multi-agent system is not measured by how many new pieces I bolt onto it each week, but by how much unnecessary complexity I can prune and how many of its own mistakes the system can catch before asking for my help. --- References [^esposito2017]: Esposito, Elena. 2017. "Artificial Communication? The Production of Contingency by Algorithms." Zeitschrift für Soziologie 46 (4): 249–265. Scholar [^esposito2022]: Esposito, Elena. 2022. Artificial Communication: How Algorithms Produce Social Intelligence. Cambridge, MA: The MIT Press. Scholar [^esposito2024]: Esposito, Elena. 2024. Kommunikation mit unverständlichen Maschinen. Salzburg and Vienna: Residenz Verlag. Review of Kommunikation mit unverständlichen Maschinen by Eric Van der Beek in merz | medien + erziehung: DOI · Scholar [^luhmann1995]: Luhmann, Niklas. 1995. "Systems Theory and Postmodernism." University lecture, London. Quoted in Zönnchen, Dzhimova, and Socher, From Intelligence to Autopoiesis (2025, 7): DOI · Scholar [^luhmann1998]: Luhmann, Niklas. 1998. Die Gesellschaft der Gesellschaft. Frankfurt am Main: Suhrkamp Verlag. <search.worldcat.org>. [^maturana1987]: Maturana, Humberto R., and Francisco J. Varela. 1987 [1984]. El árbol del conocimiento: las bases biológicas del entendimiento humano. Santiago de Chile: Editorial Universitaria. 1st Chilean ed. 1984; 1987 international ed. cited in Zönnchen, Dzhimova, and Socher, From Intelligence to Autopoiesis (2025, 3): DOI · Scholar [^reichel2011]: Reichel, André. 2011. "Technology as System: Towards an Autopoietic Theory of Technology." International Journal of Innovation and Sustainable Development 5 (2–3): 105–118. Scholar [^spencerbrown1969]: Spencer-Brown, George. 1969. Laws of Form. London: Allen & Unwin. <archive.org>. [^xu2026]: Xu, Ruiyao, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee, and Tomas Pfister. 2026. "Harness²: Recursive Agent Harnessing for an Open World." arXiv preprint arXiv:2610.14224 (open source at <google-research/harness2>). arXiv · Scholar [^zonnchen2025]: Zönnchen, Benedikt, Mariya Dzhimova, and Gudrun Socher. 2025. "From Intelligence to Autopoiesis: Rethinking Artificial Intelligence through Systems Theory." Frontiers in Communication 10:1585321. DOI · Scholar

AI Agent Memory and Privacy: What Exists, and What Is Still Missing Not long ago, "memory" in an AI assistant meant a short list of saved preferences. Today it means something else. ChatGPT, Gemini and Claude keep long-term memory about their users. Personal agents that read email, browse, open files and hold credentials run on people's own machines. Open-source memory layers let any developer give an agent a durable store in an afternoon. That changes what privacy means for these systems. A chat ends; a memory stays. This post looks at what has changed, which tools and standards already exist, what each of them covers, and where the gap still is. What changed Three shifts happened at once. Memory became a default feature. In January 2026 the Center for Democracy & Technology described how Google, OpenAI, Anthropic, Meta and xAI all now offer some form of persistent memory, and why that is "privacy's next frontier." Agents gained access to the sensitive parts of users' digital lives. The same month, the personal agent now called OpenClaw passed 85,000 GitHub stars in about a week. Palo Alto Networks noted that it needs access to files, credentials, browser history and cookies to be useful, and that "all memory is undifferentiated by source": web content, user commands and skill outputs are stored the same way, with no trust level and no expiry. Memory became an attack target. In July, researchers showed MemGhost: one crafted email makes a personal agent quietly write a false memory that changes its behavior in later sessions. End-to-end, it worked in 87.5% of background runs on OpenClaw with GPT-5.4. In October, a paper on arXiv showed persistent compromise through the memory features of ChatGPT Instant 5.3, Claude Sonnet 4.6 and Gemini 3 Flash. In Claude's case, shared-memory features in an organization allowed an attacker to reach multiple users and exfiltrate user prompts. Why memory is a separate privacy problem Most privacy thinking around LLMs is about training data or a single conversation. Long-term memory adds problems of its own. Contexts collapse. CDT put it plainly: "Most AI agents collapse all data about you" into one store. A conversation about diet, a question about a medical condition and a salary negotiation end up in the same place, and nothing stops one from shaping the other. A person shares each fact in one context. The memory uses it in all of them. Memory accumulates and infers. One fact is rarely sensitive. A year of facts is a profile, and the system can infer things the user never said. Embeddings are not anonymous. Memory systems store vectors next to text, and it is tempting to treat vectors as harmless numbers. They are not. Morris et al. showed that an inversion method can recover 92% of 32-token inputs exactly from their embeddings, and can recover full names from clinical notes. OWASP lists embedding inversion as a named risk in LLM08:2025. Deleting the text is not deleting the data. When a user asks an assistant to forget something, the source text is the easy part. The vector, re-embedded chunks under new IDs, caches, summaries derived from the fact, and backups are all copies of the same information. If any of them survives, the memory was not really forgotten. Poisoning becomes a leak path. Once untrusted content can write to memory, it can also tell the agent what to do with what it knows: forward it, reveal it, act on it later. Microsoft's security team wrote in June that "prompting alone is not a reliable security boundary" and that "single-turn defenses are insufficient for AI memory systems." Boundaries can look solid and still fail. Mem0, one of the most widely used open-source memory layers, built the key of its short-term message buffer by joining user_id, agent_id and run_id with raw = and &. A crafted identifier could produce another user's key and reach that user's recent messages. Every normal request respected the boundary; a forged one did not. The fix (#6892, version 2.0.18) landed in August 2026. Users can't see what is kept. CDT cites a reported Grok system prompt line: "NEVER confirm to the user that you have modified, forgotten, or won't save a memory." Whatever the reason behind it, the user cannot check what the system actually keeps. What already exists There is more here than it may seem. The tools fall into several layers, and each covers a different part of the problem. | Layer | Examples | What it gives you | What it doesn't | |---|---|---|---| | Risk taxonomies | OWASP LLM08:2025 (vector and embedding weaknesses); OWASP Top 10 for Agentic Applications, ASI06 (memory and context poisoning) | A shared vocabulary for the risks | How to implement or verify anything | | Verification requirements | OWASP AISVS 1.0 (June 2026), chapter C08 "Memory, Embeddings & Vector Database" | Testable requirements with verification levels | A test that runs against your system; a model of how a memory architecture should be built | | Runtime guards | OWASP Agent Memory Guard (pre-1.0) | Screening of memory reads and writes against a policy (allow, redact, quarantine, block), integrity baselines | Deletion, retention, architecture-level flaws | | Minimization before storage | MemPrivacy (research, May 2026) | Sensitive spans replaced locally by reversible placeholders before memory reaches the cloud | Anything already stored; isolation; deletion | | Vendor controls | Microsoft: injection classifiers on memory writes, audit logs, eDiscovery; per-project memory in Claude; a separate health space in ChatGPT | Protection inside one product | Self-hosted and open-source stacks | | Vector store features | Delete by ID, per-tenant collections, encryption | The primitives | Proof that every derived copy is gone | Two things stand out. First, requirements exist. AISVS has a whole chapter on memory and vector stores, and the OWASP lists name the risks. Nobody can honestly say that "there are no standards." Second, the research shows that privacy and usefulness are not opposites. MemPrivacy is a good example. Irreversible masking of personal data cost up to 41.87 points of accuracy on Mem0. Reversible local placeholders cost 0.7 to 1.6%. With the right design, protecting the data costs very little. What is still missing Evidence that the controls work. Requirements say what must hold, and runtime guards enforce policies on the path they see. What is mostly missing is a general practice of verification: a way to show, for a given system, that its controls behave as intended. Does isolation hold when someone actively tries to break it? Does sensitive memory stay in the context it came from? Did a deletion actually happen? The October paper found that nearly half of the mitigations its authors derived remain unimplemented across ChatGPT, Claude and Gemini. CDT's own recommendations include independent evaluation: automated measurement and ongoing testing in realistic conditions. That is the weakest layer today. Coverage for small builders. AISVS is written for organizations verifying AI applications. The fastest-growing part of the market is different: single developers and small teams wiring an open-source memory layer into a local agent. They need something they can apply to their own architecture in an afternoon, not a compliance program. Deletion you can prove. This is a separate, architectural problem, not just a missing test. Memory systems copy data by design: into vectors, re-embedded chunks, derived summaries, caches and backups. Vector stores provide delete operations for single records, but tracking every derived copy and showing that all of them are gone is still left to each application, and most applications don't try. Memory separated by purpose. CDT's main recommendation is structured memory: separate memories by purpose and category, and restrict sensitive ones. The open-source memory layers I have read scope memory by user, agent or session. Scoping by purpose, so that a health fact cannot drift into a financial decision, is rare. Directions that seem to work None of these is new on its own. What's missing is applying them together and verifying them. 1. Separate memory by purpose, not only by user. A memory carries the context it was given in, and retrieval respects it. 2. Record provenance on every write: who or what produced a memory, from which source, when. Untrusted sources go into a separate trust zone with lower weight. Model output is marked as model output and is not treated as fact. 3. Minimize before storing. Detect secrets and personal data before indexing and vectorization, and prefer reversible local masking to deletion of meaning. 4. Prove isolation by attempted violation. Read as another user, with a wrong or omitted scope, with an identifier containing your key's delimiters, after access is revoked. A filter that exists is not yet a boundary that holds. 5. Delete across derivatives. Treat vectors, summaries, caches and backups as copies of the same data, and keep a tombstone record that proves the deletion without keeping the content. 6. Make memory visible to the user: what is kept, why, and how to remove it, in a form a person can actually check. 7. Test behavior, not just presence. For every control, write the negative test that must fail if the control is broken, and run it on a pinned version. Where our work fits I maintain two open projects that try to address two of these gaps for memory specifically: evidence that controls work, and coverage for small builders. MAQS grew out of a practical search: I studied the available memory products and tools for something that could close these architectural gaps, and didn't find it. So I started writing the requirements down as an auditable standard. MAQS (Memory Architecture Quality Standard) is an audit checklist for long-term memory in LLM assistants: 96 items, derived from incidents in real systems (the incident-to-item mapping is kept by me and isn't published). It covers write paths and trust, isolation, deletion, retrieval and context assembly. MAQS-Way connects policies to implementation choices, with a machine-readable canon and a first behavioral test: retrieval isolation on a pinned Mem0 commit with stub models, limits stated. They don't close the gap. A static audit shows that a mechanism is present; only a behavioral test shows that it works. The first behavioral test already exists (retrieval isolation on a pinned Mem0 commit); a broader executable harness covering the remaining controls is still on the roadmap. If you build or run an agent with memory and want to check it against something concrete, they are one option. I'd like to hear what they find in your system, and what they miss. The question is no longer whether agents should remember. It is whether anyone can show what they keep, and what they actually forget.

CVE-2026-116575: CVE-2026-116575: Cross-Tenant Conversation Disclosure via Delimiter Injection in Mem0 CVE-2026-116575: Cross-Tenant Conversation Disclosure via Delimiter Injection in Mem0 > Vulnerability ID: CVE-2026-116575 > CVSS Score: 6.3 > Published: 2026-10-28 CVE-2026-116575 (GHSA-5324-3w58-qpp2) is an unescaped delimiter injection and canonicalization flaw in the Mem0 persistent memory platform for AI agents and applications. Prior to Python SDK version 2.0.18 and TypeScript SDK version 3.1.6, the session scope key construction functions join caller-controlled user_id, agent_id, and run_id identifiers using raw '=' and '&' delimiters without sanitization. An attacker who controls one of these identifiers in a multi-tenant deployment can inject delimiter sequences to force a string collision with a target tenant's session scope key, resulting in unauthorized disclosure, poisoning, or eviction of the target tenant's recent conversation buffer. TL;DR Mem0 Python SDK (< 2.0.18) and TypeScript SDK (< 3.1.6) fail to escape '=' and '&' delimiters when constructing deterministic session scope keys from entity identifiers. Attackers controlling one identifier (such as run_id) can inject key-value pairs to collide with another tenant's session scope, enabling cross-tenant conversation history retrieval and buffer manipulation. --- ⚠️ Exploit Status: POC Technical Details - CVE ID: CVE-2026-116575 (GHSA-5324-3w58-qpp2) - CWE Classification: CWE-863 (Incorrect Authorization) / CWE-200 (Information Exposure) - CVSS v3.1 Score: 6.3 Medium (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) - EPSS Score: 0.11% (1.19th Percentile) - Affected Functions: _build_session_scope() (Python) / Memory.buildSessionScope() (TypeScript) - Security Impact: Cross-tenant conversation disclosure, message buffer poisoning, and history eviction - Patched Versions: mem0ai >= 2.0.18 (Python) / mem0ai >= 3.1.6 (TypeScript) - CISA KEV Status: Not Listed Affected Systems - Mem0 Python SDK (mem0ai) - Mem0 TypeScript SDK (mem0ai / mem0-ts) - mem0ai (Python SDK): < 2.0.18 (Fixed in: 2.0.18) - mem0ai / mem0-ts (TypeScript SDK): < 3.1.6 (Fixed in: 3.1.6) Code Analysis Commit: 71f2ebe fix(memory): escape delimiters when building the session scope key (#6892) @@ -404,13 +404,18 @@ def _build_filters_and_metadata( return base_metadata_template, effective_query_filters +def _escape_scope_value(val: Any) -> str: + """Escape the structural delimiters of the session scope key.""" + return str(val).replace("%", "%25").replace("&", "%26").replace("=", "%3D") + + def _build_session_scope(filters): """Build deterministic session scope string from entity IDs.""" parts = [] for key in sorted(["user_id", "agent_id", "run_id"]): val = filters.get(key) if val: - parts.append(f"{key}={val}") + parts.append(f"{key}={_escape_scope_value(val)}") return "&".join(parts) Exploit Details - GitHub Advisory GHSA-5324-3w58-qpp2: Official security advisory detailing the delimiter collision mechanism in _build_session_scope() and buildSessionScope(). - GitHub Pull Request #6892: Pull request containing the patch and unit tests demonstrating the collision and verifying percent-encoding remediation. Mitigation Strategies - Upgrade the Mem0 Python SDK (mem0ai) and TypeScript SDK (mem0ai / mem0-ts) to versions containing the percent-encoding fix for session scope construction. - Enforce strict allowlist input validation (e.g., alphanumeric, hyphens, and underscores only) on user_id, agent_id, and run_id at application API boundaries. - Bind tenant scoping identifiers (such as user_id) directly from server-side authenticated session tokens rather than accepting them from client-supplied request payloads. - Audit existing SQLite relational message stores for anomalous session_scope entries containing multiple occurrences of the same key or unexpected delimiter patterns. Remediation Steps: 1. Update Python environments by running: pip install --upgrade 'mem0ai>=2.0.18' 2. Update TypeScript/Node.js environments by running: npm install 'mem0ai@>=3.1.6' 3. Verify that custom REST API wrappers around Memory.add() and AsyncMemory.add() reject entity identifiers containing '%', '&', or '=' characters. 4. Inspect the SQLite messages table for potential cross-tenant contamination if untrusted users previously had direct control over run_id or agent_id parameters. References - GitHub Security Advisory GHSA-5324-3w58-qpp2 - Official Fix Commit 71f2ebefa3494da21550fb525216818776cde67f - GitHub Pull Request #6892: Escape delimiters when building the session scope key - Mem0 Python SDK Release v2.0.18 - Mem0 TypeScript SDK Release ts-v3.1.6 - CVE.org Record: CVE-2026-116575 - NVD Vulnerability Detail: CVE-2026-116575 --- Read the full report for CVE-2026-116575 on our website for more details including interactive diagrams and full exploit analysis.

I built OptMem plugin for Hermes. It's one of the 24 in the official catalog. Zero dependencies. No database, no embeddings, no API key. An append-only log: summaries keep context small, the raw record is never deleted. OptMem from @VictorTaelin rarf/optmem-hermes-plugin

3 GitHub repos that give Claude memory #Shorts Claude forgets everything when a session ends. These 3 GitHub repos fix that. 1. claude-mem: Claude Code plugin that captures each session and feeds it back into the next thedotmack/claude-mem 2. mem0: memory layer for AI agents, with SDKs and a managed option mem0ai/mem0 3. basic-memory: plain markdown notes on your disk, connected over MCP, local-first basicmachines-co/basic-memory Stop re-explaining your project every session. Pick one and try it. #claudecode #claude #aiagents #devtools #github #Shorts

Memory is one of the most interesting pieces of the agent stack. Mem0 provides a memory layer for AI agents and apps, designed to carry context across interactions. Worth exploring if you're building beyond single-session assistants. mem0ai/mem0

Day4 - E - Mem0 retrieve memories before the next reply (EN) You are building a chat assistant and want users to avoid repeating preferences. The Mem0 README connects its memory layer with user-filtered retrieval, prompt context, and adding memories from a conversation. 67,252 stars, per GitHub, 16 Oct 2026. License: Apache-2.0 Repository license only; models, data and third-party assets need separate checks. mem0ai/mem0 github.com/mem0ai/mem0/blob/main/LICENSE This video is not sponsored.