MemCurrent: Designing Persistent Memory for Production Agents

MemCurrent: Designing Persistent Memory for Production Agents | Databricks Blog Skip to main content

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 and  Genie . 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. How We Designed Memory There are three ways to wire memory into an agent. As a  plugin (like our earlier work on  MemAlign and  Memory Scaling ), 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 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

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). 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. 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). Results We compare MemCurrent with three...