DEV Community: Edward Izgorodin

Agent Memory: Everything It Remembers Has the Same Authority, and That Is the Bug

Edward Izgorodin — Wed, 19 Aug 2026 15:18:00 +0000

Every team that wires long-term memory into a coding agent hits the same wall about three weeks in. The agent remembers plenty. It remembers the migration you abandoned, the library you replaced, the convention one person suggested once in a thread. It recalls all of it with the same flat confidence, and now you are debugging your memory instead of your code.

The instinct at that point is to store less, or to store better. Both are the wrong axis. The problem is not how much the agent remembers. The problem is that everything it remembers has the same authority.

Short-term versus long-term is not the useful split

The common framing separates the conversation you are in now from facts you keep forever. It is a real distinction, and it will not help you, because it says nothing about what the agent should do when two remembered things disagree.

A more useful split is evidence versus policy.

Evidence is what happened. The agent tried a fix and it failed. A user rewrote a function. A test went red. Evidence is cheap to produce, it accumulates fast, and any single piece of it can be wrong or unrepresentative.

Policy is what should happen. Use pnpm. Tests mirror the src layout. Never touch the legacy billing module. Policy is expensive to produce, because a human usually decides it, and it should be hard to change by accident.

Hold those apart and a lot of confusing behaviour becomes obvious. An agent that treats one observation as policy overfits to a single incident. An agent that treats a merged architecture decision as mere evidence keeps relitigating it. Most memory systems collapse both into one undifferentiated bucket of "things we know," which is exactly why they feel unpredictable.

Three layers, ordered by how easily they should change

In practice the split works better as three layers, because evidence and policy live at different scopes.

Shared project truth. Architecture decision records, API contracts, naming conventions, the deployment runbook. This is policy: versioned, source-linked, and the same copy for every agent on the project. If your agent invents its own answer to "which database do we use," that is not a memory problem, it is a missing shared layer.

Role memory. Heuristics that belong to a job rather than to a project. What a frontend reviewer usually checks. How the QA pass is structured. Which failure modes a migration tends to hit. This is the layer most systems skip entirely, and it is why teams re-teach the same review standards to every new session.

Episodes. What happened on a task: what was attempted, what failed, what feedback followed. Evidence in its rawest form, the layer that grows fastest and rots fastest.

These are not ranked by importance. They are ranked by how easily something should change. Episodes are written constantly. Role memory shifts slowly. Shared project truth changes only when a human decides it does.

The two time axes, and the bug you get free without them

This is the part worth stealing even if you ignore everything else.

Say your codebase used Redux, and last quarter you moved to Zustand.

With one time axis, the agent learns "we use Zustand" and the older note is overwritten or decays away. Now ask why a component written in March is structured the way it is. The agent cannot tell you. The fact that explains that code has been deleted, because it is no longer current.

But "recorded at" and "was true from / until" are different questions. "Use Redux" was true from January to June and was recorded in February. It is not wrong. It is closed. An agent that keeps closed facts with their validity window can still explain old code, warn you that a pattern you are copying belongs to a superseded era, and avoid confidently rewriting history.

Replacing a fact instead of closing it is the most common destructive operation in agent memory, and it stays invisible until someone asks about the past.

None of this is new engineering, by the way. Separating when a fact was true from when the system learned it is bitemporal modelling, standardised in SQL:2011 as application-time and system-versioned period tables (ISO/IEC 9075:2011; Kulkarni and Michels, Temporal features in SQL:2011, DOI:10.1145/2380776.2380786). The database people solved this before agents existed.

Evidence should have to earn its way into policy

If evidence and policy are different things, there has to be a path between them, and it should be explicit rather than accidental.

An agent observation starts as low-authority evidence. It becomes policy through one of a few events: a human correction, which is the strongest signal there is; a merged ADR or pull request that puts the decision in the repository; or a repeated successful outcome, where the same approach has worked often enough to stop being a guess.

The important word is earns. Systems that let a single agent observation write straight into shared knowledge will drift, and the drift is hard to spot because every individual step looks reasonable.

Demotion matters too and is rarer to see implemented. If a policy keeps producing failures, something should notice. Not delete it automatically: mark it disputed and surface that to a human.

Retrieval should hand you contradictions, not resolve them quietly

This is where most implementations go wrong, and it follows from everything above.

The default behaviour of a vector store is to return the nearest matches. If two stored items contradict each other, the one that happens to sit closer in embedding space wins, silently, and the agent proceeds as though there was never a disagreement.

That is backwards. A contradiction is information. If the store holds "we use Redux, valid until June" and "we use Zustand, valid from June," the right move is not to pick one. It is to return both with their validity windows and let the reasoning step deal with it. Same for a policy that a recent episode contradicts: an agent that sees "convention says X" next to "X failed twice last week" can raise it with you. An agent that sees only the closer embedding match cannot.

Preserving contradictions costs context budget. That is the honest trade. Losing them costs correctness in a way you cannot detect from the outside.

The practical gap nobody mentions

Here is the thing that surprises teams most, and it has nothing to do with architecture.

Connecting a memory tool does not make an agent use it.

You can wire up a perfectly good backend, expose it over MCP, watch the tools register, and then watch the agent go an entire session without calling any of them. Tool availability is not tool usage. The model has no standing incentive to check memory before acting, and no habit of writing anything down afterwards.

What closes the gap is boring: a standing instruction. Something in the system prompt or the project rules that says, in effect, recall before acting on anything project-specific, and save durable decisions and corrections when they happen. In Cursor that is a rule file. In Claude Code it is the project instructions. The exact mechanism matters much less than the instruction existing at all.

If you take one thing from this piece, take that one. It is the cheapest fix on the list and the one most often missing.

Disclosure: I work on Mnemoverse, a memory engine for AI agents. This article is adapted from the original in our library, which carries the FAQ and the mechanics in more depth: Agent memory: evidence versus policy.

Knowledge Graph vs Retrieval for Agent Memory: The Real Split Is What You Are Willing to Assert

Edward Izgorodin — Mon, 17 Aug 2026 14:21:00 +0000

"Should agent memory use a knowledge graph or retrieval?" is the wrong question, and the reason is worth more than the answer. Both are storage shapes. The decision that actually changes how your system fails is whether you store structure your system learned from use, or structure someone asserted about the world. Those two carry different truth guarantees, and merging them into one "memory graph" is how systems become confident without becoming checkable.

Here are the four terms that carry the whole argument.

A knowledge graph stores typed, directed relations between resolved entities. It asserts facts about the world and answers by traversal.

A learned graph, or associative memory, stores untyped weighted links that come from co-occurrence and use. It asserts nothing attributable and never merges identities.

Entity resolution is the decision that two mentions refer to the same thing. It is the load-bearing and most expensive assertion in any knowledge graph.

Provenance is the record of where a memory came from: the source link, the retrieval date, and the exact text that was read.

Disclosure before we go further: I work on Mnemoverse, which ships the learned side of this split, so I have a position. I have tried to make the trade-offs verifiable rather than flattering, including one place where the evidence goes against me.

The two structures fail in completely different ways

An asserted edge that is wrong is precisely wrong. If the system decided that "J. Smith", "Jane Smith" and "Jane A. Smith" are one person, and they are not, then every traversal crossing that merged node inherits the error. The system will state a falsehood with full confidence, and it will be attributable to a specific stored claim.

A learned edge that is wrong is never an explicit falsehood. It is a bias in what surfaces. That sounds safer, and in one narrow sense it is: no attributable claim, no identity merging. But it is not the same as "cannot mislead."

Two results make that concrete. Caliskan, Bryson and Narayanan showed that embeddings trained purely on language co-occurrence predict real occupational gender composition at rho = 0.90 and reproduce human bias effects (Science 356, 2017). Co-occurrence is not neutral just because nobody typed an explicit edge. And from psychology, the DRM paradigm shows that hearing bed, rest, tired produces confident false recall of sleep, a word that was never presented, in roughly 40 to 55 percent of trials (Roediger and McDermott, 1995). Associative structure alone is enough to manufacture a memory.

So the honest formulation for a learned graph is "no attributable claim, no identity merging," not "cannot be wrong."

Asserting identity is expensive, and the cost is structural

A knowledge graph earns real power. Traversal over typed relations answers questions plain retrieval handles badly. The price is entity resolution, and it is not an implementation detail you optimize away later.

The systems that do this at scale treat it with visible caution. Google's Knowledge Vault attached a calibrated confidence to every extracted triple rather than asserting it flat, and only a minority of triples reached high confidence (Dong et al., KDD 2014). Zep's Graphiti puts validity intervals on edges and runs entity resolution at ingest with an LLM in the loop (arXiv:2501.13956). Microsoft's GraphRAG builds an LLM-derived entity graph and says plainly in its own paper that indexing is expensive and the win shows up on global, corpus-level questions rather than needle lookup (arXiv:2404.16130).

None of them treats entity resolution as cheap or solved. Adding asserted structure means accepting that cost, and accepting that some merges will be precisely wrong.

A stored paraphrase is a stored misgrounding

Here is the shortcut almost every memory pipeline takes. At write time, an LLM extracts a summary of what happened, and the summary gets stored next to a pointer at the source. The retriever sees the summary. The pointer is there so someone can check later.

Nobody checks later.

A preregistered study of commercial legal AI tools measured hallucination rates of 17 to 33 percent, where hallucination includes misgrounding: the answer cites a source, and the source does not support the claim (Magesh et al., Journal of Empirical Legal Studies). A stored paraphrase beside a pointer is that failure mode by construction, and it is undetectable without re-reading the source.

The obvious fix, storing just the pointer, has its own decay. The Hypothes.is anchoring study looked at about 21,000 quote-anchored web annotations collected over roughly two years: 22 percent no longer matched their live page, 19 percent were permanently unrecoverable, and only about 12 percent of the broken ones could be re-attached through web archives (arXiv:1512.06195). A bare pointer is honest only at write time.

What works is storing the verbatim span that was read, together with the source link and the retrieval date. The span does three jobs at once. It is deterministic, because it is bytes from the source rather than a model's interpretation. It is ordinary text, so it embeds and searches like everything else. And it is exactly what a W3C Web Annotation TextQuoteSelector is: exact text with prefix and suffix, which re-locates the passage later and fails detectably when the document changed (W3C Web Annotation Data Model).

That last property is the whole point. Fuzzy anchoring reports failure. A paraphrase lies silently.

Anthropic's Citations API follows the same instinct: cited text is extracted directly with character indices, so interpretation happens at read time instead of being frozen into storage.

Provenance is the bridge, not a merge

If learned and asserted structure answer different questions with different guarantees, then the thing connecting them cannot be a merge. It has to be a record of consultation: what was read, from where, and when.

This is standardised prior art, not something to invent. Memento (RFC 7089) defines the original resource and the archived state with its datetime. Robust Links carry data-originalurl, data-versionurl and data-versiondate, so a reader can find a replacement snapshot if one archive dies. Wikipedia's citation templates even record drift as a state: url-status=deviated means the link is alive but no longer supports the claim it was cited for.

One limit worth stating plainly: at most 38.7 percent of composite web mementos are temporally coherent, and at most 17.9 percent are both coherent and complete, because embedded resources get captured at different moments (Ainsworth, Nelson, Van de Sompel). So promise the text span, not the whole page.

The part where the evidence goes against me

I would rather state this than have you find it.

The dominant memory architectures store interpretations, not raw spans, and they have a measurement on their side. Generative Agents stores natural-language experience records and synthesises reflections. RAPTOR stores recursive summaries as retrieval units. And on LOCOMO, a benchmark of question answering over long multi-session conversations, the best chunk-based RAG configuration reaches a judge score of J = 60.97 while LLM-extracted dense memories reach J = 66.88 (Table 2 of arXiv:2504.19413; note that this is the Mem0 team evaluating its own system).

The mechanism is not mysterious. A distilled fact is denser than the conversation around it, so the same retrieval budget lands on the answer more often.

That result should not be waved away, and I am not going to pretend it does not exist. Extraction buys benchmark points. What it costs is auditability, because an extracted memory is already a judgment and the system can only trust the extractor that made it. Storing the original wording and the original pointer gives up those points on purpose.

Make that trade explicitly. The one thing to never do is let an extractor's sentence silently become the stored fact.

A decision rule you can actually use

Not a verdict, a rule.

Use retrieval when the agent needs to find past evidence. This is the floor and it is the right default.

Add learned association when lexical retrieval keeps missing related memories that would have helped. Treat what it returns as ranking influence, not as truth.

Add an asserted knowledge graph when the agent must answer structural questions over resolved entities, and only when you accept entity resolution as a stored assertion you will sometimes have to correct.

Keep provenance across all three: source link, retrieval date, exact text read, and a dated snapshot where you can get one.

The two structures do not need to merge. They need to be connected by a record that can be checked. Treating them as one artifact is exactly how a memory system becomes confident without becoming checkable.

This is a shorter version of an article in the Mnemoverse library, where the full argument, the complete source list, and the related pieces on provenance and bitemporal memory live.

Why Your AI Agent Forgets Everything Between Sessions (and the Three Honest Fixes)

Edward Izgorodin — Fri, 14 Aug 2026 15:05:55 +0000

Your AI agent forgets everything between sessions because nothing in the stack persists by default: the context window empties when the session ends, and the model's weights only change when the vendor ships a new model. "Remember this" gets a polite acknowledgement, then vanishes. The fix is always some form of external memory, and there are exactly three honest ways to add one: files your agent reads, a self-hosted memory store, or a managed memory layer over MCP. Which one is right depends on which problem you actually have.

The forgetting is structural, not a bug

Every session starts from a blank context window. Whatever you explained yesterday, the decisions you made, the conventions you agreed on, the bug you already fixed twice: none of it exists for the agent today unless something outside the model carries it.

This is why the same complaints keep showing up in every community where people use coding agents seriously. You get tired of re-explaining who you are and how your project works. The agent confidently contradicts a decision it helped you make on Tuesday. It suggests npm in a pnpm repo for the third time this week. Longer context windows do not fix this: a million tokens still empty out at the end of the session, and most of what you paste back in is noise by then.

So the real question is not "why does it forget" but "where should the memory live". Three camps, each with a genuine reason to exist.

Fix 1: files the agent reads (CLAUDE.md, AGENTS.md, notes)

The simplest fix is a markdown file in your repo that the agent reads at the start of every session: project conventions, key decisions, things it should never do. Most coding agents support this natively, and you can go further with agent-curated note files that the agent itself appends to.

Honest pros: free, local, versionable in git, zero dependencies, and you can read every byte of what the agent knows. For a single repo on a single machine, this is often enough, and it is the right place to start.

Honest cons: you are the memory system. Files grow stale unless someone curates them, nothing ranks what matters, nothing forgets what stopped being true, and the memory is trapped in one repo. Your agent in Cursor knows nothing about what you told Claude Code, and vice versa.

Fix 2: a self-hosted memory store

The second camp runs a real memory engine on your own infrastructure. Open-source options take different angles: some store facts as vectors with extraction pipelines, some build temporal knowledge graphs where facts carry validity windows, some turn your documents into a queryable graph.

Honest pros: you own the data end to end, you can inspect and tune the engine, and nothing leaves your perimeter. If privacy or compliance is the hard constraint, this camp wins outright.

Honest cons: it is infrastructure. You run it, scale it, tune retrieval quality, and handle upgrades. Memory quality becomes another thing your team maintains, and most stores still serve one application rather than every tool you work in.

Fix 3: a managed memory layer over MCP

The third camp moves memory outside any single tool. Disclosure: I work on Mnemoverse, which sits in this camp, so read this section knowing that.

The idea: a hosted memory service that every MCP client shares. You write a memory in Claude Code, and the same memory is there when you open Cursor, VS Code, or ChatGPT, behind one API key or OAuth login. Nothing to run.

The interesting part is what the memory does between sessions. In Mnemoverse, each write carries an importance score, associations between concepts strengthen as memories are recalled together through a Hebbian rule tuned by a Rescorla-Wagner update, and reporting whether a recalled memory actually helped re-ranks what comes back next time. The goal is memory that improves with use instead of accumulating noise.

Honest cons: the engine is hosted, so you are trusting a vendor with your context, and if your requirement is running everything inside your own perimeter, camp 2 is your answer. There is also no magic about invocation: an agent with memory tools available will not necessarily call them, which brings me to the one tip that applies to every camp.

The tip that matters in all three camps

Whatever memory you add, give the agent a standing instruction to use it. Something as short as "before non-trivial work, check memory; after decisions, corrections, or lessons, save them" in your system prompt or project file changes memory from a tool that exists to a habit that runs. Tool available does not mean tool used. This is the most common reason any memory setup quietly does nothing.

How to choose

Latency-critical and privacy-critical, single repo: start with files, they are genuinely good. Own-your-data with engineering capacity, one main application: self-host a store. Same memory across every AI tool you use, nothing to operate: a managed MCP layer. There is no free lunch, only the corner of the trade-off triangle that fits your work.

If you want to see the cross-tool version in action, Mnemoverse has a free tier (1,000 queries a day, no credit card): write a memory in one tool, recall it in another, and decide for yourself whether the continuity is worth it.

How to Add Persistent Memory to Cursor with MCP (2026)

Edward Izgorodin — Wed, 12 Aug 2026 12:06:00 +0000

Cursor starts every session with amnesia: yesterday's architecture discussion, the migration you agreed not to touch, your preference for pnpm, all gone. There are three real ways to fix that. One, use Cursor's built-in Rules and Memories. Two, run a local-first MCP memory server such as Basic Memory, which keeps everything on your machine. Three, connect a managed memory service over MCP so the same memory follows you across tools. Disclosure up front: I'm Edward, co-founder of Mnemoverse, which is one of those managed services, so I'm biased about option three. The other two are genuinely the right choice for plenty of people, and I'll try to show where.

Option 1: Cursor's native Rules and Memories

Rules are instruction files Cursor loads into the model's context. Project rules live in .cursor/rules, and there are global user rules in settings. They are memory in the "sticky note" sense: static text you write and curate by hand. That is exactly right for stable conventions. "Use pnpm." "Tests mirror the src layout." "Never touch the legacy billing module." Write those once and stop repeating yourself.

Memories is Cursor's automatic layer: the editor generates memories from your sessions so context carries forward. I have to be honest here: availability and behavior vary by version. The feature has moved around and changed between releases, so check what your build actually does before relying on it. When it is present and fits your workflow, it is the zero-setup option.

The limits are structural. Everything stays inside Cursor. Open Claude Code or VS Code and none of it comes with you. Rules do not learn from your sessions, and because Memories varies by version, what it captures is worth auditing rather than assuming.

Option 2: local-first MCP memory servers

MCP (Model Context Protocol) lets you plug external tools into Cursor's agent, and memory servers are a natural fit. A local-first server keeps every byte on your machine.

Basic Memory is a good example: an AGPL-3.0 MCP server that stores your memories as Markdown files on disk. That design decision does a lot of work. Your memory becomes a folder you can grep, edit in any editor, back up, and version in a private repo. Nothing leaves your machine, it works offline, there is no per-query cost, and there is no vendor to trust or outlive.

The tradeoffs are equally clear. It lives on one machine unless you sync it yourself. Retrieval tends to be simpler than in hosted systems, with no learned ranking or feedback loop. And maintenance is yours. But if you operate under compliance constraints, or you simply do not want project context on anyone's server, this option wins and it is not close.

Option 3: managed cross-tool memory (a Mnemoverse walkthrough)

This is what I build, so read this section with that bias in mind. The point of a managed service is not that it is smarter than your local setup. The point is portability plus mechanics you do not have to build yourself. All integrations reach the same account and memory, but authentication differs: the local MCP package and a Custom GPT use an API key; compatible remote MCP clients can use OAuth. That means a fact written in Cursor on Monday can be available in Claude Code on Tuesday.

Setup takes a few minutes:

Step 1. Sign up at console.mnemoverse.com. The free tier is 1,000 queries per day and 10,000 atoms, no credit card.

Step 2. Copy your API key.

Step 3. Add the server to .cursor/mcp.json in your project (or the global ~/.cursor/mcp.json):

   {
     "mcpServers": {
       "mnemoverse": {
         "command": "npx",
         "args": ["-y", "@mnemoverse/mcp-memory-server@latest"],
         "env": {
           "MNEMOVERSE_API_KEY": "mk_live_YOUR_KEY",
           "MNEMOVERSE_API_URL": "https://core.mnemoverse.com/api/v1"
         }
       }
     }
   }

Step 4. Reload MCP servers in Cursor's settings. The local package now exposes nine tools: six core memory tools (memory_write, memory_read, memory_feedback, memory_stats, memory_delete, memory_delete_domain) plus three Beta shared-room tools (create, invite, join). For the current Cursor configuration and tool list, use the editor setup documentation.

If you would rather not manage a key, compatible MCP clients can connect to https://mcp.mnemoverse.com/mcp and sign in through OAuth. The remote connector exposes seven tools: four core tools (write, read, feedback, stats) plus the three Beta shared-room tools. The two deletion tools remain local-package-only.

What actually happens under the hood:

On write, each memory (we call them atoms) gets an importance score at write time, and its concepts form Hebbian associations with the concepts they co-occur with. Association strengths are tuned by a Rescorla-Wagner update, so surprising co-occurrences shift weights more than expected ones. In the background, consolidation merges similar memories into prototypes, with Von Restorff protection so a distinctive memory does not get averaged into the pile.
On recall, memory_read returns atoms ranked using those signals: importance, the learned associations, and past feedback.
On feedback, the agent calls memory_feedback with a score from -1 to 1 when a recalled memory helped or misled it, and that signal re-ranks future recall.

The current package behavior and tool surface are documented in the MCP server reference.

Openness, stated plainly: the MCP server and the Python SDK are MIT licensed, but the engine is hosted and not open source. Your atoms live on our servers. That is the real tradeoff against option two, and memory_delete / memory_delete_domain exist precisely so you stay in control of what is kept.

Which should you pick

If Cursor is your only tool and your needs are conventions plus light session carry-over, use the native features. It is the least machinery, and Rules in particular are underrated.

If privacy, latency, or data ownership dominates, go local-first. Basic Memory if Markdown on disk appeals to you; the pattern matters more than the specific server.

If you work across several tools, managed memory is the category to look at, and I would compare honestly within it. Mem0 offers an Apache-2.0 open-source SDK plus a managed cloud and focuses on extracting facts from conversations. Zep builds on the open-source Graphiti temporal knowledge graph, where facts carry validity windows, a real advantage if you care about what was true when. If your stack is LangGraph, LangMem is native to its Long-term Memory Store and is the path of least resistance. Cognee is the one to evaluate for a self-hosted knowledge graph. Letta gives you a whole agent framework with self-editing memory rather than a bolt-on. Supermemory leans on connectors (Notion, Google Drive, Gmail, S3) if your context lives in documents more than code. Mnemoverse's angle is the cross-tool key plus the learning mechanics above.

On performance claims: vendor-reported numbers are contested, ours included; run your own evals on your own recall tasks before you commit.

FAQ

Does MCP memory slow Cursor down?
Every read or write is a tool call the agent chooses to make, so the cost shows up a few times per session, not per keystroke. A local server answers on localhost; a managed one adds a network hop. If that hop bothers you, that is a point for option two.

Does a memory service see my whole codebase?
No. It only receives what the agent explicitly sends through the memory tools: the memories it writes and the queries it reads with. You can inspect and delete everything: with Mnemoverse via the delete tools, with Basic Memory by deleting a Markdown file. If "only what the tools send" is still too much for your threat model, that is option two's whole argument, and it is a fair one.

Can other tools share the memory Cursor builds?
Native Rules and Memories stay in Cursor. A local MCP server can be mounted by any MCP client on the same machine. A managed service shares across machines and tools; with Mnemoverse, the same account and memory can be reached from Claude Code, Cursor, VS Code, and ChatGPT. The authentication method depends on the client: API key for the local package and Custom GPT action, OAuth for compatible remote MCP clients.

I build one of these options, so weigh my framing accordingly. And if you try any of the three and hit something rough, tell me in the comments. I read them.

Mem0 vs Zep vs Letta vs Cognee vs LangMem vs Mnemoverse: An Honest Map of Agent Memory in 2026

Edward Izgorodin — Mon, 10 Aug 2026 16:42:56 +0000

The short answer up front: there is no best agent memory tool. These six projects solve genuinely different problems that happen to share the word "memory," and picking between them by star count or a leaderboard screenshot is how teams end up running a temporal knowledge graph to store "user prefers dark mode."

I am Edward, co-founder of Mnemoverse. One of the six tools below is mine, so read this whole piece knowing that. I have tried to handle the bias the way I would want a competitor to: my product gets one section among equals, and I tell you when not to pick it.

This is a map, not a ranking. For each tool: what it actually is, the job it wins, and when you should walk past it.

Mem0: extracted facts, open-source SDK, managed option

What it is: an Apache-2.0 open-source memory SDK with a managed cloud on top. Its core move is fact extraction: it distills conversations into discrete facts it can recall in later sessions.

The job it wins: adding a memory layer to a conversational product quickly, with an exit hatch. Because the SDK is open source, you can start on the managed cloud and move toward self-hosting if compliance or cost pushes you there. If "remember what the user told us and recall it next session" describes your need, this is a short path to it.

When not to pick it: when facts change over time and you need to know what was true when. Plain fact extraction flattens time; that job belongs to Zep. And if what you actually want is a structured graph over your documents rather than conversation-derived facts, look at Cognee.

Zep: facts with expiry dates

What it is: a managed memory service built on the open-source Graphiti temporal knowledge graph. The defining feature is that facts carry validity windows. The graph does not just know the customer's plan is Enterprise; it knows when that became true and when it stopped being true. The free tier is 10,000 credits a month.

The job it wins: any domain where state changes and history matters. Support agents, sales agents, anything touching accounts, subscriptions, or relationships. When an agent has to answer "what changed since last quarter," temporal validity is the actual feature, and Zep is honestly the tool I point people to for it.

When not to pick it: strict local-first or data-residency requirements. Graphiti is open source, but the managed service is what Zep sells. Also skip it if your memory needs are simple preferences and session context; a temporal graph is real machinery, and machinery you don't need is just operational surface.

Letta: the agent owns its memory

What it is: an Apache-2.0 agent framework in the MemGPT lineage. Memory here is not a sidecar service. Agents edit their own memory as a first-class behavior, rewriting what they know instead of delegating that to an external lookup.

The job it wins: building agents from scratch where memory management is part of the agent's cognition. If the MemGPT idea feels philosophically right to you, that the agent itself should curate what it remembers, Letta is the direct descendant of that idea and you should build inside it.

When not to pick it: when you already have an agent stack and just want memory bolted on. Letta is a framework, and adopting a framework to get a memory feature is a large trade that most existing codebases will not want to make.

Cognee: your graph, your infra

What it is: an Apache-2.0 framework that builds a knowledge graph on your own infrastructure through an extract-cognify-load pipeline. You feed it data, it constructs the graph, and everything stays inside your walls.

The job it wins: self-hosted knowledge graphs. If your security team's first question is "where does the data live" and the only acceptable answer is "our VPC," Cognee is designed for exactly you. It wins on data control the same way hosted services win on convenience.

When not to pick it: when nobody on the team wants to own a pipeline. Extract-cognify-load is yours to run, monitor, and evolve. If you want an API that just answers, a hosted service will cost you less in engineer-hours.

LangMem: memory that speaks LangGraph natively

What it is: LangChain's memory SDK, native to LangGraph's Long-term Memory Store, with storage in memory or in Postgres.

The job it wins: memory for teams already building on LangGraph. Native means no adapter layer and no impedance mismatch with your graph state, and Postgres persistence keeps operations boring. If your agents are LangGraph agents, LangMem is the honest default, and I say that as someone selling an alternative.

When not to pick it: outside the LangChain ecosystem. Its advantage is integration depth, and away from LangGraph that advantage evaporates. If your agents live in Claude Code, Cursor, or a custom stack, you take on the concepts without the payoff.

Mnemoverse: one memory across your tools (mine, so calibrate)

I build Mnemoverse. Read this section knowing that.

What it is: a hosted persistent-memory API that agents reach over MCP. All integrations reach the same account and memory, but authentication differs: the local MCP package and a Custom GPT action use an API key; compatible remote MCP clients use OAuth. The design bet is cognitive rather than graph-first: memories get an importance score on write; concepts form Hebbian associations tuned by a Rescorla-Wagner update; consolidation merges similar memories into prototypes while Von Restorff protection keeps distinctive ones from being averaged away; and outcome feedback (memory_feedback, a signal from -1 to 1) re-ranks future recall based on whether a memory actually helped. The local MCP package exposes nine tools: six core memory tools (write, read, feedback, stats, delete, and delete-domain) plus three Beta shared-room tools (create, invite, and join). The remote OAuth connector exposes seven: four core tools (write, read, feedback, and stats) plus the same three Beta room tools; the two destructive delete tools remain local-package-only. The MCP server and Python SDK are MIT; the engine is hosted. On the research side, our SLoD paper (arXiv 2603.08965) was accepted at the GRAAI workshop at IEEE WCCI.

The job it wins: continuity across tools. If you code in Cursor at work, run Claude Code at home, ask ChatGPT questions in between, and are tired of every tool relearning your stack and preferences, one shared memory over MCP is the point. The free tier is 1,000 queries a day and 10,000 atoms with no credit card; Pro is $29/month. Sign-up is at console.mnemoverse.com, docs at mnemoverse.com/docs.

When not to pick it: if memory cannot leave your machine, use Basic Memory instead, a local-first AGPL-3.0 MCP server that stores plain Markdown. If you need the engine itself self-hosted, Cognee or self-hosted Mem0 fit; our engine is hosted, and that is a real constraint, not a footnote. If you are deep in LangGraph, LangMem's native integration likely serves you better. And if your core need is temporal validity windows on facts, that is Zep's home turf, not ours.

What's not on this map

Supermemory, if your problem is connectors (Notion, Google Drive, Gmail, S3) and multimodal extraction; note that while there is an open-source repo, the hosted engine is not fully public. Basic Memory, mentioned above, for local-first purists. And Cursor now ships native Rules plus a Memories feature, with availability varying by version, which may be all you need if Cursor is your only tool.

About those benchmark numbers

Every vendor in this space, mine included, has numbers that look impressive. They conflict because everyone benchmarks the task their architecture is shaped for: a temporal-graph system gets evaluated on temporal questions, an extraction system on fact recall, and the datasets, retrieval budgets, and judge models differ from paper to paper. Small harness choices swing results substantially. So treat all of it, including anything I publish, the same way: vendor-reported numbers are contested; run your own evals. Take two candidates from this map, wire each into a week of your actual workload, and measure whether the agent stops asking questions it already asked. Wiring that up costs you a day, and it tells you more than every leaderboard combined.

The map in one paragraph

Facts extracted from conversations with an open-source SDK: Mem0. Facts with expiry dates: Zep. An agent that curates its own context: Letta. A knowledge graph you host yourself: Cognee. Already on LangGraph: LangMem. One memory following you across coding tools: Mnemoverse, and remember who wrote this. None of these is a wrong answer in its own lane. Most of the pain I see comes from picking a tool from someone else's lane because its number was bigger on a benchmark that was never about your problem.

Workflow intelligence ships as a primitive

Edward Izgorodin — Mon, 29 Jun 2026 13:31:06 +0000

This past week, OpenAI shipped Record & Replay for Codex.

Show Codex a workflow once. It turns the demonstration into an inspectable, editable skill that can guide similar work later through Computer Use, browser actions, and installed plugins.

Anthropic moved in the same direction through a different architecture: agent teams, composable skills, and nested subagents in Claude Code.

Two stacks. Same week. Same shift.

From research conversation to shipped primitive

The thing that was a research conversation last month and a procurement decision last week is becoming a shipped primitive.

In the OpenAI version:

record a workflow
extract the repeatable procedure
save it as a callable skill

In the Anthropic version:

describe a skill
load it into specialized agents
compose agents and skills into a larger workflow

One learns from demonstration. The other composes explicit procedures. Both move the unit of work up a level.

Workflow intelligence as a product

You are no longer only wiring tools to prompts. You are encoding how work is actually done and making that procedure callable by agents.

That is workflow intelligence as a product.

And it sharpens the ownership question.

Who owns the recording, the corrections, the exceptions, and the accumulated procedure the agent inherits?

The vendor? Or the builder?

What the Cursor deal may have been pricing

Perhaps that is part of what the Cursor deal was pricing.

Not only the editor. The workflow layer around it.

If memory was part of what last week's procurement conversation was about, workflow intelligence is what this week shipped. The two layers are arriving as products around the same time, and the ownership question follows them both.

Originally posted on LinkedIn on June 22, 2026 — Edward Izgorodin.

Related: Memory is becoming a procurement decision (last week's piece on the same arc).

More research on AI agent memory and workflow intelligence at mnemoverse.com/docs/library. I build Mnemoverse, open-source persistent memory for AI agents.

Memory is becoming a procurement decision

Edward Izgorodin — Mon, 22 Jun 2026 17:44:11 +0000

Last week: $60B for Cursor, where the deeper asset was not just the editor, but workflow memory around engineering teams.

Recently: Anthropic previewed "dreaming" for Managed Agents. Google's Memory Bank in Vertex AI and Agent Engine points in the same direction.

Different architectures. Same shift.

Persistent memory has stopped being only a research conversation

It is becoming a procurement decision.

For builders, this changes one thing.

You no longer get to defer the memory layer choice.

Either you pick a cloud vendor's memory and inherit its abstractions: what state means, what consolidation means, how revision works, and who controls the memory surface.

Or you pick an open layer and keep those architectural decisions inside your own stack.

Both are valid. They produce very different systems.

The uncomfortable question is what gets priced next

Is it only IP, product, and distribution?

Or is it the accumulated understanding of how teams actually get work done with agents?

Not raw user data in the crude sense.

Something more strategic: repeated workflows, corrections, repo context, task patterns, and intent signals transformed into an agent's ability to understand the job.

The vendor or the builder

If memory was part of what the market priced last week, the question now is who controls it.

The vendor.

Or the builder.

Originally posted on LinkedIn on June 19, 2026 — Edward Izgorodin.

Related research on AI agent memory at mnemoverse.com/docs/library. I build Mnemoverse, open-source persistent memory for AI agents.

Agent memory is not a database

Edward Izgorodin — Thu, 18 Jun 2026 20:49:55 +0000

A paper from late May argues that agent memory is not a database. I think it is right.

That sentence is the entire thesis. The rest of this post is what it means.

The four failure modes

Orogat and Mansour name four failure modes you hit when you treat memory like storage:

Unregulated growth — facts pile up indefinitely with no shape control
Missing semantic revision — the system cannot update what a fact means over time, only the row itself
Capacity-driven forgetting — you forget the wrong things first, because storage limits decide for you
Read-only retrieval — retrieval cannot reshape state; reading is decoupled from learning

If you have built a serious agent, all four are familiar. They are not edge cases. They are what happens when the abstraction is wrong.

GEM — four state-level operations

The authors' model, Governed Evolving Memory (GEM), replaces record-level CRUD with four state-level operations:

Ingestion — incorporate a new observation into memory state
Revision — update what existing memory means, not just its contents
Forgetting — explicit, governed reduction of state
Retrieval — read-coupled-to-state, not detached lookup

Notice what is missing. There is no insert. No update. No delete. The operations are about the state of memory, not the rows in it.

The strongest claim

Then they make the strongest claim in the paper:

No record-level system can satisfy the correctness conditions, whatever storage engine sits underneath.

That is the part worth sitting with.

The claim is not that databases are slow. It is that the abstraction is wrong. Correctness lives in how memory state evolves over time, not in any single record.

For anyone building long-running agents that are supposed to remember, this reframes the design question.

Less: "What is the right schema for memory rows?"

More: "What is the right vocabulary for memory state evolution?"

The honest gap

The prototype runs on a property graph, and the authors are honest about the gap: state-level revision and forgetting are expensive to do properly. Native engine work is still ahead.

Worth reading

A short paper. Worth reading if you build for agents that have to remember.

📄 Paper: arxiv.org/abs/2605.26252

Also shared on LinkedIn — Edward Izgorodin, June 11, 2026.

Related research on AI agent memory at mnemoverse.com/docs/library. I build Mnemoverse — open-source persistent memory for AI agents.