Deletion doesn’t come up much when people talk about agent memory. This week, several things in semantic tech all dealt with it. Tiger Data’s pg_vectorsearch treats deletion as a storage problem: deleted rows become tombstones first, and you have to rebuild the index to get the space back. Zep v4 cares about origin: you only know what to delete once you know where a fact came from. OceanBase’s open source PowerContext treats forgetting as deactivation: the memory stops being used, but its content and history stay around for the record. And Bemula, a benchmark from Tsinghua University and Sina Weibo, takes the user’s side and tests whether a system actually forgets after the user says “forget this.” Taken together, deletion in agent memory touches at least four layers: storage, origin, lifecycle and what the user asked for.

The engagement numbers here are a public snapshot from 2026-10-17 and will change. Numbers from papers are the authors’ own experimental results, and vendor claims are reported the way the vendors put them.

This week’s thread: before deleting a memory, answer three questions: where it came from, whether to deactivate or erase it, and whether it still exists somewhere else. On the right, three layers a deleted memory can leave behind; below, where each of this week’s four stories lands

Figure 1 | This week’s thread: remembering is easy. Deleting cleanly is the hard part.

Vector indexes: a deleted row becomes a tombstone first

On October 13, Tiger Data (formerly Timescale) released pg_vectorsearch 0.1.0, an open source vector search extension for PostgreSQL that’s currently in alpha. Its PRISM index groups vectors into compressed partitions instead of building a graph the way HNSW does, can be built right on top of existing pgvector columns, and uses the PostgreSQL license. In Tiger Data’s runs with its own open source benchmark tool, PRISM built an index over 100 million vectors in 1 hour 40 minutes on a machine with 128 GiB of memory, and answered queries in 21 milliseconds at 99% recall. HNSW couldn’t finish building on that machine. The news got 208 points and 52 comments on Hacker News.

Screenshot of the pg_vectorsearch 0.1.0 release notes: deletes work, but the space isn’t reclaimed yet

Figure 2 | The pg_vectorsearch 0.1.0 release notes, captured on 2026-10-17. See reference [1].

My take: Performance is the easiest way to get people’s attention, and Tiger Data led with it too. What caught my eye, though, was how upfront the release notes are about what doesn’t work yet. After a delete, the space isn’t reclaimed right away: VACUUM turns deleted rows into unusable markers (tombstones), scans skip them, and you get the space back with REINDEX. Frequent inserts and updates can make recall drift over time, so you have to rebalance by hand. There’s one more that’s easy to miss: the number of rows an ordered scan can return is capped by a buffer, and anything past the cap gets cut off without any error (I still don’t understand why it was designed that way). Putting all of this in the release notes of a first version is an honest move. It’s also a reminder that for an agent, “deleted” and “can’t be found anymore” aren’t the same thing. There’s an index sitting between them.

Memory platforms: you have to know where every fact came from first

On October 14, Zep released v4 and pitched it as a Context API built for the agents that call it. This version adds Ingestion Traces: with debugging turned on, they record the input, output and errors of the extraction steps Zep traces (on Flex plans and above), so you can explain how a wrong fact got into the system. A few other changes are worth a look:

  • reference_time: records when an event actually happened, as its own marker, separate from when Zep received the data.

  • Hyperedges: a fact that involves three or more entities is stored as one unit.

  • Subgraphs: when an expansion hits a node or edge limit, the response says the result was truncated and which limit it hit.

Screenshot of Zep’s blog: Ingestion Traces explain why each traced extraction step made its decision

Figure 3 | Zep’s blog post introducing v4, captured on 2026-10-17. See reference [2].

My take: To delete a wrong memory, you first need to know where it came from and which extraction steps brought it into the system. Otherwise you can only delete the one memory you can see on the surface, and whatever was derived from it keeps hanging around. This time Zep turned “why does this fact exist” into a record you can query, and I think that matters more than any gain in retrieval speed.

Memory lifecycle: forgetting isn’t the same as erasing

On October 12, OceanBase released v1.3.0 of its open source PowerContext (the repo used to be called powermem). This version stores each fact, preference or decision as its own atomic memory, each with immutable content revisions, exact evidence references and a separate lifecycle. The release notes say that forgetting a memory keeps its content and history, and you can restore it later; only a retired memory can’t be restored directly. It also adds four selectable modes to its memory evidence check, which runs before data is written: disabled, shadow, advisory and enforcing. Once it’s turned on, the default just records its assessment without holding the write, and it doesn’t call any external model.

Screenshot of the PowerContext v1.3.0 release notes: forget a memory while retaining its content and history

Figure 4 | The OceanBase PowerContext v1.3.0 release notes, captured on 2026-10-18. See reference [3].

My take: In PowerContext, forgetting means deactivating: the memory is taken out of use, but its content and history are still there, so you can audit it and trace it back. For project knowledge that makes a lot of sense. Why a decision changed is often worth more than the decision itself. But when a user says “forget my phone number,” they want a different kind of forgetting: “erase.” You need both, and a system has to be clear about which one it’s doing.

Papers: almost no system can delete on request

On October 13, a team of authors mostly from Tsinghua University posted a paper on arXiv that proposes Bemula, a benchmark built specifically to test memory deletion: 50 dialogues spanning multiple sessions, 135 deletion requests of six types and 1,742 test questions, plus a control version of each dialogue with no deletion requests. The authors tested six memory systems, Naive RAG, Mem0, A-MEM, LangMem, LightMem and SimpleMem, on three backbone models. The results aren’t good: no system passed more than 1.5% of deletion requests end to end, and most passed none at all. Either the deleted information could be pulled back out with simple attacks, or far more got deleted than the user asked for.

Screenshot of the arXiv abstract page: no evaluated system passes more than 1.5% of forget requests end to end

Figure 5 | The arXiv abstract page for the Bemula paper, captured on 2026-10-17. See reference [4].

Two other papers ran into the same problem that week, each from a different direction.

  • “Keep Your Receipts” looks at how to clean up a knowledge graph an agent built after one of its sources is retracted. The author reports that existing pipelines only delete the facts extracted directly from that source, and on their corpus the share of contaminated queries only drops from 32.2% to 28.0%.

  • “Beyond Downstream QA” finds that the memory system it tested correctly decides whether a new piece of information should create, update, reinforce or replace an old memory only 20% of the time, and you can’t see that at all in evaluations that only look at QA accuracy.

My take: All three papers are really saying the same thing: deletion is hard because not enough got recorded at write time. Who wrote a memory, what it was based on, which summaries and relations came from it later: if none of that was recorded at write time, deletion is guesswork. Guess too little and you don’t delete it all; guess too much and you delete the wrong things.

The other side of deletion: if the data isn’t complete, say so

Deletion is about removing information that shouldn’t be there anymore. The other kind of problem is data that’s missing or gets cut off. The truncated ordered scans in pg_vectorsearch and the truncated subgraphs in Zep v4, both mentioned above, fall into this category. Zep’s blog puts it this way: the agent won’t mistake an incomplete neighborhood for a complete one.

Cortrix published a post about exactly this on October 14. The scenario: an agent has to fetch data from several places at once, one of them doesn’t respond, and the request still comes back with HTTP 200. The post argues that you should hand the agent the results you did get, and say in the response which part is missing and whether it can be retried, so the agent can decide what to do next without parsing error text. If the caller is running evaluations, reconciliation or batch jobs, or has to report a number like “how many in total,” an incomplete result should be treated as a failure.

Screenshot of the Cortrix blog post: when one of them fails, the request still returns HTTP 200

Figure 6 | The Cortrix blog post on partial success responses, captured on 2026-10-17. See reference [5].

My take: What’s extra has to be deleted cleanly, and what’s missing has to be called out. Both come down to the same requirement: the storage layer has to tell the agent the truth about its own state. The agent can’t guess on the storage layer’s behalf what it missed or what it kept.

Other semantic tech news from around the world

  • On October 16, InfiniFlow released RAGFlow v1.0.0-rc2. Chat gets a new Agentic mode that replaces the old four thinking levels, the 12 built-in document parsers were unified with the Pipeline parsers, and there’s an arm64 image. [6]
  • Haystack 3.4 (October 15) adds an experimental way to compact context: old tool results aren’t dropped or summarized anymore. They’re written to external storage with a reference left in place, and the agent reads them back when it needs them. [7]
  • On October 15, Weaviate disclosed a medium severity permissions issue: nearObject only checked permissions on the collection being searched, not on the collection the referenced object lives in, and the distances it returned were enough to reconstruct protected vectors. The fix shipped in v1.39.3 on September 7, so v1.39.3 and later aren’t affected. [8]
  • Zhipu’s GLM-Legal (October 12) got 674 points on HN. It stresses that a legal agent has to keep an unbroken chain between facts, statutes and conclusions, and its examples back their points with the source documents and the specific statute sections. [9]

My read on this week

My overall take: For the past year, agent memory has been about remembering more and finding things more accurately. Lately, a few vendors and researchers have started thinking about the other side: deletion. Before you delete a memory, you have to answer three questions: where it came from, whether you’re deactivating it or erasing it, and whether the index, the summaries or the graph already hold something derived from it. The answers to all three have to be recorded at write time, or whenever something gets derived from it.

A question for readers

If a user asked your agent to delete a memory right now, could you say how many places it left traces in? Raw content, vectors, summaries, graph, logs: which of those can you delete, and which do you honestly not know about?

References