Databricks MemCurrent: Agent Memory That Triples Pass Rate With 31% Fewer Tokens

Databricks has published MemCurrent, the persistent memory design behind its new Agent Bricks Memory offering and its Genie data assistant. According to the Databricks blog post MemCurrent: Designing Persistent Memory for Production Agents, published October 20, 2026, memory triples the agent's pass rate on an internal enterprise benchmark (22.3% to 68.4%) while using 31% fewer tokens and running 26% faster than the same agent with no memory. On three public memory benchmarks, it matches putting the full history in the prompt at roughly 12x fewer input tokens.

The most important caveat is up front: the benchmark that produces the "triples" claim was built by Databricks from its own product's conversations. The design ideas are the more durable part, so this guide walks through both.

TL;DR

The problem: more history is not better memory

Databricks starts from a production reality: vibe-coding an agent is easy, but maintaining an enterprise agent is hard, and teams often trade quality against cost and latency. Memory can improve both by carrying context across tasks: user preferences, prior corrections, metric definitions and successful workflows. But "supplying every past interaction is costly and can introduce stale, conflicting, or irrelevant context." The design question is what to retain, how to maintain it and how to measure usefulness.

How MemCurrent is built

Databricks' Figure 1 plots pass rate against tokens per task on the internal benchmark, with MemCurrent on the frontier against Mem0, PropMem and OpenClaw memory.

Databricks lays out three ways to wire memory into an agent and uses all three:

The architecture has two kinds of memory:

• Episodic memory stores raw session traces. It is append-only: a plugin logs each step as the session runs.
• Derived memory stores distilled learnings as files in a structured knowledge base, simulated as a hierarchical file system in a mutable table, with an auto-generated memory.md index at the top describing what each file contains.

Both live in a production database that scales to many users with low latency. Writing to derived memory happens two ways: agent tools (add_memory, update_memory, delete_memory) handle explicit requests such as "never write scripts in the /tmp dir," while the offline dreaming pipeline distills implicit learnings from each new session into the right files and also cleans the store by splitting oversized files, merging duplicates and resolving conflicts. Reading is layered: a plugin injects the memory index at session start so the agent knows what it knows, and two tools, search_memory and fetch_memory, work across both memory types.

How it was evaluated

Databricks used two kinds of tests.

Open benchmarks. LoCoMo, LongMemEval and ConvoMem test whether an agent can recall facts stated earlier in synthetic conversations. Using GPT 5.6 luna as the agent and memory model, with two harnesses (LangGraph and the OpenAI Agents SDK) and three repeats, MemCurrent scored highest among memory backends and stayed on the cost-accuracy frontier. Its 88.1% average matched full context at 87.8% but with about 12x fewer input tokens (8.4K against 103K per question), and on the two benchmarks with the longest histories it beat full context, where dumping everything in the prompt "ends up confusing the agent."

The Internal Memory Benchmark. Databricks started from more than 12,000 (12K+) real Genie sessions, mined 3,000 candidates with memory-worthy signals, and drafted follow-up questions with scoring rubrics. An adversarial judge checked each case against seven criteria, and after manual review the benchmark has 114 test cases, 29 users and 2,233 history sessions. It spans five memory types (profile, preferences, domain knowledge, projects, workflows) across eleven scenarios, and the scoring is by an LLM judge against rubrics. The agent was Claude Opus 4.6 with GPT 5.6 sol as the memory model.

The internal results

Databricks says MemCurrent closes over 80% of the gap between no memory and the gold-injection ceiling, and that compared with no memory it is 1.35x faster and 1.44x cheaper. Mem0, which was also on the frontier on the earlier benchmarks, trails here at 43.9% with higher latency and cost.

What the ablations say

• Memory types. Episodic memory alone reached 35.8%. The agent searched raw history in only about a third of cases, though it passed 60% of those. Derived memory alone reached 66.1%, because the injected index tells the agent what exists. Adding episodic memory gave 68.4%, a small gain that suggests raw traces recover details distillation drops.
• Extraction strategy. Offline dreaming alone scored 63.5%, online tools alone 53.9%, and the combination 66.1% for the derived path. Databricks reads that as a division of labor: dreaming handles background extraction and consolidation, while tools make explicit requests take effect right away.

A green thread looping around three spools in a drawer, illustrating long-term agent memory stored for later sessions

Two examples from Genie

Databricks shares two anonymized cases. In the first, an agent wrote a correct SQL query but never read the saved results and then hallucinated a table. After user feedback it saved a lesson, and the next time it read the results first. In the second, a request for "the top 5 SDP customers" needed 11 tool calls, 8 subagents and nearly six minutes of discovery. The agent saved the steps as a workflow file; a later related question took 2 tool calls, 1 subagent and 41 seconds. These are single cases, chosen by the authors, but they show the kinds of memories worth keeping: corrections and reusable workflows.

How to read the claims

1. "Triples the pass rate" is relative to no memory, on an internal set. The internal benchmark is built from the same product the architecture ships in, which is realistic but not neutral.
2. Different models for different tests. The open-benchmark results use GPT 5.6 luna, the internal ones Claude Opus 4.6 and GPT 5.6 sol, so results across the two are not directly comparable.
3. LLM-judge scoring. Pass rates depend on rubric and judge quality. The adversarial test-case filtering helps, but the judge is still a model.
4. The baselines were run by Databricks. Competing memory systems can be sensitive to configuration.
5. Ceiling matters. Gold injection reaches 78.6%, so even perfect memory retrieval does not solve every task; the rest is the agent's own ability.

What builders can take from it

Even if you never use Databricks, the design is a usable checklist: separate raw traces from distilled notes; give the agent an index of what it knows rather than dumping everything; keep an offline job that merges duplicates and resolves contradictions; let explicit user instructions bypass the delay; and measure memory with tasks where memory feeds actions, not just recall. For other approaches on this blog, see Perplexity's Brain computer memory system, the argument in agents don't need memory, they need documentation, and our guide to always-on persistent agent architecture. Databricks' own earlier coverage here includes managing AI coding costs at scale. A security note: persistent memory is also an attack surface, as in the Claude memory exfiltration case; if agents write their own memory, review what gets stored.

Getting started

Per Databricks, Agent Bricks Memory is built on Lakebase and includes a session store (episodic), a memory store (derived), an automatic dreaming pipeline, tracing and evaluation that shows memory's impact, and a CLI for an end-to-end sample agent in under ten minutes. Genie users already benefit from MemCurrent behind the scenes. Databricks also suggests that because memory is a knowledge base not tied to one agent or model, it could move with users to new agents and might seed shared organizational knowledge, a direction it says it is exploring next.

Bottom line

MemCurrent's main lesson is that memory quality beats memory quantity. The open benchmarks show that a compact store of 8.4K tokens per question can match a 103K-token full-context prompt at 88.1% versus 87.8%, and the internal benchmark shows the gap between no memory (22.3%) and a well-designed memory (68.4%) can be large on enterprise tasks. Those results come from Databricks' own tests, so the practical step for any team is to build a small memory benchmark from its own sessions before committing to an architecture, and to compare against a no-memory baseline and a full-context baseline.

Related reading

• Perplexity Brain computer memory system
• Agents don't need memory, they need documentation
• Always-on persistent agent architecture
• Databricks on managing AI coding costs
• Claude memory exfiltration case
• Official: MemCurrent on the Databricks blog and Databricks agent memory docs

Details are accurate as of October 22, 2026 and come from Databricks. Benchmarks were built and run by Databricks.