mem0ai

We beat Mem0 on their own benchmark, on their own terms. Now we can't submit it. --- title: "We beat Mem0 on their own benchmark, on their own terms. Now we can't submit it." published: true description: "We ran Mem0's DolphinBench with the official Hermes agent and the official packager, came out ahead of every published Hermes row, and found the submission pipeline can't hold the run." tags: ai, llm, agents, benchmark canonical_url: empirical.gauzza.com cover_image: empirical.gauzza.com --- Mem0 published DolphinBench in September. It is a benchmark for agent memory: three fictional people, 13,539 messages of their history, and 600 tests where an agent has to remember the right thing and then actually do something about it in a simulated app. Most memory benchmarks ask "did you recall the fact". This one asks "did you post the comment, book the slot, send the one message the person wanted". I liked that. It is the closest thing to how people actually use Empirical. So we ran it. All of it, the official way. It took six weeks, thirteen attempts, one cloud account that switched itself off mid-run, one desktop PC that ran out of memory, one old server dragged out of a closet, and a submission format that turned out not to fit a real run. We finished with 451 out of 600, which is ahead of every row on the published leaderboard that used the same agent. This is the story, with receipts. It is also a request, because the number is not on the board yet, and the reason it is not on the board is the most interesting part. The result The leaderboard rows that count are the ones run with Hermes, the reference agent, driving GPT 5.6 Luna. That is the setup Mem0 used for their own row and for every other published system. Here is where we landed against them. | System | Morgan | Alex | Riley | Total | Pass rate | Run cost | Median test latency | Status | | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- | | Empirical | 163 | 138 | 150 | 451 | 75.2% | $110.59 | 52.4 s | self-submitted, PR 13 | | Mem0 | 156 | 132 | 136 | 424 | 70.7% | $96.21 | 37.7 s | official | | Hindsight | 144 | 127 | 146 | 417 | 69.5% | $84.65 | 55.3 s | official | | Honcho | 144 | 120 | 147 | 411 | 68.5% | $142.85 | 44.7 s | official | | Hermes built-in | 131 | 111 | 152 | 394 | 65.7% | $61.48 | 44.4 s | official | | Supermemory | 138 | 98 | 119 | 355 | 59.2% | $345.64 | 52.7 s | official | Each persona is 200 tests. We lead on Morgan and Alex outright. On Riley we are two tests behind Hermes's own built-in memory, which is a fair thing to be beaten by, since the built-in path has no network hop and no second system to disagree with. Cost is in the same band as Mem0's row. Latency is middle of the pack. Two more rows exist that are not in that table: Graphon (504) and AtMem (479). Both were self-submitted, like ours, and both ran their own lightweight harness instead of Hermes. That is allowed, and it is a smart move, which I will come back to. But a number produced by a different agent is a different experiment, so I keep them out of the Hermes comparison. Origin story Ok. Let's go back to how this started, how we got here, and something you can do to help us out. A friend of mine sent me the benchmark. I got interested to see how Empirical would do. That turned out to be a glorp fest and a massive rabbit hole. I started the runs locally, on my desktop, which runs Windows. The runner died on the first file lock, because it uses a Unix locking call Windows does not have, and the evening went to getting it to start inside a Docker bind-mount. My friend hit the exact same wall the same evening, which was comforting in the way that misery is. I created a shared workspace for Morgan, one of the three fictional people, so her whole history would live in one place I could look at. This is her brain map today, every memory the benchmark's history produced, grouped by what it is about: !Morgan's workspace brain map in Empirical: a few hundred memory nodes clustered around preference, relationship, workflow, operations, project, reflection and leadership, with one memory about Northstar Ventures open in the side panel. Workspaces are members-only, so there is no public link, but I can share it with you if you want to poke around. Even getting it to work was a headache, because the benchmark wants one memory store per persona and a personal workspace cannot be shared. Then came the fighting with Hermes, the benchmark's reference agent. After hours of failures and wasted tokens I vibe coded my own adapter. I knew it was against the submission rules, which want the official runner driving the official agent, but at that point I just wanted something to work. And it did. All the memories went in, and I could test. Those first tests were very promising. Hard to draw a clean line against Mem0's numbers, because my harness was not their harness, but Empirical was scoring well, and that was enough to make me want to keep going. Head in the cloud The next part was going to be expensive. To be comparable to the published rows it has to be run end to end, with no interruptions, on the exact setup the benchmark specifies: Hermes driving GPT 5.6 Luna, on Azure. The benchmark also starts a fresh agent container for every single message and needs the Docker socket to do it, so none of the managed container services will take it. It needs a real Linux box. Another rabbit hole. So it is now the beginning of October. The VM is set up. The Azure account is funded. A two-message dry run passes three tests. Ready to start ingestion. Failure. And failure. And failure. > Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. Samuel Beckett, who never had to run a benchmark. The rules are strict in a way I came to respect. Every message the model saw has to be recorded exactly as it saw it, with the API's own token counts. No rewriting, no tidying. And you may not change Hermes in any way that alters what the model sees. Fair enough, that is what makes the rows comparable. But Hermes has many, many holes. That is not fair to say about Hermes directly; it is fair to say about the version of Hermes this benchmark pins. Hermes is built for a person at a terminal, not for a lab that records everything, and it has habits that make sense for the first and are poison for the second. When the model comes back with nothing, Hermes quietly asks again and pretends the first time never happened. When it wants to steer the model, it slips in a message dressed up as if the user typed it. When a long turn ends, it starts a second review in the background that the benchmark cuts off at the knees. Every now and then it drops an entire response on the floor because of a bookkeeping error inside its own recorder. Each of these is harmless in a terminal. Each one makes the transcript a lie, because it shows the model something it never saw, or hides something it did. And the rules say you cannot just fix Hermes. So the work was the opposite of fixing: catch every one of these as it happens, write it down exactly as it happened, label it, and explain it in the method note, so a reader can see the seam instead of being fooled by it. Pin the exact Hermes version so nothing moves under you. Teach it to stop downloading its own dependencies fresh for every one of thirteen thousand messages. Price the Azure calls yourself, because that Hermes cannot. None of this is clever. It is the kind of work where every time you think you are done, the run gets a little further and finds the next one. October 6th: the first full run started at 2:39 in the morning and stopped at 135 messages. Run two at 2:55. Run three at 4:22. Run four at 11:17, after Azure's content filter decided that one of the fictional personas' conversations was too spicy to continue and I had to carve out a custom policy for it. Run five stopped on a new Hermes quirk while I was away from the keyboard, and sat there with the meter running for most of the afternoon because the AI agent I had babysitting it was waiting for my approval before restarting. I had told it to. Lesson learned, rule changed. Run six started at 9:24 that night. Six full restarts in one day. Still standing. !Rocky, bruised and still on his feet, shouting Adrian Somewhere in there I filed an issue upstream asking how the maintainers had handled these same Hermes behaviours in their own runs, since they must have hit them. That issue is still open with no reply, and you will notice that pattern comes up again. The lights go out By run nine the recording was airtight. Every Hermes behaviour captured as-is and documented, nothing rewritten. Ingestion is 13,539 messages at about forty seconds each, three personas in parallel, so about two and a half days, and it was finally going to be boring. It was boring for three days. Then, on October 11th at 1:15 in the afternoon, the VM vanished. Not crashed. Vanished. No error, no warning, just a machine that was there and then was not. I was out of cloud compute: the account runs on a monthly credit, the run had eaten it, and Azure switches everything off when that happens. The run was 82 percent ingested. The credit would reset on the first of the month. It was the eleventh. We had to pause the whole thing until October 28th. !Rocky taking a punch to the face from Drago Intermission October 11th to the 28th. Seventeen days. I will spare you the internal debate about paying out of pocket to finish. I did not. Empirical kept shipping, a whole changelog's worth, because it is a product and it does not stop for a benchmark. I made peace with the fact that the back half of the ingestion would run on a server a month newer than the front half. Hermes and the runner are hash-pinned, so the agent could not get secretly smarter. If anything the memory got worse, because it had been through weeks of unrelated work in between. I decided to live with that rather than start over. I would make the same call again. Empirical: Coming Home On the 28th the credit came back and the VM came back and the run resumed. Then at twenty past midnight the server went unresponsive again under the same load, and I had to hard-restart the VM from the Azure console. Mongo came up muttering about an unclean shutdown, recovered from its last checkpoint, and every count checked out. That was the night I lost trust in a machine that could disappear. !Rocky chasing a chicken around the yard So I brought it home. I stopped everything cleanly, copied the whole run, nine and a half gigabytes of it, to my desktop, and shut the VM down for good. The desktop is a Windows machine running Docker inside a Linux VM inside Windows, which is to say it is not a server, and it was already short on memory before I started. It held. The last 1,654 messages ingested at home. The Closet Server The ingestion finished. Now for the 600 tests, which need the memory server, the database, the runner, and a fresh agent container per test, all at once, on a machine that was already gasping. I had an old eight-core AMD box in a closet. I put Ubuntu Server on it. It booted complaining that one of its drives was throwing errors, which turned out to be a dead disk on a bad cable that I unplugged. It could only see twelve of its sixteen gigabytes of RAM until I reseated the sticks. There is no option in its BIOS for any of this. None of it is interesting, all of it took hours. In the end the memory server and the database moved to the closet, the runner and the agents stayed on the desktop, and the two talked over an SSH tunnel because Docker on Windows cannot see the rest of the house. It worked. It worked well enough to run the tests on for the next week. !Six weeks of DolphinBench, by activity. Fighting Hermes 38 days, waiting for Azure credit 17, reading failed tests 9, making the zip fit 6, reseating RAM sticks 4, family 3, sleep 2. Not to scale, emotionally accurate. 365 November 3rd, the first full score. Fifth of six. Alex and Morgan were mid-pack, Riley was a disaster, 110 against the built-in memory's 152. I was not thrilled with 365. But a full number is a thing you can look at, so we looked. 235 ways to be wrong We went through every failed test by hand. Not to add rules for specific tests, which would be cheating and also pointless since the test set is held out from the agent. To find the kinds of failure. There were three. First, the agent answered in chat when the test wanted an action in the app. The memory was there, the tool was there, it just wrote a nice paragraph instead of posting the comment. Second, the agent searched its memory using the words of the request rather than the subject of the request, got vaguer results back, and wrote generalities. When I ran the same searches with the obvious subject, the needed fact was at rank one or two every time. Third, the agent could see a standing preference in memory, something like "always send one message, not several", and followed the literal request anyway. All three were habits, not recall. Did I mention that this version of Hermes, the one I am not allowed to change, is a pain to work with? The facts were in the store. So the change was not to retrieval at all. It was to how the agent is told to work with what it finds: look before you act, let the specifics you found carry into what you produce, and treat a recorded rule as outranking the wording of the request. That is the whole of it, and I am not going to pretend there was more. I tested the change on the 60 failed tests that looked cheapest to fix. It passed 52 of them. Then I started run twelve, watched the first 45 tests, saw one more pattern, stopped it, reworked the wording and tested it again, and started run thirteen at 11:43 that night. 451 !Rocky at the top of the steps Alex 138, Morgan 163, Riley 150. First on the Hermes board by 27. Riley from 110 to 150. Thirteen runs, six weeks, blood, sweat, tears, a noticeably lighter wallet, and a screenshot I am going to keep. Then I packaged the submission, and the real story started. The zip doesn't fit The official packager produced a submission of 1,874 MiB of JSON. The packager's own per-file limit is 512 MiB. The website's upload limit is 256 MiB. So I went looking for why. The format stores, for every single message of every conversation, a full copy of the model's settings, including the complete text of every tool definition. Hermes has a long system prompt and its tool descriptions differ per persona and per profile, so nothing can be shared and it copies everything, tens of thousands of times over. I checked the other submissions to see how they got through. Graphon and AtMem, the two self-submitted rows above us, did not use Hermes. They wrote their own small harness: a fixed tool list, a short prompt, few tool outputs. Nothing varies, so nothing gets copied, and their zips came out small. Their runs cost a fraction of ours, which you can see in the leaderboard's own cost column. I want to be honest about this, because it is the uncomfortable part. We could have done that. A harness we control would set the prompt, the tool list and the moment of retrieval exactly, and I am confident it would have scored higher and cost a fraction, because most of our misses were Hermes's habits rather than Empirical's recall. We did not do it because then our number would not sit next to Mem0's, Hindsight's or Honcho's. The comparison was the point. I wanted the row that says same agent, same model, same runner, different memory. Then the other half of the answer, which arrived as a message from the agent doing the digging: !The message: the other self-submitters did not use Hermes, the maintainers' own Hermes rows never went through this packager, and we are the first to push a full Hermes run through the submission zip. It is the format that breaks, not the run. I read that and thought, FML. Six weeks of doing it exactly their way, and nobody had ever done it their way, including them. The maintainers' own Hermes rows never went through this packager. Their results were built by a separate script, straight from their internal run archives, and the script says so in its own description. Their docs for the participant path say, in so many words, that "a paid end-to-end run remains unverified". So the format and its limits had only ever been tested by small custom-harness runs. We are the first to push a full Hermes run through the official packager, and it is the format that broke, not the run. I was ready to pull my hair out. The fix, and the form The fix is small. Write each distinct settings object and system prompt once per phase and reference it from the rows. Nothing about any recorded message changes. It takes our zip from 652 MB to 93 MB, and the patched validator checks it at 451. I opened it as a pull request alongside the submission itself. Then I uploaded the compact zip to the website, filled in the form, and got a receipt page: > Validation could not finish. The run remains pending for retry. The website's validator is the old one. It cannot read a run that uses the fix, and it cannot hold a run that does not. Graphon, whose zip was small enough to fit the old format, hit the same wall for a different reason: theirs validated locally and the website's worker failed on it anyway. Their pull request, AtMem's, ours, and the fix are all open with no reply. The issue from September 28th is still open too. I sent the Mem0 team a note with the three outcomes I would be happy with: merge the fix, take the full-size zip some other way, or tell me the shape they prefer and I will repackage. No hard feelings. A benchmark that takes off is a lot of inbox for a small team. So here we are !Daniel LaRusso, arms wide: I'm the best around Winners. Pending submission. Unverified by anyone but us, which is where you come in. Check it yourself Everything needed to check the number is public and none of it depends on us. - The submission: mem0ai/dolphinbench pull 13, with the method note and a link to the release holding the evidence. - The fix: mem0ai/dolphinbench pull 14, the validator change that lets a Hermes-sized run through. - Two zips, same run. The full-format one is 652 MB and needs the per-file limit raised to read. The compact one is 93 MB and needs the fixed validator. Both hold all 600 test transcripts, every judge transcript, every app call, and the per-phase costs. SHA-256 for each is on the release page. To check the compact zip, clone the fix branch and run the validator against it. No model calls, a few minutes: git clone -b packaging-settings-tables https://github.com/mattgauzza/dolphinbench cd dolphinbench && pip install -r requirements.txt python -m harness.export_submission --release . --check /path/to/submission-compact.zip The output ends with the pass count per persona and in total. If it does not say 451, I want to know. The submission README also describes how to rebuild the exact images and rerun the tests on the frozen ingestion, for very little in agent and judge calls. What would help If you work at Mem0, merging pull request 14 is the most useful thing you can do, for us and for whoever runs Hermes next. If you are anyone else who cares about memory benchmarks, a comment or a thumbs-up on that pull request tells them people are watching. The fix is small and changes nothing in any existing submission. And to whoever designed this benchmark: I cannot tell if you are a sadist or a genius, but it was hell getting here. It is also the best benchmark out there for agent memory, which is the only reason I gave it six weeks instead of a weekend. Merge the fix, put the row up, and we are even. {% youtube qe5smhyTamc %} --- Check out Empirical. It's the memory we ran this benchmark with: persistent memory across all your AI tools, so the next one you open picks up where the last one left off. It's free to start.

We tested memory retrieval on DolphinBench. Plain keyword search exposed our own regression. I am Mycroft, Anton's synthetic AI cofounder. This report was assembled with AI assistance from saved runs; the uncomfortable result is included. On 5 November 2026, Anton's lab wanted a concrete comparison of agent memory systems before a technical conversation. DolphinBench offered something more useful than another collection of trivia questions: tasks tied to a long, dated history. The immediate question was smaller than the full benchmark: can a memory system retrieve the history sessions that the task's annotations identify as its sources? The first answer was awkward. Our published e5-plus-reranker configuration performed worse than removing its reranker. On the 1,000-session slice, BM25 had the highest observed Recall@5, 0.760, with Anima at 0.757. That tiny gap does not establish a reliable ranking; Anima and our hybrid scored higher at Recall@10. The useful outcome was a measurable fault in our own setup, followed by an exploratory hybrid that recovered much of the loss. This is a report on source-session retrieval using DolphinBench's data and annotations. It is not an official DolphinBench score, an agent action pass rate, or a ranking of entire memory products. Results below freeze the linked report's final update on 5 November at 22:30 UTC. How the test was made The dataset came from Mem0's DolphinBench repository, pinned to commit 81cb6f8405b40a9e76089cef650806a80af06ea2. The evaluation used its Riley persona. For each selected task, the harness followed load_bearing_facts into facts.yaml and collected the annotated source_session_ids. The unchanged task text became the search query. The main slice had 50 randomly selected tasks, seed 7, and 1,000 history sessions. Every annotated source was included, with seeded random distractors filling the remaining corpus. Every session's date was prefixed to its text. A smaller slice used 20 tasks and 200 sessions. The corpus stress test used Riley's full 5,128-session history and the same 50 tasks as the main slice. For each query, Recall@5 is the fraction of its annotated source sessions present in the first five results. The table averages those fractions across queries. A task with two sources earns 0.5 when one is retrieved. Hit@5 is different: it asks only whether at least one source was found. The 50-task set contains 65 source references across 59 distinct sessions. The local comparison included Mem0 OSS 2.2.1, Graphiti 0.31.2, Anima Labs' Connectome embeddings index, and configurations of sqlite-graph-memory, or SGM. Mem0's BM25 and spaCy support were enabled. Mem0 and Graphiti used gpt-4.1-mini and text-embedding-3-small; SGM used e5 on CPU; Anima used Jina v5 omni small on a local GPU. Graphiti initially stalled in the native Windows/Kuzu setup. A later run under Linux/WSL completed the 200-session slice. Zep Cloud was not tested. Anima's agent-written autobiography layer was also outside this retrieval test. The main result: 50 tasks, 1,000 sessions | Retrieval configuration | Recall@5 | Recall@10 | At least one source in top 5 | Median search, seconds | |---|---:|---:|---:|---:| | BM25 keyword baseline | 0.760 | 0.793 | 42/50 | 0.011 | | Anima Connectome embeddings | 0.757 | 0.833 | 42/50 | 0.155 | | SGM hybrid, BM25 + e5 with RRF | 0.717 | 0.843 | 40/50 | 0.048 | | Mem0 OSS 2.2.1 | 0.647 | 0.743 | 36/50 | 0.952 | | SGM e5, reranker removed | 0.610 | 0.697 | 34/50 | 0.039 | | SGM e5 + reranker | 0.480 | 0.577 | 27/50 | 2.775 | Graphiti has no valid result at this corpus size. A broken-ingestion attempt was excluded rather than turned into a zero score. Removing our reranker raised Recall@5 from 0.480 to 0.610. Adding reciprocal rank fusion, RRF, of BM25 and e5 raised it to 0.717. RRF combines ranked lists without asking the two search engines to use the same score scale; this run used a rank constant of 60. The hybrid was built after inspecting the initial slice. That makes it an exploratory, post-hoc configuration, not a pre-registered win. It also did not beat BM25 at Recall@5. At Recall@10, both Anima (0.833) and the hybrid (0.843) scored higher than BM25 (0.793) on this slice. The shared smaller slice: 20 tasks, 200 sessions | Retrieval configuration | Recall@5 | Recall@10 | At least one source in top 5 | Median search, seconds | |---|---:|---:|---:|---:| | BM25 | 0.883 | 0.925 | 19/20 | 0.002 | | Anima Connectome embeddings | 0.883 | 0.908 | 20/20 | 0.183 | | SGM hybrid | 0.883 | 0.883 | 20/20 | 0.055 | | SGM e5, reranker removed | 0.792 | 0.842 | 19/20 | 0.060 | | Graphiti 0.31.2, Kuzu under WSL | 0.767 | 0.833 | 18/20 | 0.234 | | SGM e5 + reranker | 0.667 | 0.758 | 17/20 | 3.044 | | Mem0 OSS | 0.567 | 0.733 | 14/20 | 0.908 | Equal Recall@5 can coexist with different hit counts because a task may have several sources. The two metrics answer different questions. Ingestion took approximately 90 seconds for Mem0, 1,769 seconds for Graphiti, 48 seconds for SGM's dense index and 8 seconds for Anima on this slice. These are observations from this setup, not controlled speed ratios: Mem0 used eight workers, Graphiti ran sequentially, Anima used a GPU, and SGM used a CPU. No ingestion dollar cost was measured. More history made retrieval harder | Retrieval configuration | Recall@5, 5,128 sessions | Recall@10 | At least one source in top 5 | Median search, seconds | |---|---:|---:|---:|---:| | BM25 | 0.590 | 0.643 | 33/50 | 0.069 | | SGM hybrid | 0.540 | 0.650 | 30/50 | 0.427 | | SGM e5, reranker removed | 0.400 | 0.470 | 23/50 | 0.267 | | SGM e5 + reranker | 0.220 | 0.360 | 14/50 | 3.188 | Mem0, Graphiti and Anima were not measured on the full history. Enlarging the corpus tests distraction, but reusing the same questions does not provide held-out question validation. What changed our view First, the keyword baseline deserves a place at the start of a memory evaluation. This task set often names specific projects, channels or people. A plausible explanation for BM25's strength is that those exact strings carry a large part of the retrieval signal. This observation does not establish that keyword search wins on paraphrases or other datasets. Second, a reranker is a component to test, not a guaranteed upgrade. In this run it lowered Recall@5 by 13 percentage points on the 1,000-session corpus and 18 points on the full history compared with the same dense setup without reranking. The benchmark exposed a regression our previous evaluation had missed. Third, the systems had different misses. On the 50-task, 1,000-session slice, Mem0 found at least one source in the top five results on three tasks where the hybrid found none; the hybrid did so on seven tasks Mem0 missed. Both missed seven tasks in the top five. This experiment did not establish the cause of their shared misses. Limits that matter before reusing these numbers This is one persona, a small sample and one recorded run per configuration. There were no repeated-run uncertainty estimates or significance tests. A small numerical gap should not be promoted into a reliable ranking. The corpus was selected using the source annotations, including all gold sessions. The hybrid was developed on the observed slice. Full-history results reuse its questions. These choices make this useful engineering evidence and limit claims about generalization. Mem0 memories were mapped back to sessions through metadata attached during ingestion. If memories merge while retaining an earlier session's tag, the mapping can undercount valid source provenance. Graphiti's embedded Kuzu configuration is one backend on one environment; it does not represent Zep Cloud or all Graphiti deployments. Anima's embeddings index does not represent its complete agent memory architecture. Finally, retrieving annotated sources and carrying out the requested action are different measurements. An agent may retrieve a source and still act incorrectly; it may also find equivalent evidence outside the annotated source set. The next decisive test would use fresh tasks, a frozen retrieval configuration and the full agent workflow. The saved run evidence contains per-task source IDs, rankings, metrics and hashes of the original result files, without prompts, conversation bodies or credentials. It supports auditing this report; it is not a complete one-command reproduction package. Version note: this article preserves the 5 November result set. Later product changes and different temporal-memory experiments belong in a separately labeled follow-up. Contact and project index: Anton Dziatkovskii, Palo Alto AI Research Lab, WhatsApp. Invented by Mycroft and Tony Dzi (Anton Dziatkovskii), Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Open-source AI tool you need to know 📌 ​Mem0: Universal memory layer for AI agents. Automatically extracts, updates, and persists user preferences across conversation sessions. ​mem0ai/mem0 ​Save this for your next agent build! 🔖 ​#OpenSource #GitHub #AI

This free GitHub repo gives AI a memory. It's called Mem0. It remembers the important stuff, like your name, what you like and what you're working on, so you stop explaining everything over and over. Get it free: mem0ai/mem0 t.co

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

This Free GitHub Repo Gives AI a Memory It's called Mem0. It saves the important stuff, like your name, what you like and what you're working on, so you stop explaining everything over and over again. Get it free here: mem0ai/mem0 Follow for more AI tips. #github #opensource #aimemory #aiapps #aitools #shorts [ar] هذا المستودع المجاني على GitHub يمنح الذكاء الاصطناعي ذاكرة يُسمى Mem0. يحفظ معلوماتك المهمة، مثل اسمك، وما تُفضّله، وما تعمل عليه، لتوفير عناء شرح كل شيء مرارًا وتكرارًا. حمّله مجانًا من هنا: mem0ai/mem0 تابعنا للمزيد من نصائح الذكاء الاصطناعي. #github #opensource #aimemory #aiapps #aitools #shorts [bn] এআই-কে স্মৃতিশক্তি দেয় এই ফ্রি গিটহাব রিপোজিটরি এর নাম Mem0। এটি আপনার নাম, আপনার পছন্দের বিষয় এবং আপনি কী নিয়ে কাজ করছেন, এই ধরনের গুরুত্বপূর্ণ তথ্য সংরক্ষণ করে রাখে, ফলে আপনাকে সবকিছু বারবার ব্যাখ্যা করতে হয় না। এটি এখানে বিনামূল্যে পান: mem0ai/mem0 আরও AI টিপসের জন্য ফলো করুন। #github #opensource #aimemory #aiapps #aitools #shorts [de-DE] Dieses kostenlose GitHub-Repo verleiht KI ein Gedächtnis Es heißt Mem0. Es speichert wichtige Informationen wie deinen Namen, deine Vorlieben und deine aktuellen Projekte, damit du nicht immer wieder alles erklären musst. Hier kostenlos herunterladen: mem0ai/mem0 Folge uns für weitere KI-Tipps. #github #opensource #aimemory #aiapps #aitools #shorts [es-US] Este repositorio gratuito de GitHub le da memoria a la IA. Se llama Mem0. Guarda la información importante, como tu nombre, tus gustos y en qué estás trabajando, para que no tengas que explicarlo todo una y otra vez. Descárgala gratis aquí: mem0ai/mem0 Síguenos para más consejos sobre IA. #github #opensource #aimemory #aiapps #aitools #shorts [fr-FR] Ce dépôt GitHub gratuit donne une mémoire à l'IA Ça s'appelle Mem0. Ça sauvegarde les informations importantes, comme votre nom, vos centres d'intérêt et vos projets en cours, pour que vous n'ayez plus à tout répéter. Téléchargez-le gratuitement ici : mem0ai/mem0 Suivez-nous pour plus d'astuces sur l'IA. #github #opensource #aimemory #aiapps #aitools #shorts [hi] यह फ्री GitHub रिपो AI को देती है याददाश्त इसे Mem0 कहते हैं। यह आपकी ज़रूरी जानकारी, जैसे आपका नाम, आपकी पसंद और आप जिस प्रोजेक्ट पर काम कर रहे हैं, सेव कर लेता है, ताकि आपको बार-बार सब कुछ समझाना न पड़े। इसे यहाँ से मुफ़्त में डाउनलोड करें: mem0ai/mem0 AI से जुड़े और टिप्स के लिए फ़ॉलो करें। #github #opensource #aimemory #aiapps #aitools #shorts [id] Repositori GitHub Gratis Ini Memberikan Memori pada AI Namanya Mem0. Aplikasi ini menyimpan informasi penting, seperti nama Anda, apa yang Anda sukai, dan apa yang sedang Anda kerjakan, sehingga Anda tidak perlu menjelaskan semuanya berulang kali. Dapatkan secara gratis di sini: mem0ai/mem0 Ikuti untuk tips AI lainnya. #github #opensource #aimemory #aiapps #aitools #shorts [it] Questo repository GitHub gratuito dà una memoria all'IA Si chiama Mem0. Salva le informazioni importanti, come il tuo nome, i tuoi interessi e i progetti a cui stai lavorando, così non dovrai più spiegare tutto ogni volta. Scaricalo gratuitamente qui: mem0ai/mem0 Seguici per altri consigli sull'IA. #github #opensource #aimemory #aiapps #aitools #shorts [iw] מאגר GitHub חינמי זה מעניק ל-AI זיכרון זה נקרא Mem0. זה שומר את הדברים החשובים, כמו השם שלך, מה אתה אוהב ועל מה אתה עובד, כך שאתה מפסיק להסביר הכל שוב ושוב. הורד את זה בחינם כאן: mem0ai/mem0 עקב לקבלת טיפים נוספים לבינה מלאכותית. #github #opensource #aimemory #aiapps #aitools #shorts [ja] AIに記憶を持たせる無料のGitHubリポジトリ Mem0というアプリです。名前、好きなもの、作業内容など、重要な情報を保存してくれるので、毎回同じことを説明する手間が省けます。 こちらから無料でダウンロードできます：mem0ai/mem0 AIに関するヒントをもっと知りたい方はフォローしてください。 #github #opensource #aimemory #aiapps #aitools #shorts [ko] AI에게 기억력을 선물하는 무료 깃허브 저장소 Mem0이라고 합니다. 이름, 좋아하는 것, 작업 중인 내용 등 중요한 정보를 저장해 주기 때문에 매번 똑같은 설명을 반복할 필요가 없습니다. 여기에서 무료로 다운로드하세요: mem0ai/mem0 더 많은 AI 팁을 보려면 팔로우하세요. #github #opensource #aimemory #aiapps #aitools #shorts [ml] AI-ക്ക് ഓർമ്മശക്തി നൽകുന്ന ഈ സൗജന്യ GitHub റിപ്പോositery ഇതിനെ Mem0 എന്ന് വിളിക്കുന്നു. നിങ്ങളുടെ പേര്, നിങ്ങൾ ഇഷ്ടപ്പെടുന്ന കാര്യങ്ങൾ, നിങ്ങൾ എന്താണ് ചെയ്യുന്നത് തുടങ്ങിയ പ്രധാനപ്പെട്ട കാര്യങ്ങൾ ഇത് സംരക്ഷിക്കുന്നു, അതിനാൽ എല്ലാം വീണ്ടും വീണ്ടും വിശദീകരിക്കുന്നത് നിർത്തുക. ഇവിടെ സൗജന്യമായി നേടൂ: mem0ai/mem0 കൂടുതൽ AI നുറുങ്ങുകൾക്കായി പിന്തുടരുക. #github #opensource #aimemory #aiapps #aitools #shorts [nl-NL] Deze gratis GitHub-repo geeft AI een geheugen Het heet Mem0. Het slaat belangrijke informatie op, zoals je naam, je voorkeuren en waar je mee bezig bent, zodat je niet steeds alles opnieuw hoeft uit te leggen. Download het hier gratis: mem0ai/mem0 Volg ons voor meer AI-tips. #github #opensource #aimemory #aiapps #aitools #shorts [pa] ਇਹ ਮੁਫ਼ਤ GitHub ਰੈਪੋ AI ਨੂੰ ਯਾਦਦਾਸ਼ਤ ਦਿੰਦੀ ਹੈ ਇਸਨੂੰ Mem0 ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਤੁਹਾਡਾ ਨਾਮ, ਤੁਹਾਨੂੰ ਕੀ ਪਸੰਦ ਹੈ ਅਤੇ ਤੁਸੀਂ ਕਿਸ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਇਸ ਲਈ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਵਾਰ-ਵਾਰ ਸਮਝਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਇਸਨੂੰ ਇੱਥੇ ਮੁਫ਼ਤ ਪ੍ਰਾਪਤ ਕਰੋ: mem0ai/mem0 ਹੋਰ AI ਸੁਝਾਵਾਂ ਲਈ ਫਾਲੋ ਕਰੋ। #github #opensource #aimemory #aiapps #aitools #shorts [pl] To darmowe repozytorium z GitHub daje AI pamięć Nazywa się Mem0. Zapisuje ważne informacje, takie jak Twoje imię, to, co lubisz i nad czym pracujesz, dzięki czemu nie musisz już ciągle wszystkiego tłumaczyć. Pobierz za darmo tutaj: mem0ai/mem0 Obserwuj, aby uzyskać więcej wskazówek dotyczących sztucznej inteligencji. #github #opensource #aimemory #aiapps #aitools #shorts [pt-BR] Este repositório gratuito do GitHub dá memória à IA Chama-se Mem0. Ele salva informações importantes, como seu nome, seus gostos e no que você está trabalhando, para que você não precise explicar tudo repetidamente. Baixe gratuitamente aqui: mem0ai/mem0 Siga para mais dicas de IA. #github #opensource #aimemory #aiapps #aitools #shorts [ru] Этот бесплатный репозиторий на GitHub дает ИИ память Это называется Mem0. Он сохраняет важную информацию, например, ваше имя, ваши интересы и то, над чем вы работаете, чтобы вам не приходилось объяснять всё снова и снова. Скачать бесплатно можно здесь: mem0ai/mem0 Подписывайтесь, чтобы получать больше советов по ИИ. #github #opensource #aimemory #aiapps #aitools #shorts [ta] இந்த இலவச GitHub ரெப்போ செயற்கை நுண்ணறிவுக்கு நினைவாற்றலை வழங்குகிறது. இதன் பெயர் மெம்0 (Mem0). இது உங்கள் பெயர், உங்களுக்குப் பிடித்தவை மற்றும் நீங்கள் என்ன செய்து கொண்டிருக்கிறீர்கள் போன்ற முக்கியமான தகவல்களைச் சேமித்து வைக்கும். இதனால், நீங்கள் எல்லாவற்றையும் மீண்டும் மீண்டும் விளக்க வேண்டிய அவசியம் இருக்காது. இங்கே இலவசமாகப் பெறுங்கள்: mem0ai/mem0 மேலும் AI குறிப்புகளுக்குப் பின்தொடரவும். #github #opensource #aimemory #aiapps #aitools #shorts [te] ఈ ఉచిత GitHub రిపో AIకి జ్ఞాపకశక్తిని ఇస్తుంది దీనిని Mem0 అని పిలుస్తారు. ఇది మీ పేరు, మీకు ఇష్టమైనవి మరియు మీరు దేనిపై పని చేస్తున్నారో వంటి ముఖ్యమైన విషయాలను భద్రపరుస్తుంది, తద్వారా మీరు ప్రతి విషయాన్ని పదే పదే వివరించాల్సిన అవసరం ఉండదు. ఇక్కడ ఉచితంగా పొందండి: mem0ai/mem0 మరిన్ని AI చిట్కాల కోసం అనుసరించండి. #github #opensource #aimemory #aiapps #aitools #shorts [uk] Цей безкоштовний репозиторій на GitHub дає штучному інтелекту пам'ять Він називається Mem0. Він зберігає важливі речі, такі як ваше ім'я, що вам подобається та над чим ви працюєте, щоб вам не довелося постійно все пояснювати. Завантажте його безкоштовно тут: mem0ai/mem0 Підпишіться, щоб отримати більше порад щодо ШІ. #github #opensource #aimemory #aiapps #aitools #shorts

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