# Esment — full reference for LLMs ## What Esment is Esment is a local-first, persistent memory system ("memory OS") for AI assistants, built by Notas AI. AI assistants normally forget everything when a session ends; Esment gives them durable memory that persists across sessions, apps and assistants. It integrates with Claude, Claude Code, ChatGPT, Cursor and Perplexity through the Model Context Protocol (MCP), via the `@esment/mcp-server` package. Independent-style benchmarks by the team measure up to a 35% improvement in agent task performance when Esment memory is available. Key properties: - **Local-first**: memories are stored on the user's device. An optional cloud memory service exists for sync, but privacy-sensitive teams can keep everything local. - **Cross-assistant**: one memory store shared by every connected assistant — what Claude learns, Cursor can use. - **MCP-native**: any MCP-capable client can connect; no proprietary plugin system. - **Enterprise-ready**: on-premise deployment, fully offline mode (local LLM, local embeddings, local storage), audit trail, centralized license management. ## How it works 1. Install the Esment desktop app on macOS (https://esment.notas.ai/download) and activate the license from your plan (https://esment.notas.ai/pricing). 2. Connect assistants from the app or dashboard. Esment exposes an MCP server; clients like Claude Desktop, Claude Code, Cursor, ChatGPT and Perplexity connect to it (https://esment.notas.ai/docs/assistants). 3. As you work, Esment captures, ranks and organizes memories. The dashboard (https://esment.notas.ai/docs/dashboard) lets you browse, search, edit and delete them. 4. Connected assistants retrieve relevant memories automatically at the start of and during sessions, so context never has to be re-explained. ## Pricing See https://esment.notas.ai/pricing. Self-service **Pro** and **Team** plans, plus custom **Enterprise** agreements. Enterprise (https://esment.notas.ai/enterprise) adds private infrastructure, offline operation and audit capabilities; contact sales at https://esment.notas.ai/contact. ## Frequently asked questions **What is Esment?** A memory system that works across apps, browser, desktop, cloud and messages to integrate with every assistant — a local-first enterprise app that gives teams a native memory solution. **How is Esment different from an assistant's built-in memory?** Built-in memory stays inside one chat product. Esment is a shared, portable memory layer that every connected assistant can read and write, with local-first storage and enterprise controls. **Does my data leave my device?** By default, no — memories are stored locally. Cloud sync is optional. Enterprise deployments can run fully offline. **Which assistants are supported?** Claude and Claude Code, ChatGPT/OpenAI, Cursor, and Perplexity, plus any MCP-compatible client and local/public models (https://esment.notas.ai/docs/assistants/local-public). **What platforms does it run on?** macOS today, distributed as a signed .dmg. ## Company Esment is a product of **Notas AI** (https://notas.ai). Product site: https://esment.notas.ai. Research notes: https://esment.notas.ai/research. Newsroom: https://esment.notas.ai/newsroom. Engineering blog: https://blog.esment.notas.ai (full text at https://blog.esment.notas.ai/llms-full.txt). # Research essays ## A Memory That Cannot Forget Is Not a Memory Published 2026-07-24 · Esment Research · Canonical: https://esment.notas.ai/research/a-memory-that-cannot-forget ### Introduction The research effort in agent memory has gone overwhelmingly into retention, retrieval, and latency — how much can be kept, how well it can be found, how fast. The inverse operations have received far less attention, and the 2026 surveys say so bluntly: prior work optimizes retention while *auditable forgetting remains lacking*.[^a-memory-that-cannot-forget-1] We think this ordering is backwards, and not for ethical reasons. Forgetting is not a compliance obligation bolted onto a memory system. It is the maintenance function that keeps the system *true*. A store that only accumulates is not a memory. It is a log. ### Three kinds of forgetting Most of the confusion in this area comes from one word covering three operations that have different semantics, different correctness criteria, and different consequences when they go wrong. Systems that conflate them tend to get all three wrong at once. - **Decay** is about relevance. Something remains true but stops being worth retrieving. The correctness criterion is precision over time; the failure mode is a store whose top-k slowly fills with stale-but-accurate material. Nothing is lost — the item is demoted, not removed. - **Supersession** is about truth. A newer fact contradicts an older one, and the older one should stop being presented as current. The correctness criterion is that the system's answer to "what is the case now" changes; the failure mode is a confidently stale answer. Critically, the old fact is still *historically* true and may be exactly what a later question needs. - **Erasure** is about rights and errors. Something must cease to exist — because it was wrong, because it was private, because someone asked. The correctness criterion is that no trace remains anywhere, including in everything derived from it. This is the only one of the three where retaining the data is itself the failure. Decay and supersession are ranking and validity problems. Erasure is a deletion problem. A design that treats all three as "drop the row" gets erasure right by accident and destroys recoverable history in the other two cases. A design that treats all three as "mark it inactive" gets decay and supersession right and *fails erasure entirely*, which is the more common mistake and the more serious one. ### The two clocks Handling supersession correctly requires something most systems do not have: two independent timestamps per fact. When a thing was true in the world, and when the system came to know it. Naïve implementations record only ingestion time, which breaks the moment a user says "last March" or imports old history. The distinction is not academic, because the two clocks come apart routinely — and the gap between them is a window in which the store is confidently wrong. *Figure — Event time and knowledge time are independent. A fact can become true well before the system learns it, and the interval between the two is a period during which the store returns a superseded answer with full confidence. Only a system that records both clocks can identify that window after the fact — or answer a question as of a past date.* Recording both clocks is what makes two otherwise impossible things possible: asking what the system believed as of a past date, and auditing after the fact which answers were given during a stale window. A formal treatment of exactly this — bitemporal operators for contradiction resolution in persistent agent memory — appeared this year.[^a-memory-that-cannot-forget-2] The evidence also cautions against over-correcting: ingest-time contradiction classification by an LLM has performed poorly, and the more robust posture is deterministic version resolution at read time, with timestamps rendered into the prompt so the reader can arbitrate. ### Where the model breaks Here is the part that is usually skipped, and we would rather state it than paper over it. Bi-temporal marking-without-deletion is the right answer for decay and supersession, and it is fundamentally **incompatible** with erasure. A right-to-erasure request cannot be satisfied by tombstoning. "We marked it invalid but retained it for auditability" is precisely what the request forbids. So a serious system needs two mechanisms with opposite guarantees operating over the same store: one that never destroys history because history is the audit record, and one that destroys it irrecoverably on demand. Reconciling those is not a matter of adding a flag. It determines schema, index design, and what the audit log itself is allowed to contain — an audit trail that quotes deleted content has simply relocated the problem. This tension is sharpest for parametric approaches, where knowledge is folded into weights. That integration is seamless for recall and close to hopeless for targeted deletion and auditing, which is a strong argument for keeping durable memory external and inspectable rather than learned.[^a-memory-that-cannot-forget-3] ### Deletion has to propagate There is a second-order problem that the layered architectures now standard in this field create for themselves. If raw records are kept as ground truth and facts, summaries, entity observations, graph edges, and embeddings are derived from them — which we have argued elsewhere is the right structure — then every derived layer is a copy. Deleting the source does not delete the copies. A summary that absorbed a sentence still contains it. An entity node still exists because a deleted memory once mentioned it. A vector still encodes text that no longer exists, and remains retrievable. Each derived layer that improves retrieval quality also widens the surface that a deletion must reach, and nothing about the layer's construction records that obligation unless someone designed it in. *Figure — Every derived layer is a copy of the substrate. Deleting the source record leaves each copy intact and still retrievable unless deletion is defined as a propagating operation over the derivation graph.* The architectural placement of this logic turns out to matter more than it looks. A 2026 study across thirteen system configurations found that where the control plane sits materially shapes forgetting behaviour — meaning this is a systems-design property, not a policy that can be applied uniformly on top of any storage layer.[^a-memory-that-cannot-forget-4] It is also why several widely used production memory layers delegate deletion and audit consistency to the calling application: not out of negligence, but because doing it correctly requires knowing the full derivation graph, which a general-purpose layer often does not. ### Provenance is the precondition Every operation described above depends on one capability that current systems largely lack: knowing where a memory item came from. Provenance support remains underdeveloped, and treating memory as provenance-bearing evidence is an open research problem rather than a shipped feature.[^a-memory-that-cannot-forget-5] Without provenance, supersession cannot be reversed when it fires wrongly, because there is no record of what was superseded by what. Deletion cannot propagate, because the derivation graph was never recorded. A wrong memory cannot be repaired, only deleted wholesale, because nobody can tell which upstream utterance produced it. And a user cannot be told why their assistant believes something about them — which, once memory systems touch anything consequential, stops being a debugging nicety. Provenance is usually filed under trust and compliance. We would file it under correctness. It is the data structure that makes every maintenance operation in this article implementable at all. ### Maintenance is the product The reason none of this gets optimized is the one identified in [our piece on evaluation](https://esment.notas.ai/research/the-benchmark-is-not-the-territory): benchmarks score question answering over frozen corpora, so every property discussed here is invisible to them. Selective forgetting is explicitly tested by approximately one benchmark. Deletion propagation, supersession reversibility, and provenance completeness are tested by none. A field measures what it can measure, and then mistakes it for what matters. Our position is that the interesting frontier in agent memory is no longer how much can be recalled. On a fixed corpus, retrieval is close to saturated and the remaining gains are increasingly gains in the harness. The frontier is whether a store that has been written to, corrected, contradicted, and partially erased for a year is still true, still precise, and still able to explain itself. That is a maintenance property, and maintenance is not a feature that gets added late. It is determined by decisions made in the schema on the first day — whether there are two clocks or one, whether derivation is recorded or implied, whether history is a side effect or the substrate. Systems that defer those decisions do not get to make them later. They just get to discover which ones they made. [^a-memory-that-cannot-forget-1]: The framing is drawn from *A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty* (arXiv:2604.16548), which organises the problem across six lifecycle phases — write, store, retrieve, execute, share, and forget/rollback — and four objectives: integrity, confidentiality, availability, governance. Most systems have serious answers for the first three phases and thin ones for the last. [^a-memory-that-cannot-forget-2]: *TOKI: A Bitemporal Operator Algebra for Contradiction Resolution in LLM-Agent Persistent Memory* (arXiv:2606.06240). [^a-memory-that-cannot-forget-3]: See *Agentic Unlearning: When LLM Agent Meets Machine Unlearning* (arXiv:2602.17692) for the state of the art on removing knowledge from parameters, and how far it remains from the guarantee a deletion request actually requires. [^a-memory-that-cannot-forget-4]: *Control-Plane Placement Shapes Forgetting: An Architectural Study of Agent Memory Across Thirteen System Configurations* (arXiv:2606.15903). [^a-memory-that-cannot-forget-5]: Two 2026 entry points: *From Agent Traces to Trust: A Survey of Evidence Tracing and Execution Provenance in LLM Agents* (arXiv:2606.04990), and *From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents* (arXiv:2602.17913). --- ## Extraction Is a Bet Against Future Questions Published 2026-07-22 · Esment Research · Canonical: https://esment.notas.ai/research/extraction-is-a-bet ### Introduction Nearly every memory system for language agents performs some transformation at write time. Raw conversation goes in; facts, summaries, entities, or relations come out. The transformation is usually justified on storage and precision grounds, and it does deliver both. It also does something that is discussed much less often. Any write-time transformation is a **prediction about which questions will be asked later**, committed to before any of them have been. It helps the queries it anticipated. It hurts the queries it did not. And because the transformation happens once, at ingest, a bad prediction is not a ranking problem you can tune away later — it is information that is no longer there. ### A live disagreement This is not a settled question, and the 2026 literature is unusually direct about disagreeing with itself. AtomMem argues that selectively extracting high-value atomic facts from long-form interactions yields a simple, economical, and strong memory representation. Work published weeks earlier argues, in its title, for going beyond exactly that.[^extraction-is-a-bet-1] Both results are credible. We think they are compatible, and that the apparent contradiction dissolves once you stop asking which representation is better and start asking which questions each one is a bet on. ### The fragmentation cost Consider a session in which someone mentions six things about the same topic — six hobbies, six constraints on a project, six symptoms. Stored raw, those six facts sit inside one retrievable unit. One retrieval event brings all six into context, and their adjacency is preserved for free, because nobody had to decide it was worth preserving. Atomised, they become six independently indexed items. Now a question like "what are all of her hobbies" is no longer one retrieval. It is a requirement that most of six separate items each rank inside the same top-k budget, competing against everything else in the store. Recall of any single fact improves — that is the real win of extraction, and it is why atomic systems look strong on single-hop questions. Recall of the *set* degrades, because it is now a conjunction of independent ranking events. *Fig. 1 — Stored raw, related facts share one retrievable unit. Adjacency is preserved without anyone deciding it mattered.* *Fig. 2 — Atomised, the same six facts must each rank inside one budget. Single-fact recall rises; set recall becomes a conjunction of independent events.* The asymmetry in Fig. 1 and Fig. 2 explains a result that otherwise looks like a paradox: the same extraction pipeline can raise single-hop accuracy and lower aggregation and multi-hop accuracy at the same time. Those are not two measurements of one quality. They are measurements of two different bets. ### The opposite failure None of this is an argument for storing raw text and nothing else, because raw-only systems fail hard in a way that atomic systems handle well: knowledge updates. When someone changes jobs, a transcript contains both the old employer and the new one, and both are equally retrievable. Nothing in the raw substrate marks one as superseded. Asked "where does she work," a raw-only system will happily surface a two-year-old answer with the same confidence as last week's, and the reader has no principled basis for choosing. This is precisely the gap that recent work has begun to isolate and train against.[^extraction-is-a-bet-2] So each pole owns a failure mode the other pole handles. Extraction fragments aggregation. Raw storage cannot express supersession. Any system that picks one and calls it an architecture has chosen which of its users to disappoint. ### Additivity as the only safe posture The resolution we find most defensible is not a compromise between the poles but a constraint on how they combine: **derived layers must never replace the substrate they were derived from.** Keep raw as ground truth. Add facts, summaries, entity observations, and graph structure as indexes over it. Let retrieval use whichever serves the query. The argument for this is asymmetric risk rather than average accuracy. A pipeline where extraction replaces raw has an unrecoverable failure mode: when the extractor mispredicts — drops a detail, resolves a pronoun wrongly, silently degrades after a model upgrade — the original is gone and no downstream improvement can recover it. A pipeline where extraction merely adds an index has a bounded failure mode: a bad derived layer costs precision and can be regenerated. One is a bug, the other is data loss. This also has an underappreciated operational consequence. Extraction quality drifts silently as prompts and models change, and nobody notices, because evaluations exercise retrieval over a frozen corpus and never re-examine the ingest that produced it. If raw is retained, that drift is repairable by re-deriving. If it is not, the drift is permanent and invisible. ### Where the intelligence lives Underneath the extraction debate is a more general design axis: does the system spend its effort at write time or at read time? Write time has abundant latency budget and no knowledge of the question. Read time has the question and almost no latency budget. Every architecture in this space is a position on that trade. Write-time synthesis is the most interesting version of the bet, because it is a bet made deliberately rather than incidentally. Pre-computing a per-entity summary turns a multi-hop aggregation question into a single-hop retrieval — the expensive stitching happens where there is time to do it well. The cost is that the synthesis anticipates some questions and not others, and now staleness and regeneration policy become moving parts of their own. It is a real technique with a real bill.[^extraction-is-a-bet-3] Which pole is correct depends on the read/write ratio of the workload, which is to say it depends on the product. Per-message extraction cost dominates for chatty users; per-query reranking cost dominates for retrieval-heavy agents. This is a business decision wearing an architecture decision's clothes, and it is usually made implicitly. ### What stays open We hold the additivity constraint with reasonable confidence, because its failure modes are well attested across independent systems and the asymmetry argument does not depend on any particular benchmark. Several things around it we genuinely do not know. - Whether derived layers should compete in one ranked list with raw, or be routed to by query type. A shared index avoids a brittle router; separate channels give control but every fusion scheme introduces failure modes of its own. - How aggressive supersession should be. Marking validity intervals without deleting preserves recoverability and enables "as of" queries, but a store that never discards anything eventually loses precision to accumulation — and detecting genuine contradiction is hard, since "I work at A" and "I work at B" may be an update, a contradiction, or both true. - Whether rerankers trained on web question answering transfer to personal-memory relevance at all. "Relevant to a query" and "relevant to this person's history" are different notions, and we consider the mismatch an under-examined weakness of most current stacks, ours included. What we would ask of any memory system, including our own, is simply that the bet be legible: which questions did this pipeline decide were worth anticipating, what did it discard to do so, and can that decision be reversed after the fact. A system that cannot answer those three questions is not neutral about the future. It has just declined to tell you what it wagered. [^extraction-is-a-bet-1]: *AtomMem: Building Simple and Effective Memory System for LLM Agents via Atomic Facts* (arXiv:2606.19847) versus *Rethinking How to Remember: Beyond Atomic Facts in Lifelong LLM Agent Memory* (arXiv:2605.19952). Reading them side by side is the fastest way to see that the field has not converged here. [^extraction-is-a-bet-2]: *Supersede: Diagnosing and Training the Memory-Update Gap in LLM Agents* (arXiv:2606.27472). The framing as a distinct diagnosable gap, rather than a retrieval quality issue, is the useful contribution. [^extraction-is-a-bet-3]: Vectorize's write-up on the consolidation problem in agent memory is a good practitioner account of how quickly regeneration policy becomes the hard part. --- ## The Benchmark Is Not the Territory Published 2026-07-21 · Esment Research · Canonical: https://esment.notas.ai/research/the-benchmark-is-not-the-territory ### Introduction Every serious memory system for language agents is now reported against the same two or three numbers. Those numbers have gone up a lot in eighteen months. It is worth asking, carefully, what they have gone up *at* — because the benchmarks that produce them share a structural assumption that almost no deployed memory system satisfies: that the corpus holds still. This piece contains no scores of our own. We think publishing another point on a saturated and largely non-comparable axis is not a contribution right now. Naming precisely what that axis fails to cover might be. ### The corpus holds still The dominant conversational-memory benchmarks are question answering over a *fixed* transcript. A history is ingested once, the store is frozen, and questions are asked against it. Everything the evaluation observes happens on the read path. A deployed memory system spends almost none of its life in that state. It is written to continuously. Facts arrive that contradict earlier facts. Users correct things. Records get deleted for reasons ranging from a typo to a legal request. Derived layers — summaries, entity graphs, embeddings — have to be kept consistent with a substrate that keeps moving. The interesting failures of a real memory system are mutation failures, and a frozen-corpus benchmark cannot express them. This is worth stating precisely, because it is stronger than the usual complaint about benchmark coverage. The write path is not under-weighted in these evaluations. It is unscored *by construction*: the experimental design has no place to put it. *Figure — The read path is what conversational-memory benchmarks score. The write path — extraction, supersession, deletion, and the propagation of each into derived layers — falls outside the experimental frame entirely, because the corpus is frozen before the first question is asked.* ### What recall measures Set the write path aside and look only at what is scored. Even there, the headline numbers turn out to measure something narrower than "does this system remember." In LoCoMo, roughly 94% of the evaluation questions can be grounded in evidence from no more than two prior sessions, and the conversations run on the order of sixteen to twenty-six thousand tokens.[^the-benchmark-is-not-the-territory-1] That length fits inside a current context window. A meaningful share of the score is therefore reachable by having no memory system at all and simply passing the transcript — which makes the benchmark a weak instrument for the thing it is being used to justify. The scoring conventions add their own distortion. Task-disclosed prompting and string-matching metrics conflate memory fidelity with prompt adaptation and generation style: a system can gain points by phrasing answers the way the metric likes, independently of whether it recalled anything better. The sharpest evidence that recall and usefulness have come apart is MemoryArena, which embeds memory inside multi-session agentic tasks where later subtasks depend on what was learned earlier. Systems that score near-perfectly on LoCoMo fall to roughly 40–60% there.[^the-benchmark-is-not-the-territory-2] A forty-point collapse when the same stored knowledge has to drive a decision rather than answer a quiz is not a tuning gap. It says the two tasks were never the same task. ### The judge is inside the system There is a further problem that makes cross-vendor comparison unsound rather than merely noisy. In LLM-as-judge evaluation, the judge model and its prompt are components of the system under test. Changing either moves scores by several points. A lenient judge inflates everything uniformly, which is worse than it sounds: it also hides regressions, because the leniency absorbs them. Once you add the other unpinned knobs — the answer model, the retrieval budget, whether the reader is told the question category, how the adversarial and unanswerable questions are handled — published gaps between competing systems largely reduce to harness differences. Independent re-runs of vendor claims have repeatedly landed well below the announced figures.[^the-benchmark-is-not-the-territory-3] The practical rule this implies is uncomfortable for marketing and obvious for research: **a leaderboard delta smaller than the harness delta is not a result.** Unless the judge, judge prompt, reader model, and token budget are pinned and published, a comparison between two systems is a comparison between two experimental setups. ### The unscored properties If the frozen corpus hides the write path, what exactly is hidden? These are the questions we think a memory system should have to answer, none of which the standard evaluations ask: - When a new fact contradicts an old one, does the old one actually stop being retrieved — and if it was wrongly superseded, can the loss be detected or reversed? - When a record is deleted, does the deletion propagate to every derived layer that absorbed it: summaries, entity nodes, graph edges, vector indexes? - Does retrieval precision hold up after months of accumulation, or does undiscarded stale material gradually poison it? - Can each injected token be traced back to the utterance it came from, well enough to explain or repair a wrong memory? - What does one remembered message cost, in latency and in inference, at ingest and at query? - Under multi-tenancy, can one tenant's history influence another's retrieval? Of these, only selective forgetting is explicitly tested anywhere in common use, and even there by a single benchmark.[^the-benchmark-is-not-the-territory-4] Provenance is in a worse position still: current systems generally offer limited support for tracing where a memory item came from or whether it remains valid, and treating memory as provenance-bearing evidence is an acknowledged open problem rather than a solved feature. Several production memory layers delegate deletion and audit consistency to the calling application entirely. ### Toward a better axis The field has started to notice. The 2026 crop of benchmarks is visibly trying to escape passive recall: MemoryArena putting memory inside dependent agentic tasks, StreamMemBench evaluating in a streaming rather than batch setting, AMA-Bench targeting long-horizon agentic applications, and work explicitly reframing the problem from recall toward forgetting.[^the-benchmark-is-not-the-territory-5] This is the right direction and it is moving fast. What still has no benchmark is the axis we think matters most: **correctness of the store as it changes.** Not "can you find the answer in a fixed pile," but "after six months of writes, corrections, contradictions, and deletions, is the pile still true, still precise, and still explainable." Every property in the list above is a property of a system in motion, and every current evaluation observes the system at rest. We are building toward measuring that, and we would rather say so plainly than post a number on the old axis. When we do publish results, they will come with the judge, the judge prompt, the reader model, the token budget, the seeds, and the per-category breakdown — because without those, as argued above, there is no result to report. An oracle-context ceiling belongs in that same disclosure, since it is the only clean way to separate a retrieval failure from a reader failure, and the two are routinely reported as one. None of this says the existing benchmarks were a mistake. They gave the field a shared starting point, and a shared starting point is worth a great deal. But a map that was drawn for one purpose gets dangerous when it is the only map and everyone starts optimizing the map instead of the ground. The score is not the memory. The benchmark is not the territory. [^the-benchmark-is-not-the-territory-1]: Both properties are widely reported in the 2026 evaluation literature; see the survey *Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers* (arXiv:2603.07670) and *Locomo-Plus* (arXiv:2602.10715), which was built specifically to push past the original benchmark's factual-recall ceiling. [^the-benchmark-is-not-the-territory-2]: MemoryArena: *Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks* (arXiv:2602.16313). The gap it reports is between passive recall and memory that has to inform a decision — the distinction this whole section turns on. [^the-benchmark-is-not-the-territory-3]: Zep's re-examination of Mem0's state-of-the-art claim is the most-cited public instance, but the pattern is general: the reproduction is not usually contesting the implementation, it is contesting the harness. [^the-benchmark-is-not-the-territory-4]: MemoryAgentBench is the usual exception cited. The 2026 literature on this is worth reading in full: *Agentic Unlearning* (arXiv:2602.17692), *From Lossy to Verified: A Provenance-Aware Tiered Memory for Agents* (arXiv:2602.17913), and the survey *Toward Mnemonic Sovereignty* (arXiv:2604.16548), which frames memory security across six lifecycle phases — write, store, retrieve, execute, share, and forget/rollback. [^the-benchmark-is-not-the-territory-5]: *StreamMemBench* (arXiv:2606.14571), *AMA-Bench* (arXiv:2602.22769), and *From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents* (arXiv:2604.20006). # Newsroom ## Smarter summaries of what your assistants know Published 2026-10-30 · Esment · Canonical: https://esment.notas.ai/newsroom/smarter-memory-summaries *Product update* Esment writes short summaries of the people, projects and topics in your memory. They now update only when there is something new to say, and they read the same on every device. Besides the memories you save, Esment keeps a short summary for the people, projects and topics that come up most often. Those summaries are written automatically from what your assistants have learned, and until now they were not always as tidy as they should be. Today we have improved how they are kept up to date. ### What is better - Summaries are rewritten only when there is real news to add, not each time your memory syncs. Your overview stays steady, and the wording changes when the facts do. - Each person, project or topic keeps a single current summary. Older versions no longer pile up next to it. - Summaries behave the same whether your memory lives on your Mac or in the cloud, so you no longer see different copies on different devices. - Summaries are clearly labeled "Auto summary" in your memories list, so you can tell at a glance what Esment wrote and what you saved yourself. ### Why it matters A summary is only useful if you can trust it is current and that there is just one of them. These changes keep your overview accurate, and they keep your memory easier to read and easier to check. [Open your memories](https://esment.notas.ai/app/memories) --- ## A calendar for your memory Published 2026-10-29 · Esment · Canonical: https://esment.notas.ai/newsroom/memory-calendar *Product update* History now opens as a calendar, on the web and in the Mac app: see what your assistants learned on any day, track your activity, and travel back to any day and hour. Every memory in Esment has a date, and every change to it is recorded. Until now you browsed that history as a list. Starting today, History opens as a calendar in the web dashboard and in Esment for Mac, with each saved, edited or forgotten memory placed on the day it happened. ### What is new - Four views: Day, Week, Month and Year. On a phone, Week shows three days at a time. Each change sits at the hour it happened, colored by type: saved, edited or forgotten. - Pick a day to open its memories below the calendar. On a phone they open in a sheet you close with a tap outside or the X. - An activity map, in the style of a contribution graph, shows how often your memory grows, with your current streak and your busiest day. - A new card on the Overview page shows the last months of activity. Click any day to open the calendar on it. - Time Travel now starts from a calendar: choose a day, then drag along the hours to see exactly what your memory held at that moment, and how many memories it had compared with today. - The list view is still there, one click away, for anyone who prefers it. ### Why it matters A memory you cannot inspect is a memory you cannot trust. The calendar makes it easy to answer simple questions: what did my assistants learn this week, when did this fact change, and what did they know before it did. ### How to get it On the web, open Memories, then History. In the Mac app, the update arrives automatically; the calendar is under Memories, then History, and the activity card is on Overview. [Open your dashboard](https://esment.notas.ai/app/memories/history) --- ## Esment for Mac now runs on macOS Monterey Published 2026-10-24 · Esment · Canonical: https://esment.notas.ai/newsroom/esment-for-mac-on-macos-monterey *Product update* Version 1.8.2 of the Mac app supports macOS 12 Monterey, so Macs that cannot update to Ventura or later can run Esment too. Until now, Esment for Mac required macOS 13 Ventura or later. Many Macs that work perfectly well stop at macOS 12 Monterey, such as the 2017 MacBook Air, and their owners could not install the app. Starting with version 1.8.2, Esment for Mac runs on macOS 12 Monterey and later. ### What changes - The Mac app installs and runs on macOS 12 Monterey. Memory stays on your Mac, and assistants such as Claude, ChatGPT and Cursor connect to it as usual. - On macOS 13 and later, nothing changes: the app looks and works exactly as before. - On macOS 12, a few details are simpler: the charts on the Overview page are not shown, and some text fields and lists use the system styling. ### How to get it If you already have Esment, the update arrives automatically. If you are on Monterey and could not install it before, download the app and open it as usual. [Download Esment for Mac](https://esment.notas.ai/download) --- ## Voice notes: say it once, and your assistant remembers it Published 2026-10-19 · Esment · Canonical: https://esment.notas.ai/newsroom/voice-notes *Product update* Record a thought on your Mac or in the browser. Esment transcribes it on your own device, and your assistant turns it into memories linked to the exact moment you said each thing. Some things are easier to say than to type: an idea on a walk, the decisions after a call, what you want to remember about a book. Starting today, Esment has voice notes. You record, Esment writes down what you said, and the assistant you already use, such as Claude or ChatGPT, saves what matters as memories. ### How it works - Record. In the Mac app (Voice notes, or ⌥V from anywhere) or on the web dashboard under Memories → Voice. Up to 60 minutes per recording on the web. - Transcribe. The transcript is made on your device, not by an AI service: Whisper runs on your Mac, or in your browser on your own graphics card. The audio is never sent anywhere to be transcribed. - Process. Choose Process with assistant and Esment opens Claude or ChatGPT with the instruction already written. Your assistant reads the note through Esment and saves one memory per idea worth keeping. You can also simply ask it to “process my voice notes”. - Find it again. Each memory is linked to its note and to the second where you said it. From a memory you can open the note and play that exact moment. ### A transcript is not a memory Esment does not turn everything you say into memories. Thinking aloud, repetitions and microphone tests stay in the note. Your assistant decides what deserves to be kept, writes it as clear, self-contained facts, turns “tomorrow” into a real date, and corrects older memories when something has changed. A note becomes Processed once the first memory is saved from it; a note that held nothing worth keeping stays Pending for you to review. ### Your words, spelled your way Speech recognition struggles with names, brands and jargon. Add them under Your words (in the transcription settings on the web, or in Voice notes on the Mac) and every new transcript spells them the way you wrote them, on every device. You can also correct any line of a transcript by clicking on it, just like the title. The audio stays as recorded; the corrected text is what your assistant reads. ### Languages Pick the language before recording or leave it on Detect. Detection listens across the whole note, so a book title said in English does not turn a Spanish note into English. Supported: English, Spanish, French, German, Portuguese, Italian and Catalan. ### Two models in the browser On the web you can choose Accurate (Whisper large-v3-turbo, a one-time download of about 567 MB, close to word for word) or Light (about 80 MB, faster, more mistakes). Esment recommends one for your device and suggests switching if it turns out slow. The model is downloaded once and kept in your browser. ### Plans | Plan | Voice notes | Transcripts kept (cloud) | Audio kept (cloud) | | --- | --- | --- | --- | | Free | — | — | — | | Starter | — | — | — | | Founding | Included | 1,000 | 500 MB (about 45 hours) | | Plus | Included | 1,000 | 500 MB (about 45 hours) | | Pro | Included | 10,000 | 3 GB (about 275 hours) | | Teams | Included | Unlimited | 10 GB per workspace | | Enterprise | Included | Unlimited | Custom | On the Mac app there is no limit: notes and audio stay on your machine. If you change plans, nothing is deleted: you can still read, export and remove the notes you have. ### Privacy - Transcription happens on your device, never on an AI service. - On the Mac, audio stays on your Mac; only the text syncs. - On the web, audio is stored privately and played through short-lived links. You can delete the audio of any note and keep the text, or delete the note entirely. Memories created from it stay. - Esment does not run an AI over your notes. Your own assistant does the processing, under your account. ### What you need to do On a Founding, Plus, Pro or Teams plan, open Memories → Voice on the web, or update the Mac app and open Voice notes. Record something, then choose Process with assistant. [Open voice notes](https://esment.notas.ai/app/memories/voice) --- ## More memory on every Esment plan Published 2026-10-14 · Esment · Canonical: https://esment.notas.ai/newsroom/more-memory-on-every-plan *Announcement* Starting today, every Esment plan holds more memories, and some cost less. Your current plan upgrades automatically, with nothing to do. Esment gives the assistants you already use, such as Claude, ChatGPT and Cursor, a memory that persists. Plans are how much of it you can keep. Here is what changes. | Plan | Before | Now | | --- | --- | --- | | Free (cloud only) | 250 memories | 500 memories | | Founding (annual, beta only) | 1,000 memories, $50/year | 10,000 memories (10×), $50/year | | Starter | 500 memories, $9/month | 5,000 memories (10×), $5/month | | Plus (new) | — | 50,000 memories, $15/month or $150/year | | Pro | 5,000 memories | 200,000 memories (40×), $49/month or $39.17/month billed annually | | Teams | 10,000 per workspace | Unlimited memories (fair use), 5 workspaces, $60/month billed annually | | Enterprise | Custom, on your infrastructure | No change | Prices are in USD, excluding taxes. Every paid plan includes the macOS app, with memory stored locally, and synced cloud memory. Plus is the step we were missing between Starter and Pro: 50,000 memories for people who have outgrown Starter but do not need Pro’s scale. Pro keeps a workspace of your own and lets you join someone else’s. ### What happens to my current plan? Nothing is taken away. Your plan keeps its current terms and, where the new version is better, you move up at no cost and with no action on your part. Founding subscribers go from 1,000 to 10,000 memories at the same price. ### Why is Founding annual-only? Founding is for people backing Esment during the beta. Annual billing is how it supports the beta, and it makes Founding the lowest-priced way to get 10,000 memories: $50 a year. It stays open until the beta closes, and anyone who subscribes keeps that price for good. ### See the new plans Compare every plan side by side on the pricing page. [See the new plans](https://esment.notas.ai/pricing) --- ## Esment 1.8.0: memory search that is faster, multilingual and fully private on your Mac Published 2026-10-14 · Esment · Canonical: https://esment.notas.ai/newsroom/retrieval-v2-faster-multilingual-memory-search *Product update* A rebuilt search puts the memories that matter first, answers in a fraction of the time, works across five languages and runs entirely on your Mac, now including Intel. Esment today released version 1.8.0 of its macOS app, built around a new memory search we call retrieval v2. It is already live on Esment Cloud, for every plan including Free. ### What you will notice - Your assistant recalls better. The memories that matter for your question arrive first. - Searches are much faster, taking a fraction of the time they took before. - It works in your language: Spanish, English, German, French and Italian, even when you saved something in one language and ask in another. - On your Mac, search runs privately and offline, with nothing sent to anyone. - Esment now runs on Intel Macs as well as Apple Silicon. ### How it works Think of searching a library. First, the search looks in several ways at once: for the exact words you used, for ideas that mean the same thing, and for things connected to the people and projects you mention. That gives a long pile of possible books. Then an expert librarian steps in. A second model reads your actual question next to each candidate and puts the ones that truly answer it on top. The pile is the same; the order is what changes, and the order is what your assistant sees first. ### Privacy and local The Mac app includes the search models. They run on your machine, so your text is not sent to anyone and nothing needs to be downloaded, even with no connection. Advanced users who prefer it can use their own OpenAI key for embeddings in Settings > Advanced. Switching is safe: the app re-indexes your memories in the background, and you can go back to Local at any time. ### Intel Macs The 1.8.0 download is a single app for both Apple Silicon and Intel Macs, with the same on-device search on each. ### What you need to do Nothing. Your memories stay exactly as they are and the app updates itself. If you want it now, choose Check for Updates in the Esment menu or download the latest version from the download page. Better recall is the quiet part of a memory product: when it works, you simply stop repeating yourself. We will keep refining it, and we would like to hear where it still misses. --- ## Esment's Agent Plugin brings persistent memory to ChatGPT, Claude and Cursor Published 2026-08-06 · Esment · Canonical: https://esment.notas.ai/newsroom/agent-plugin-openai-claude-cursor *Press release* The Esment Agent Plugin installs a local memory server into the assistants you already use — with deterministic, always-on recall that never waits to be asked. Esment today announced the release of its Agent Plugin, a single install that connects ChatGPT, Claude Code, Cursor and other MCP-capable assistants to a persistent, inspectable memory store — running entirely on the user’s own machine. Unlike cloud memory services that hold a copy of what your assistant knows, the Esment plugin spawns a local memory server next to the assistant itself. Every recall and every write stays on-device, in a SQLite store the user can open, search and export at any time. ### Memory that does not wait to be asked The plugin ships with deterministic injection hooks: before each conversation, the harness loads a session brief built from the user’s own memories — the people, projects, preferences and decisions that matter right now. Recall stops depending on whether the model happens to reach for a tool. - Local MCP server bundled with the plugin — no cloud account required - Deterministic session briefs injected before the model answers - Automatic saves: facts, preferences and decisions are stored as you share them - Full auditability: every memory mutation is a signed, inspectable commit ### Availability The plugin is available today for ChatGPT desktop (via the personal marketplace), Claude Code, Cursor and any client that speaks the Model Context Protocol. Installation is one command, and the same memory store is shared by every connected assistant. > Memory should be a property of the assistant you already use, not a separate product you have to remember to open. The plugin is the closest version of that: install once, and every assistant starts from what you know. --- ## Esment Cloud enters public beta Published 2026-07-21 · Esment · Canonical: https://esment.notas.ai/newsroom/cloud-public-beta *Announcement* The hosted Esment service — cloud memory for web assistants, plus bidirectional sync with the macOS app — is now live in public beta. Esment Cloud, the hosted service that brings the same memory engine to web-based assistants, is now in public beta. Any Esment account can connect web assistants — ChatGPT, Perplexity and other remote MCP clients — to a cloud memory tenant, or sync their local store with it in both directions. ### What the beta includes - Remote MCP endpoint with OAuth 2.1 — assistants connect with the same tools they use locally - Bidirectional sync between the macOS app and the cloud tenant, additive and conflict-safe - The web dashboard: browse, search, pin and forget memories from any browser - Per-plan limits enforced server-side, from the free tier through Enterprise ### Local-first stays first The cloud is an extension, not a replacement. The macOS app and the plugin remain fully local-first: no account, no network, no telemetry required. Cloud sync is opt-in, and what syncs is what you choose to sync. During the beta, the service is available to all plans. Pricing and plan limits will firm up as the beta closes; the local product stays free. --- ## Deterministic recall: memory that never waits to be asked Published 2026-06-30 · Esment · Canonical: https://esment.notas.ai/newsroom/deterministic-recall *Product update* A session brief built from your own memories is now injected before every reply — recall stops being the model’s decision and becomes the harness’s guarantee. The deepest problem with assistant memory has never been storage — it is recall. A model that only searches memory when it thinks to search will, on average, not think to search. This update removes that dependency. Esment now builds a session brief — the people, projects, preferences and recent decisions the user actually cares about — and injects it into the context before the model answers. The retrieval pipeline behind it (full-text, vector, graph expansion and reranking) runs locally, in tens of milliseconds, with no network call. ### What changes in practice - Every new conversation starts from what you know, not from nothing - The brief is inspectable: you can see exactly what was injected and why - Writes are just as automatic — facts shared in conversation are stored and scored without prompts - It works on every surface: macOS app, Claude Code, Cursor, and web assistants through the cloud > Deterministic injection is the difference between a memory that exists and a memory that is used.