MemCurrent: Designing Persistent Memory for Production Agents

Quality and Efficiency Are Supposed to Trade Off

AI tools have made it easy to vibe code agents. Building and maintaining an enterprise agent in production, however, remains significantly more challenging. Developers are often forced into a trade-off between quality (getting good answers, especially on long-tail tasks) and efficiency (keeping cost and latency in check at scale). Oftentimes, a technique brings gains in one dimension at the cost of the other.

Memory is a promising way to improve both at the same time. It can help agents carry useful context across tasks: user preferences, prior corrections, metric definitions, successful workflows. In principle this improves accuracy, reduces repeated errors, and avoids unnecessary rediscovery. But more history is not necessarily better memory. Supplying every past interaction is costly and can introduce stale, conflicting, or irrelevant context. The central challenge is deciding what to retain, how to maintain it, and how to measure usefulness.

This post introduces MemCurrent, a persistent memory architecture for production agents, which now powers Databricks' Agent Bricks Memory and Genie. Agents read and write memory as they work, and an offline "dreaming" pipeline consolidates memory to keep it consistent and fresh. On an internal benchmark built from realistic enterprise tasks, MemCurrent triples the agent's pass rate over having no memory, while using 31% fewer tokens and running 26% faster.

How We Designed Memory

There are three ways to wire memory into an agent. As a plugin (like the earlier MemAlign and Memory Scaling work), memory is read and written automatically at fixed points in a session. As tools, the agent decides what and when to read and write. As an offline pipeline, memory is updated in the background on a schedule or trigger, and used in later sessions. Each comes with trade-offs:

Table 1. Three access patterns of memory: plugin, tool, or offline pipeline.

Memory as a ...	Triggered by	Time of computation	Pros	Cons
Plugin	Automatic	Online	Updates take effect immediately Predictable behavior	Higher runtime cost and latency Inflexible (e.g., wasting tokens even when memory isn't needed)
Tool	Agent	Online	Updates take effect immediately Agent has flexibility	Higher runtime cost and latency Quality constrained by agent capability
Pipeline	Schedule or trigger	Offline	Lower runtime cost and latency (async batched)	Updates arrive with a delay

MemCurrent uses all three, each where it fits best.

MemCurrent has two types of memory: episodic memory, which stores raw session traces; and derived memory, which holds the distilled learnings from these traces, stored as files in a structured knowledge base. An auto-generated memory.md index sits at the top, describing the file structure and what each file contains.

Both episodic and derived memory live in a production-grade database that can scale to many users while delivering low-latency responses. Episodic memory is append-only: a plugin logs each step as the session runs. Derived memory is a mutable table simulating a hierarchical file system, and writing happens in two ways. Agent tools (add_memory, update_memory, delete_memory) handle explicit requests like "Never write scripts in the /tmp dir". An offline dreaming pipeline captures the rest, distilling implicit learnings from each new session into the relevant files. It also cleans up the whole store: splitting oversized files, merging duplicates, and resolving conflicts.

Reading works in layers. At session start, a plugin injects the memory index, so the agent knows what it knows before it begins. During the session, the agent has two tools that work across both memory types: search_memory returns the top matches for a query (a step in a past trace, or a line in a memory file), and fetch_memory returns the full entry by identifier (session ID or file path).

How We Evaluated Memory

Benchmarks

We start with three popular open-source benchmarks: LoCoMo, LongMemEval, and ConvoMem. All three test whether an agent can recall facts stated earlier in open-ended synthetic conversations.

In addition, we built an Internal Memory Benchmark from real Genie conversations, where users ask all kinds of questions about their data. As in Figure 3, we started from 12K+ sessions, mined 3K candidates containing memory-worthy signals, and drafted a follow-up question with scoring rubrics. The other sessions from the same user serve as fillers for the test case. An adversarial judge then checked each test case against 7 criteria, such as whether the knowledge is actually present, specific to the user, required to answer, natural, and verifiable. After a final manual review, the benchmark has a total of 114 test cases, with 29 users and 2,233 history sessions.

Here's an example:

Our benchmark differs from existing ones in three ways:

• Enterprise domain. Existing benchmarks are open-ended chats about the lives of simulated personas. Ours is from real work in a data workspace, involving rich enterprise knowledge like table semantics, metric definitions, and workflows.
• Memory feeds actions, not answers. Finding the right string in past conversations is not enough; agents must apply retrieved knowledge to complete multi-step tasks.
• Diversity. Test cases span 5 memory types (profile, preferences, domain knowledge, projects, workflows) crossed with 11 scenarios (direct instruction, changing or outdated facts, multi-session aggregation, memory-independent questions, and more).

Results

We compare MemCurrent with three open-source memory backends, Mem0, PropMem, and OpenClaw memory, using the same underlying LLM.

Open-source benchmarks. We pair each memory backend with a simple question-answering agent, built with two agent harnesses (LangGraph and OpenAI Agents SDK). We also run two baselines: a floor with no memory, and a ceiling with full context, where every past session goes into the agent's context. Across all three benchmarks, MemCurrent scores highest among all memory backends and stays on the cost-accuracy Pareto frontier. On average, MemCurrent (88.1%) performs on par with full context (87.8%) at ~12x fewer input tokens per question (8.4K vs 103K). On the two benchmarks with the longest histories, it even beats full context, where dumping everything into the prompt ends up confusing the agent.

Internal Memory Benchmark. On our benchmark, the gap widens. Here, each memory backend runs inside our internal Genie, the same agent the benchmark sessions came from. The histories are too long to fit in context, so our ceiling is gold injection: injecting only the gold memories into the agent's context. Among all memory backends, MemCurrent has the highest pass rate (68.4%) and the lowest latency (252s) and token usage (418K), closing over 80% of the gap between no memory (22.3%) and gold injection (78.6%). Notably, while Mem0 was also on the frontier on earlier benchmarks, it trails at 43.9% here with higher latency and cost. Compared to no memory, MemCurrent triples the agent's pass rate (22.3% → 68.4%) while making it 1.35x faster and 1.44x cheaper.

MemCurrent in Action

Beyond benchmark numbers, two examples from internal Genie sessions show how MemCurrent helps in practice.

Example 1: Memory stops an occasional hallucination mistake. In Figure 7, a user asked the agent for the top 20 users of Product X over the past two months. The agent wrote a correct SQL query, but never read the actual execution results saved to a file. It still confidently produced a table with hallucinated content. Upon user feedback, the agent saved the lesson to memory. Next time, once the query ran, the agent read the results first and returned the right table. One memory correction kept a one-off slip from becoming a habit.

Example 2: Memory saves computation on related tasks. In Figure 8, a user asked for "the top 5 SDP customers". The agent had to figure everything out from scratch: what "SDP" stands for, which tables held usage data, and how to join and filter them. It took 11 tool calls, 8 subagents, and nearly six minutes. The agent saved these steps as a workflow file in memory, which it could reuse on related tasks. Later, the user asked a different question: how many SDP customers had more than 5K pipeline runs last month. Using the workflow, the agent answered with 2 tool calls and 1 subagent in 41 seconds. The question was new, but the path to the answer wasn't, and memory let the agent skip unnecessary exploration.

What Makes MemCurrent Work

To understand what accounts for MemCurrent's superior performance, we ran ablations on the Internal Memory Benchmark for two design choices: memory types and extraction strategy.

Do we need both memory types? Episodic memory alone helps moderately: 35.8%, up from 22.3% with no memory. The raw history is useful, but the agent only searches it in about a third of test cases, though it passes 60% of those when it does. Derived memory avoids this issue, as the injected memory index at session start gives the agent information about what's available in memory and when to look, lifting pass rate to 66.1%. Adding episodic memory on top gives the best result, at 68.4%. The gain is small, but it suggests raw traces can recover details that distillation drops.

What's a good memory extraction strategy? As shown in Figure 2, two channels extract derived memory: online tools and offline dreaming. When isolated, offline dreaming (63.5%) beats online tools (53.9%) by nearly 10 points. Their combination produces the highest pass rate at 66.1%. That supports a split of duties: dreaming handles background extraction and consolidation, while online tools make explicit requests take effect right away.

Conclusion

Memory is how an agent stops starting from zero. In this post, we introduced MemCurrent, a memory architecture for production agents that combines episodic memory and derived memory, with three access patterns: plugins to log and load context automatically, tools the agent calls on demand, and an offline dreaming pipeline that consolidates memory in the background.

Across all benchmarks we ran, MemCurrent improves quality and efficiency at the same time, the trade-off we set out to break. On open-source benchmarks, it matches full context performance at about 12x fewer input tokens. On our Internal Memory Benchmark, built from real data work, it triples the agent's pass rate over no memory while also making it faster and cheaper.

The ablations point to where the value comes from. Derived memory does most of the work, and episodic memory adds a smaller boost by recovering details that distillation drops. Combining online tools with offline dreaming makes the best extraction strategy: explicit requests take effect immediately, while dreaming distills implicit learnings and consolidates the store in the background.

Beyond the numbers, memory provides a knowledge base that isn't tied to a single agent or LLM. It can move with users to new agents or LLMs, and could seed knowledge shared across their organization, a direction we are exploring next.

Authors: Veronica Lyu, Wenhao Zhan, Sam Havens, Ziyi Yang, Jenny Sun, Qinxin Wang, Nihit Desai, Sirui Sun, Ankit Mathur, Jane Zhang, Yi Liu, Jialu Liu, Michael Bendersky, Matei Zaharia, Xing Chen. We thank Jonathan Li, Rishabh Singh, Andy Zhang, Kenneth Choi, Will Tipton, Cassie Cao, Siddharth Murching, Sue Ann Hong, Pranav Sukumar, Neo Ni, Shanshan Zheng, Chung Wu, and our internal user study participants for their feedback and support throughout this project.

¹ The latency is similar (4-7s/question) across all memory backends, as most questions are answerable within a single hop.

² We find plugin-based memory sufficient for the existing benchmarks. Results from adding tools are strictly dominated and thus omitted.

Source: Databricks Blog, "MemCurrent: Designing Persistent Memory for Production Agents", October 20, 2026.