Once a conversation ends, the scattered records don’t turn into long term memory by themselves. Somebody has to distill them, merge duplicates and settle conflicts. That’s memory consolidation, and it’s been happening in the background all along, but people rarely talk about it on its own. This week, several things in semantic tech put that step right in front of us, and they nearly all reached for the same metaphor: dreaming, Dream, sleep.

So memory consolidation has to answer at least three questions first: when to consolidate, who signs off, and whether the originals stay. Databricks consolidates automatically with an offline “dreaming” pipeline. OceanBase’s open source PowerContext has “Dream” too, but every revision needs a person to approve it before it takes effect. EverMind’s open source EverOS lets extraction run in a background queue and insists that the original Markdown is the only source of truth. And two papers sit at opposite ends: one deletes the raw records as soon as it’s done consolidating, and the other finds that naive RAG, which just retrieves from the raw records, often beats complex memory systems.

The numbers here are public information as read on 2026-10-24 and will change. Numbers from papers and vendor reports are their own experimental results, reported the way they put them.

This week’s thread: a memory goes from raw session records to long term memory with a background consolidation step in between. The core box holds the three questions consolidation has to answer: when to consolidate, who signs off, whether the originals stay. Below, where each of this week’s four stories lands

Figure 1 | This week’s thread: memory starts dreaming in the background.

Memory platforms: Databricks lets memory dream in the background

On October 20, Databricks released Agent Memory. It’s part of Agent Bricks, its agent development platform, and it’s currently in Beta. Memories live in Lakebase (Databricks’ serverless Postgres), deployed in the customer’s own workspace. Developers can read, export and delete the entries an agent saves for each user, and can tell the consolidation pipeline what to keep and what to drop with a single instruction.

The design behind it is called MemCurrent, published the same day by the Databricks AI Research team, with Matei Zaharia among the authors. It splits memory into two kinds: raw session records are append only and never modified, and distilled memories are stored as a mutable table that simulates a hierarchical file system. When a user explicitly asks for something, the agent writes it right away with a tool call. Everything else goes to an offline “dreaming” pipeline, which distills implicit lessons from new sessions and tidies up the whole store at the same time: splitting files that got too big, merging duplicates and settling conflicts.

On an internal benchmark built from its own Genie conversations, Databricks reports a 68.4% pass rate for MemCurrent, about three times the rate with no memory and higher than Mem0. In its ablation study, offline dreaming contributes more than online tools.

Screenshot of Databricks’ MemCurrent blog post: the offline dreaming pipeline also reorganizes the whole store, splitting oversized files, merging duplicates and resolving conflicts

Figure 2 | Databricks’ blog post introducing MemCurrent, captured on 2026-10-24. See reference [1].

My take: what I want to remember from this release is the split, not the 3x pass rate. What the user says out loud gets written right away. What they don’t say gets handed to the background to slowly “dream” over. It’s a bit like a database that writes the log first and lets a background job merge things later (compaction): append first, tidy up later. There’s also a line in the ablation study that’s worth chewing on: the raw records are there to recover details that got lost during distillation. In other words, Databricks’ own ablation suggests that distilled memories can lose details.

Memory lifecycle: PowerContext’s “Dream” only takes effect when a person says yes

On October 19, OceanBase released v1.4.0 of its open source PowerContext. This version adds “Dream”: a person explicitly kicks off a review, using a task result, an explicit correction or usage feedback as the occasion. The system then proposes revisions to atomic memories, Profiles, Topic Memory, Handoffs, Prompt configs and tags, and every proposal goes through the Candidate review flow. The release notes say that approval checks the exact candidate version and the current target before publishing the change, and that generating proposals doesn’t approve them, run tasks or install Skills. A few other changes are worth a look:

  • Working Notes: record current findings, abandoned approaches and open questions. You can give them an expiry time; once expired they’re no longer used, but the raw record is kept for auditing. Notes never get promoted to long term knowledge on their own.

  • Revision history: browse and compare past versions in the Dashboard, and restore old content as a new revision that records the source version, the reason and who did it.

Screenshot of the PowerContext v1.4.0 release notes: generating a proposal doesn’t approve it, run a task or install a Skill

Figure 3 | The OceanBase PowerContext v1.4.0 release notes, captured on 2026-10-24. See reference [2].

My take: Both call it dreaming, but Databricks and PowerContext went two different ways. The first lets the pipeline consolidate on its own, and users tell it what to keep through instructions. The second has the system only make suggestions, and a person decides whether to apply them. Put simply: for a personal assistant, automatic consolidation is probably good enough. For project knowledge that lots of people will cite, I’d rather have a person confirm every revision and be able to go back to the previous version.

Writes: EverOS accepts first, extracts later, and the original is the source of truth

On October 21, EverMind released 1.5.0 of EverOS (formerly EverMemOS), its open source memory system. In this version the /add endpoint supports async_mode: the request is written to a durable SQLite queue and gets a 202 back within milliseconds, and a background worker runs extraction in session order. The release notes point out that failed batches aren’t retried automatically by default, because the extraction pipeline isn’t atomic and running it again isn’t clean. Two other changes are both about speaking up when something goes wrong:

  • The width of the vector column now comes from config. It used to be hardcoded at 1024, so switching to a model with a different dimension meant either every write failed or vectors got silently truncated. Now, if the index doesn’t match the configured model at startup, it refuses to start.

  • If you deleted the index directory, the system used to keep reporting that everything was healthy while search found nothing. Now it checks the row count of every table at startup and reports honestly when the index has been wiped. You recover by rebuilding the index, and the original Markdown is the only source of truth and is never modified.

Screenshot of the EverOS 1.5.0 release notes: recover with cascade rebuild; Markdown is the source of truth and is never modified

Figure 4 | The EverOS 1.5.0 release notes, captured on 2026-10-24. See reference [3].

My take: remember “Markdown is the source of truth, and if the index breaks you can rebuild from the original.” As long as the original is still there, memory consolidation has a way back when it gets something wrong. Moving extraction to the background makes writes fast. The price is a time gap between “written” and “remembered,” plus a queue that can fail. EverOS handles that a lot like a database would: persist to disk first, make the state queryable, and don’t pretend a failure succeeded.

Papers: after consolidating, do you keep the raw records?

The same week, two papers answered that question from opposite directions.

  • “Let Them Sleep” proposes RSPM: every so often the agent “sleeps,” clusters its recent failures into a few groups, distills each group into a short rule, and then deletes the raw records it just learned from. Rules that don’t get reinforced decay. The authors report gains of 9.1, 11.9 and 7.6 points on three kinds of tests: a SWE-bench simulation, temporal consistency across 12 dialogue benchmarks, and LoCoMo-10. They also report that retry loops dropped by about 93%, and stored entries by about 30%.

  • “Is Complex Agentic Memory Always Needed?” tests a naive baseline called Raw-RAG: dense retrieval plus reranking directly over the raw conversation history. The authors report that it came first in six of seven settings across LoCoMo, LongMemEval, MEME and MemoryAgentBench. They also report that even reading the full store after a complex memory system has transformed it was still less accurate than reading the raw evidence directly.

Screenshot of the arXiv abstract page: the agent sleeps, clusters failures into rules, then deletes the raw records

Figure 5 | The arXiv abstract page for “Let Them Sleep,” captured on 2026-10-24. See reference [4].

My take: The two papers look like they reach opposite conclusions, but they’re two sides of the same thing. Sleep, distill and delete the originals, and you get a smaller, cleaner store. Keep the originals, and the details lost in distillation can still be recovered. Databricks’ ablation study lands on the second side too. (I still can’t quite figure out why RSPM is willing to delete the originals right after distilling. Maybe failure records in long tasks really are that noisy.) For me, raw records are more like a database log: you can archive them and compress them, but you shouldn’t throw them away the moment consolidation is done.

Other semantic tech news from around the world

  • On October 22, Pinecone added integrated embedding to its Documents API: you assign an embedding model to a string field in the index schema, Pinecone vectorizes it automatically at write time and at query time, and the same field also supports full text search. Its blog post the same day was titled “When vectors became an implementation detail.” [5]
  • On October 22, Tiger Data looked back at three memory systems it had built: a list of facts, a general knowledge graph and a tree structure. Its conclusion is that the most expressive one wasn’t the most useful. With the graph approach, an agent sometimes took dozens of turns to write one session summary into memory; with the tree approach, one tool call was usually enough. [6]
  • Volcano Engine’s OpenViking shipped v0.5.1 and v0.5.2 on October 19 and 23. Memory extraction triggered by resources now returns an accepted status as soon as it’s queued, and starting with v0.5.2, Working Memory is off by default, while sessions still archive raw messages and extract long term memory. [7]
  • The paper “Compaction Laundering” looks at agents that compact their context by flattening the conversation into plain text. After that, each message is marked only by a text label like [User]:, and anything the agent reads can fake one. So a forged “the user has approved” line from an attacker gets written into the summary as a real instruction. The author reports success rates of 87% to 100% on five harnesses that work this way, and 0% on four that keep message roles. Compaction done this way loses more than details. It also loses track of who actually said what. [8]

My read on this week

My overall take: Over the past year, agent memory competed on extracting accurately at write time and finding things at query time. Lately, a few vendors and researchers have started putting their effort into the stretch between the two: memory consolidation. That means memory systems now need to answer three questions first: when to consolidate, who signs off on the result, and whether the raw records are still there afterward.

A question for readers

Who’s consolidating your agent’s memory right now? If it gets one memory wrong, can you still find what that memory originally looked like?

References