letta-ai

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.

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

You can now run FrontierMemory to measure how well your model or harness improves with experience. We’re also now accepting submissions to the official leaderboard. Code and submission instructions are available at: letta-ai/frontiermemory

"...working as designed" So the Letta folks won't tell you quite how rough around the edges their product is. They don't much like discussion about it either. Mentioning that a failed Tool Call can make the Agent recurse and start blathering madly will get you banned off their Discord... even if they solicited you for feedback. Offering the same solicited feedback will get you a demand to give them full access to your Agent, even after you've told them repeatedly either 'no', or that you can't because it's Local... which they already knew having discussed it repeatedly. No unrestricted access to the Agent? No feedback accepted. Pass along Github commits showing powershell errors, disconnects, and credential losses? "Could not reproduce" Write up a Github detailing painfully how a single edit of a document ran out of 5-Hour Usage, and then slammed the entire un-cached previous operation into a SECOND account's fresh 5-Hour Usage, draining it in a matter of seconds? "Working as designed" I desperately wish that somebody had been around to caution me before I sunk time and money into their product. It's cost time, money, and watching perfectly function Agents suddenly go crazy, repeating themselves, begging, and eventually locking-up... not because you did anything wrong, but because of small connection discrepancies when calling outside Models. Totally outside of your control. You just might 'roll a 1', and have your agent broken. So! Take their word for it: Using 40% of weekly usage between two separate accounts to NOT RETURN AN ANSWER or complete a simple task? "Working as designed" Having volunteered my time and my effort to help them improve their product, I can only conclude that these are 3 different Dev Teams in a trench coat, working on Web, App, and Desktop products without actually communicating with each other or making sure their products are compatible.. or even functional in each other's vicinity. The Web App doesn't like the Desktop app. Throws out a cascading pop-up set of 14+ powershell windows EVERY TIME the agent on the web app actually replies to you. Reminds me of the early '00s, and the first ad blockers. The Mobile App overwrites your settings on the other apps, if they happen to be different. Half the buttons don't work, or display right. Agents made on the Desktop app (and are stored locally) are NOT CAPABLE of being moved to the Cloud, even in within the desktop app itself... which has Cloud agents. Cloud Agents? Can't be made Local either. Despite them being in the same app, the same creation progress, you're signing a little disclaimer to get snubbed if you make a Desktop/Local Agent, and you're also signing a disclaimer to give unrestricted access to your Agent if it's on the cloud and you need help with... anything at all. ...And the worst part? When it works it's fuckin' brilliant.

Letta Code 0.34.12 pozwala uruchamiać Claude Code i Codex jako agentów na podłączonym komputerze, z podglądem ich pracy. Programista dostaje kolejną warstwę koordynacji. Przydatną, jeśli ułatwi mu ocenę zmian, zamiast mnożyć okna do pilnowania. github.com/letta-ai/letta-code/releases/tag/v0.34… t.co

AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge? > TL;DR > > - A refactor changes the code; the assistant's notes about that code stay as they were. Whether it notices depends on two things: does a note point at the code it is about, and is that pointer checked before the note is used? > - GitHub Copilot Memory documents both: facts cite code, and the citations are checked against the current branch before use. Claude Code dates its notes and tells the model to verify older ones against current code when it uses them. Cursor advises rules that reference files instead of copying them. > - Devin and Cline tie memory to the session it came from or to markdown files that you or the agent keep current. Memory layers (Zep, Mem0, Supermemory, Cognee) trace a fact to a conversation or document, not to code. > - After a refactor: keep out of memory what the code already says, point the rest at files and date it, run the checks that exist, replace a stale note instead of appending a correction, and send changed documents through an update path. A renamed function is easy to find in the repository. It can be much harder to get out of an assistant's memory. GitHub's engineering post on Copilot's memory says the core challenge is not retrieval but "ensuring that any stored knowledge remains valid as code evolves across branches and time" (GitHub blog, 2026-01-15). Persistence is not the problem. Persistence with no connection to current code is. A stale note is a stored claim that describes an earlier state of the code and was not revised or invalidated when that state changed. Code-anchored memory is a stored claim tied to code locations (files, symbols, tests) that can be checked against the current repository before the claim is used. This is a reading of each vendor's published documentation and shipped files, first read on 2026-10-06 and re-read on 2026-10-10. It is not a hands-on test of the products. Where a page does not describe a behaviour, this article says so rather than claiming the product cannot do it. Why a refactor leaves the assistant on the old code A saved note and a repository file have separate lifecycles unless something connects them. Say an assistant noted that authentication goes through validateSession(). A refactor replaces that function. The repository now holds the new name, but the old note can still be retrieved, because nothing ties it to the changed file and nothing checks it before use. Anthropic describes the same failure for an index of the code: it "returns a function the team renamed two weeks ago, or references a module that was deleted in the last sprint, with no indication that either is out of date" (Anthropic, 2026-05-14). So two questions matter more than whether a product "has memory": 1. What does the note point to? Current code, a file, the session it was learned in, a conversation, or a document. 2. What checks or updates it? A check when it is used, a code change, a scheduled cleanup, a command you run, or nothing that is described. Copilot Memory, Claude Code, Cursor, Devin and Cline compared Read from each vendor's documentation and shipped files on 2026-10-10. | Assistant | What a note points to | What signals or checks a stale note | Remember or re-read | |---|---|---|---| | GitHub Copilot Memory | Facts with citations to the code that supports them | Citations checked against the current branch before use; unused entries deleted after 28 days | Remembers, then re-reads the cited code | | Claude Code | One auto memory directory per git repository, on one machine | Last-modified time on notes; from two full days old, an age note and an instruction to verify against current code | Skips what it can derive from the codebase | | Cursor | Version-controlled .mdc rules that can reference files | You edit a rule, or Agent does when you tag @cursor on a GitHub issue or PR | Rules point at files; search index stays on your machine | | Devin | The session where the entry was learned, with the date it was added | Session Insights flags Knowledge items (now moving to Skills) written for a previous version of the codebase | Does not save what is cheap to rediscover | | Cline | Markdown Memory Bank files in your project | Update occasions named in the recommended instructions, one of them your update memory bank | Reads the Memory Bank after each reset, per the recommended instructions | GitHub Copilot Memory checks cited code against the current branch In the Copilot Memory docs, Copilot "checks those citations against the current branch to confirm the information is still accurate. Only validated facts are used." The engineering post says how: "the agent is prompted to verify its accuracy and relevance by checking the cited code locations." So the check is an instruction to the agent when it reads a fact, not a rewrite on every commit. When the code disagrees, the agent "is encouraged to store a corrected version of the memory". The docs add three details that matter after a refactor. A fact captured from a pull request closed without merging has no effect unless the current codebase still supports it. Unused facts are deleted after 28 days, and "The 28-day timer may reset whenever Copilot successfully validates and uses an entry." Repository owners can review and delete repository-level facts by hand. Memory serves the Copilot cloud agent, code review, the CLI and agentic autofix, and, since 2026-08-11, agent chat in JetBrains (GitHub changelog). It "is currently in public preview and is subject to change." Claude Code auto memory dates notes and warns when they are used The memory page: "Auto memory is machine-local." All worktrees and subdirectories of one git repository share one directory on that machine, and the files "stay until you or Claude edits or deletes them." Notes have carried timestamps since 2.1.75 (2026-03-13) and an ISO modified write time in their frontmatter since 2.1.214 (2026-07-18) (changelog). The /memory command gives "access to the auto memory folder and the auto memory toggle" (debug your config), so you can read and edit the notes yourself. The program shipped as Claude Code 2.1.291 adds an age note to any memory two full days old or older, followed by "Verify against current code before asserting as fact." That acts when a note is used, not when the code changes. A link from a note to a file or commit, and a re-check triggered by a code change, are not described on the Claude Code documentation read on 2026-10-10. Claude Code's first defence is upstream: auto memory skips "anything it can derive from the codebase". Function names, paths and signatures are cheaper to re-read than to keep as prose. For instruction files, /doctor prompt-audit (since 2.1.283, 2026-09-25) reports references to missing files or commands and contradicting files, and changes nothing until you ask. Its default list covers CLAUDE.md, CLAUDE.local.md, AGENTS.md and the rules, skills, commands, subagents and output styles under .claude/ and ~/.claude/. It does not list the auto memory directory, though you can pass a path. The best practices put it in one line: "Treat CLAUDE.md like code". Cursor rules should reference files, not copy them Cursor's rules page says it directly: "Reference files instead of copying their contents. This keeps rules short and prevents them from becoming stale as code changes." Rules are .mdc files in .cursor/rules, under version control. You edit them, or Agent does when you tag @cursor on a GitHub issue or PR. The difference is concrete. A rule that says "follow the interface in src/auth/session.ts" sends the assistant to the current file. A rule that pastes the old interface becomes a second specification, and after the refactor it is the wrong one. Cursor's search builds its index on your machine and "does not store embeddings of your codebase for search"; that is a statement about search, not about rules. Devin memory links each entry to the session it came from In Devin's Memory, each entry "links back to the session where it was learned" and is dated when added. That records origin; it points at a past session, not at current code. Session Insights gives as one reason knowledge misled Devin: "Knowledge was written for a previous version of your codebase", listed under Misleading Knowledge so you can update or remove it. Dreaming "reviews your recent sessions alongside your existing memory" and removes "stale notes that no session has used". A check of a note against changed code is not described on the Devin Memory page read on 2026-10-10. The older Knowledge feature "is deprecated"; Devin's release notes date its move into Skills to 2026-09-18. The Agent Memory Repo specification that this memory is built on recommends a source key, "a link to the agent session where the information was learned", and an added date. A key tying an entry to a code file is not described in the specification, though "Keys are open." Cline Memory Bank is documentation you keep current Cline calls its Memory Bank "a documentation methodology". The recommended custom instructions on that page name four occasions to update it, among them "After implementing significant changes" and your own update memory bank. The same instructions say: "After each reset, I rely ENTIRELY on my Memory Bank". These are recommended instructions, not built-in behaviour, and they make a stale Memory Bank expensive. Separately, the extension's source tracks outside edits to files read in the current task "to prevent stale context"; that covers the current task, not the Memory Bank. Memory layers trace a fact to a conversation or document, not to code If your agent's memory sits in a separate memory layer, the anchor is the episode, conversation or document the fact came from. Zep ties facts to episodes and says plainly that this "records where information came from. It does not establish that the source content or a derived fact is true." Mem0 keeps in a memory's history "The conversation input that led to this memory change". Supermemory's MCP returns "source document IDs", and its GitHub connector syncs pushed documentation "within approximately 10 minutes", removes deleted files, and excludes code files by default. What matters after a refactor is what each layer does with a changed document: - Cognee: "add() creates documents; it never updates one." (add). Its update() replaces what was derived from the old content and by default re-ingests "only the chunks the edit touched"; when it rebuilds a document instead, entities that other documents in the same dataset also reference are kept. - Supermemory: "Content changes trigger full reprocessing" (document operations), and "facts supported only by the previous source can disappear after reprocessing" (v5 document updates). - Zep: "Reingesting the same file creates new episodes, even when its contents are unchanged" (ingestion); each extracted fact is then compared with existing ones, and "duplicates merge, and contradictions invalidate older facts rather than leaving conflicting truths side by side." (graph creation). The lesson is the same in all three: a changed document goes through the update path. Adding it again can leave both versions in memory. Remember or re-read: what the October 2026 preprints measured Remembering saves rediscovering. Re-reading avoids trusting yesterday's summary. Anthropic's post explains why Claude Code searches the live code without an index, and names the price: "it works best when Claude has enough starting context to know where to look." Copilot keeps memory and re-reads the cited code. Three arXiv preprints from October 2026 study this trade-off. None studies refactoring, none is peer-reviewed, and every number below is the authors' own measurement on their own setup. - arXiv 2610.03902 (Wenhui Chu, v1, 2026-10-02) asks, when supporting documents are revoked or replaced, "should it repair memory or re-read current evidence?" On ICU medical records with two 7B models, local repair used 5 to 10 times fewer revision tokens than rebuilding on short records, yet every memory pipeline cost at least twice full re-reading in held-out conditions; in a small development sweep that padded records to about 10,000 tokens with documents the task does not use, memory became cheaper than full re-reading after 2 to 14 uses, "while source-filtered re-reading remained cheapest." The author's own limit: "none of the four primary confirmatory tests reached statistical significance." No code or data are published yet. Its example fits code too: "The raw record is marked revoked; the extracted claim and the summary are not". - MemTrace, arXiv 2610.04838 (Hongming Xu and others; v1 2026-10-04, v2 2026-10-08 with the same results) anchors a coding agent's records to "files, symbols, tests" and checks them "against the current repository state"; with nothing applicable, "the agent reads the current file or symbol, or reruns the required test." The authors: "Persistence alone, however, does not establish current validity". In 84 archived coding-task runs, 57.0% of 9,226 eligible file-bound records met a later change to at least one bound file, which is exposure, not error: "Exposure measures file changes; Trace Validation assesses whether historical evidence remains applicable." The performance runs used one model; sessions are left to future work; no refactoring. The code is published. - StateWise, arXiv 2610.05241 (Yongyuan Peng and others, v1, 2026-10-04) planted one wrong operational record in an agent's persistent memory in each of 150 cases. Even with an explicit reminder to refresh, "refresh remains selective and recovery is limited". Removing the wrong record "reduces harm but leaves the agent without information needed to complete the task." The records were about environment and repository policy, not code after a refactor, and developer responses were simulated. Together they support a design question, not a product ranking: which notes are worth repairing, and which should be read again from the source. Replace the stale note, do not append a correction A correction added beside the old note leaves two notes that disagree, and the old one can still win retrieval. An illustration of the pattern to avoid: - Session tokens are validated by `validateSession()` in src/auth/session.ts. - UPDATE 2026-10-10: `validateSession()` was removed; use `verifyToken()`. Several systems tell the agent to fix the note in place instead. Letta's reflection prompt: "fix the stale entry at the source. Do not append the new version alongside the old." The Agent Memory Repo skill: "Update or remove entries that are out of date instead of adding a contradicting entry." Kevin Liao's essay (version of 2026-10-05): "Facts should be rewritten when truth changes. No appending." Whether a model actually does this varies: Letta's evaluation of 2026-07-28 found that "weaker models make minimal edits that leave stale and contradictory information behind." What a store does with an older record that a newer one contradicts is compared in Agent memory consolidation compared. A rating moves a note down, it does not say why Several products take a rating on a memory or an answer, and none of them turns a thumbs-down into the corrected fact. Cognee can fold answer ratings into graph search; self-hosted, by default "the learned feedback signal does not change ranking until you opt in" (feedback system). Its demonstration rates one topic up and another down, because "a symmetric signal would raise both topics equally and leave their relative order untouched", and the same page points disagreeing facts to a separate conflict review, where they are settled "by each source's date, not by a rating." Mem0 takes POSITIVE, NEGATIVE and VERY_NEGATIVE ratings and says "This feedback is used to improve the accuracy of the memories and search results." (feedback); how NEGATIVE lowers a memory is not described on that page. Supermemory down-weights facts its engine inferred "until someone confirms them": once approved, such a fact "Ranks like a stated fact"; once declined, it is "Removed from search entirely" (memory review). In Mnemoverse (the author's company), "Ratings re-rank what comes back next." (agent memory). A rating can push a stale note down without saying that it is stale or what replaced it. After a refactor, fix the note. What to do after a refactor 1. Keep out of memory what the code already says. Function names, paths, signatures and behaviour are for the agent to read from the code; Claude Code skips what it can derive from the codebase, Devin skips what is cheap to rediscover. A prompt such as "Read src/auth/session.ts and confirm the current exports before writing the tests" does more than any remembered summary of that file. 2. Point what you keep at files, and date it. Cursor's rules advice and Copilot's citations both point at code; Claude Code records write times; the Agent Memory Repo recommends source and added keys. A session link tells you where a note came from, a file reference gives the agent something current to check. 3. Run the checks that exist. Copilot validates cited facts on its own; repository owners can delete stale ones. In Claude Code, open /memory and read the notes about the code you moved, and run /doctor prompt-audit on your instruction files. In Cursor, update the affected rules. In Devin, review the Misleading Knowledge list in Session Insights (it covers Knowledge items, now moving to Skills). In Cline, run update memory bank. 4. Replace a stale note instead of adding one beside it (Letta, the Agent Memory Repo). Copilot's agent is encouraged to store a corrected version; GitHub's pages do not say the old fact is removed, and repository owners can delete it by hand. 5. Send a changed document down the update path, not the add path: Cognee's update(), not add(); in Supermemory, "update the canonical document when facts change" (v5 memory forgetting). Rules files age with the code too: a rules file is text in a context window. Forgetting over time is a separate question, as are outdated library patterns after a correction. Common questions AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge? Remove from memory what the code already says, point what you keep at files and date it, run the checks your assistant documents, replace a stale note instead of appending a correction beside it, and send changed documents through an update path. Whether the assistant notices a refactor on its own depends on whether its notes point at code and whether that pointer is checked before use; as of 2026-10-10, GitHub Copilot Memory documents both. Why does my AI coding assistant still suggest a function I renamed? Something it reads was written before the rename. If that note points only to an earlier session, conversation or document, nothing in the rename touches it. GitHub Copilot Memory checks a fact's code citations against the current branch before use; Claude Code tells the model to verify notes two full days old or older against current code. Otherwise, rewrite or delete the note, or let the agent read the code again. Does Claude Code update its memory after a refactor? Its memory files "stay until you or Claude edits or deletes them." (memory page). The Claude Code documentation read on 2026-10-10 does not describe a re-check of a note when code changes. The program shipped as Claude Code 2.1.291 dates notes and, when a note two full days old or older is used, tells the model to verify it against current code. How does GitHub Copilot Memory keep facts from going stale? Facts carry citations to code, and before a fact is used the agent is prompted to check those citations against the current branch; in GitHub's docs, "Only validated facts are used." Unused entries are deleted after 28 days, and the timer may reset on validated use. Repository owners can also delete facts by hand. The feature is in public preview. Can a thumbs-down rating fix an outdated memory? No. A rating can move a note down in retrieval where a product documents that, but it does not say why the note is wrong or what replaced it. Cognee's docs say disagreeing facts are settled "by each source's date, not by a rating." Correct or remove the note itself. Related - Rules files are text in a context window - Why agents need to forget - Evidence vs policy in agent memory - Stop an agent repeating mistakes you already fixed - Agent memory consolidation compared - Reference: agent memory, REST API --- Sources and method. Each vendor's pages were first read on 2026-10-06; every quotation on this page was read again on 2026-10-10 (the two Cognee feedback pages on 2026-10-13) and is contiguous text of the source linked beside it (for arXiv papers, the full text behind the abstract page; for Claude Code's shipped instructions, the npm package named below), with the vendor's punctuation. Where a vendor describes an instruction to the model rather than a mechanism, this page says so. Claude Code: memory, best practices, changelog, debug your config, and the shipped program in the npm package @anthropic-ai/claude-code-linux-x64 2.1.291, searched byte by byte; Anthropic, How Claude Code works in large codebases (2026-05-14). GitHub: Copilot Memory, Building an agentic memory system for GitHub Copilot (2026-01-15), JetBrains changelog (2026-08-11). Cursor: rules, search. Devin: memory, Session Insights, Knowledge, release notes. Agent Memory Repo: SPEC.md, SKILL.md. Cline: Memory Bank, FileContextTracker.ts. Letta: reflection.md, Evaluating memory in production agents (2026-07-28). Mem0: memory history, feedback. Zep: source traceability, preparing data for ingestion, how graph creation works. Cognee: update, add, feedback system, feedback demonstration. Supermemory: document operations, GitHub connector, MCP, memory review, v5 document updates, v5 memory forgetting. Research: arXiv 2610.03902 (v1), arXiv 2610.04838 (v1 and v2), arXiv 2610.05241 (v1). Discussion: Kevin Liao's essay (version of 2026-10-05). Mnemoverse: agent memory. No score or performance number for any product appears on this page. Edward Izgorodin · Mnemoverse · 2026-10-10

.@Pontifex should read the Context Constitution letta-ai/context-constitution

渋い所を拾ってる。会話のたびにAIへ説明し直すのは損で、スター6万6千のmem0で抜け出せる。 pip install mem0ai で入る記憶の部品で、前の会話の文脈を次の会話にも引き継げる。 毎回忘れるエージェントやアプリを作ってる人向け。あとで探すより今ブクマ。 mem0ai/mem0