[1/2] MemCurrent: What an Agent Carries Over from the Last Session (Series #Agent)

In October Databricks described MemCurrent, a memory system that lets an agent draw on earlier sessions. In Genie, where users ask questions about their data, that experience might be a correction to how a metric is calculated, knowing which table to use, or a proven way to join several tables.

MemCurrent has two layers. One holds raw session logs. The other holds extracted notes with definitions, corrections, and methods that worked. At startup, a plugin shows the agent the memory.md index and automatically logs the session as it works. The agent can search both layers itself and record explicit corrections right away. In the background, a separate process the authors call dreaming extracts lessons from sessions, merges duplicates, and resolves contradictions. The piece connects with Anthropic’s article on dreaming, which I wrote about earlier.

On the public LoCoMo, LongMemEval, and ConvoMem benchmarks, the authors tested how the agent answered questions about past conversations. With MemCurrent, its answers were about as accurate on average as with the full history in context, while using about 8.4 thousand input tokens per question instead of 103 thousand. They made their own test for Genie. It asks the agent to do things such as remember an earlier correction to a metric and apply it in SQL for a new report. From 12 000+ sessions, the authors identified about 3 000 candidates and, after checks, arrived at 114 tasks based on the histories of 29 users.

According to Databricks, Genie’s pass rate on this set rose from 22.3% without memory to 68.4% with MemCurrent. Average time fell from 340 to 252 seconds, and token use by 31%. In one example, after a user’s correction, the agent remembered to open the SQL results file before answering. In another, it spent nearly six minutes figuring out where data about customers of the SDP product lived and how to join it. When a new question about SDP customers arrived, the agent retrieved the saved steps and finished in 41 seconds.

The authors also switched off components one by one. The log alone got 35.8%, the notes and their index got 66.1%, and the two layers together got 68.4%. In a separate experiment about how the notes were populated, background processing got 63.5%, while writing only during the session got 53.9%.

Now to my margin notes

Next to Fig. 2, I wrote down three ways to connect memory: the plugin, tools, and background processing. I like that one diagram shows which work has to happen inside the session and what can wait. The paper’s two examples make the reason clear. Sometimes experience restores a missed step. Sometimes it gives you a shorter route. In the customer example, the answer had to be calculated again, but the agent already knew the data schema.

“The internal benchmark results are excellent,” I wrote. Next to the selection funnel I had a different note: “the sample shrinks quickly.” The authors deliberately looked for tasks where past experience could help. To understand the average gain on an ordinary stream of queries, you’d also need to know how often such tasks occur. Next to the public tests I noted GPT‑5.6 luna. I’d like to repeat the comparison on the same tasks with another model and see whether the lead holds.

I especially liked the ablations. They show that notes with their index account for most of the gain. I’d like one more run here. Keep the same notes and search available to the agent, remove only the index, and see how often it remembers on its own that it has somewhere to look.

#AI #Agents #Architecture #Data #Evals