MemCurrent: Designing Persistent Memory for Production Agents Databricks introduced MemCurrent, a persistent memory architecture for production agents that now powers Agent Bricks Memory and Genie, and which triples an agent's pass rate over having no memory on Databricks' internal enterprise benchmark while using 31% fewer tokens and running 26% faster. MemCurrent combines episodic memory of raw session traces with derived memory distilled into a structured knowledge base, using plugins, agent tools (add_memory, update_memory, delete_memory) and an offline "dreaming" pipeline that consolidates the store by splitting oversized files, merging duplicates and resolving conflicts. Databricks said MemCurrent sits on the Pareto frontier of pass rate versus tokens per task, outperforming Mem0, PropMem and OpenClaw memory on both dimensions. AI tools have made it easy to vibe code agents. Building and maintaining an enterprise agent in production, however, remains significantly more challenging. In particular, developers are often forced to make a trade-off between quality getting good answers, especially on long-tail tasks and efficiency keeping cost and latency in check at scale . Oftentimes, techniques bring gains in one dimension at the cost of another. Memory is a promising way to improve both at the same time. It can help agents carry useful context across tasks, such as user preferences, prior corrections, metric definitions, and successful workflows. In principle, this can improve accuracy, reduce repeated errors, and avoid 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. In this post, we introduce MemCurrent , a persistent memory architecture for production agents, which now powers the new Agent Bricks Memory https://docs.databricks.com/aws/en/agents/custom-agents/stateful-agents and Genie https://docs.databricks.com/aws/en/genie-one/chat . Agents read and write memory as they work, and an offline “dreaming” pipeline consolidates memory to keep it consistent and fresh. On our 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. The rest of this post covers how we designed and evaluated it, and what we learned along the way. Figure 1. Pass rate vs. tokens per task on our Internal Memory Benchmark. MemCurrent is on the Pareto frontier, outperforming Mem0, PropMem, and OpenClaw memory on both dimensions. There are three ways to wire memory into an agent. As a plugin like our earlier work on MemAlign https://www.databricks.com/blog/memalign-building-better-llm-judges-human-feedback-scalable-memory and Memory Scaling https://www.databricks.com/blog/memory-scaling-ai-agents , 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: | Memory as a … | Triggered by | Time of computation | Pros | Cons | | Plugin | Automatic | Online | | | | Tool | Agent | Online | | | | Pipeline | Schedule or trigger | Offline | | | Table 1. Three access patterns of memory: plugin, tool, or offline pipeline. MemCurrent uses all three, each where it fits best. Figure 2. Overview of MemCurrent. MemCurrent has two types of memory: episodic memory , which stores raw session traces; and derived memory , which has 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, where a plugin logs each step as the session runs. Derived memory is a mutable table simulating a hierarchical file system, where 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 . We start with three popular open-source benchmarks: LoCoMo https://arxiv.org/abs/2402.17753 , LongMemEval https://arxiv.org/abs/2410.10813 , and ConvoMem https://arxiv.org/abs/2511.10523 . 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 https://docs.databricks.com/aws/en/genie-one/ 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. Figure 3. How we built our Internal Memory Benchmark. Here's an example: Figure 4. An example test case from our Internal Memory Benchmark. In a past session, the user corrects the agent's choice of table and tells it to exclude background requests. Later, the agent faces a different but related question, and has to find that session among 100+ others and apply what it learned. The output is scored by an LLM judge based on a list of rubrics some memory-dependent, some task-intrinsic . 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 . We compare MemCurrent with three open-source memory backends, Mem0 https://github.com/mem0ai/mem0 , PropMem https://github.com/ProsusAI/MemEval , OpenClaw memory https://docs.openclaw.ai/concepts/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. Figure 5. Cost–accuracy