Skip to content

DATABRICKS 2026-10-20

Read original ↗

MemCurrent: Designing Persistent Memory for Production Agents

Summary

Databricks introduces MemCurrent, a persistent-memory architecture for production AI agents that now powers Agent Bricks Memory and Genie. Its central thesis is that more history is not better memory — supplying every past interaction is costly and injects stale, conflicting, or irrelevant context, so the real problem is deciding what to retain, how to maintain it, and how to measure usefulness. MemCurrent splits memory into episodic memory (raw append-only session traces) and derived memory (distilled learnings stored as files in a structured, memory.md-indexed knowledge base), and wires memory into the agent through all three access patterns — a plugin (automatic read/write at fixed points), tools (agent-driven add/update/delete/search/fetch), and an offline "dreaming" pipeline that consolidates memory in the background (split oversized files, merge duplicates, resolve conflicts, distill implicit learnings). On an internal benchmark built from real Genie sessions, MemCurrent triples the agent's pass rate vs no memory (22.3% → 68.4%) while using 31% fewer tokens and running 26% faster, and sits on the cost–accuracy Pareto frontier against Mem0, PropMem, and OpenClaw memory.

How memory is wired in — three access patterns

The post's first design axis is where memory read/write happens. MemCurrent uses all three patterns, each where it fits best (Source: this page):

Pattern Triggered by When Pros Cons
Plugin Automatic Online Updates take effect immediately; predictable Higher runtime cost/latency; inflexible (spends tokens even when memory isn't needed)
Tool Agent Online Immediate; agent has flexibility Higher runtime cost/latency; quality bounded by agent capability
Pipeline Schedule/trigger Offline Lower runtime cost/latency (async, batched) Updates arrive with a delay
  • Plugin injects the memory index at session start (so the agent "knows what it knows before it begins") and logs each step to episodic memory as the session runs.
  • Tools give the agent add_memory / update_memory / delete_memory for explicit requests ("Never write scripts in the /tmp dir") plus search_memory (top matches for a query — a past trace step or a line in a memory file) and fetch_memory (full entry by identifier — session ID or file path).
  • Pipeline — the offline "dreaming" pipeline — distills implicit learnings from each new session into the right file and does whole-store maintenance (split oversized files, merge duplicates, resolve conflicts).

The two memory types

  • Episodic memory — raw session traces, append-only, written by a plugin that logs each step as the session runs. "The agent only searches it in about a third of test cases, though it passes 60% of those when it does."
  • Derived memory — distilled learnings stored as files in a structured knowledge base simulating a hierarchical file system (a mutable table). An auto-generated memory.md index sits at the top describing the file structure and what each file contains. Written two ways: agent tools (explicit) + the offline dreaming pipeline (implicit) (Source: this page).

Both types live in a production-grade database that scales to many users at low latency — Agent Bricks ships this as a session store (episodic) + a memory store (derived) powered by Lakebase.

Key takeaways

  • "More history is not better memory." The central problem statement: supplying every past interaction is costly and introduces stale, conflicting, or irrelevant context; memory's value is in deciding what to retain, maintain, and measure — not in dumping the full log into the prompt (Source: this page).
  • Derived memory does most of the work; episodic adds a smaller boost. Ablation: no memory 22.3% → episodic-only 35.8% → derived-only 66.1% → both 68.4%. The injected memory index at session start is what makes derived memory strong — it tells the agent what's available and when to look — while episodic recovers details distillation drops (Source: this page).
  • Offline "dreaming" beats online tools; combine both. Extraction-strategy ablation: offline dreaming alone 63.5% vs online tools alone 53.9%; combined 66.1%. The split of duties: dreaming handles background extraction + consolidation; online tools make explicit requests take effect immediately. This is an offline-projected read model applied to agent memory — the authoritative raw log (episodic) feeds a background pipeline that materializes the fast-to-read derived store (Source: this page).
  • MemCurrent ≈ full context at ~12× fewer tokens. On three open-source benchmarks (LoCoMo, LongMemEval, ConvoMem) MemCurrent averages 88.1% vs full-context 87.8% at 8.4K vs 103K input tokens/question; on the two longest-history benchmarks it beats full context, where "dumping everything into the prompt ends up confusing the agent" — a concrete instance of context-window pollution degrading quality (Source: this page).
  • Internal benchmark: triples pass rate, faster and cheaper. On the Genie Internal Memory Benchmark, MemCurrent 68.4% pass (vs 22.3% no-memory, 78.6% gold-injection ceiling) — closing >80% of the gap — at the lowest latency (252s) and token usage (418K) among backends. Mem0 trails at 43.9% with higher latency/cost despite being frontier on the open-source benchmarks (Source: this page).
  • Memory feeds actions, not just answers. The benchmark's design point: finding the right string in past conversations is not enough — the agent must apply retrieved knowledge to complete multi-step tasks. Worked examples: a saved correction stops a repeated hallucination (agent writes a correct SQL query but hallucinates results without reading them; one memory correction fixes the habit); a saved workflow file turns a from-scratch 6-minute / 11-tool-call / 8-subagent task into 41 seconds / 2 tool calls / 1 subagent on a related question (Source: this page).

Benchmark construction (an evaluation-design datum)

Databricks built the Internal Memory Benchmark from real Genie sessions because existing benchmarks (LoCoMo, LongMemEval, ConvoMem) only test fact-recall in open-ended synthetic chats — not enterprise action completion. Construction pipeline: 12K+ sessions → mine 3K candidates with memory-worthy signals → draft a follow-up question + scoring rubrics → adversarial LLM judge checks each case against 7 criteria (knowledge actually present, specific to the user, required to answer, natural, verifiable, …) → final manual review → 114 test cases, 29 users, 2,233 history sessions, spanning 5 memory types × 11 scenarios. Scored by an LLM judge against memory-dependent and task-intrinsic rubrics. Three stated differences from existing benchmarks: enterprise domain, memory feeds actions not answers, and diversity (Source: this page). This is a clean instance of benchmark-construction methodology — an adversarial judge is used specifically to screen out cases where the "memory" isn't actually load-bearing.

Systems / concepts / patterns extracted

  • Systems: MemCurrent (primary subject — the memory architecture); Lakebase (the production-grade DB powering the session store + memory store); Genie (now powered by MemCurrent; the benchmark's source agent); Agent Bricks Memory (the Databricks product offering MemCurrent — session store + memory store + dreaming pipeline + tracing/eval + a <10-min CLI, powered by Lakebase; recorded as databricks-agent-bricks slug, no page). Comparison backends Mem0, PropMem, OpenClaw memory named plain-text (no page). Benchmarks LoCoMo / LongMemEval / ConvoMem named plain-text. Agent/memory models in the eval (GPT-5.6 luna/sol, Claude Opus 4.6) named plain-text.
  • Concepts: agent memory (the core concept — the episodic/derived split + three access patterns are the fullest treatment on the wiki); context engineering (memory as a token-budget lever — the "12× fewer tokens, and beats full-context on long histories" result); benchmark methodology (adversarial-judge-screened benchmark construction; action-vs- recall workload shape); LLM-as-judge (adversarial construction judge + rubric scoring judge); token overhead (memory reduces token cost vs full context); memory-worthy-signal mining and memory-index-at-session-start recorded as tags + prose.
  • Patterns: async-projected read model — episodic (append-only authoritative log) → offline dreaming pipeline → derived memory (materialized read-optimized view) is a textbook instance. Episodic-vs-derived memory split and offline memory consolidation / "dreaming" recorded as tags + prose on the agent-memory concept page (single-source MemCurrent-specific vocabulary — tag, don't mint).

Operational numbers / specifics

  • Internal benchmark: no memory 22.3% → MemCurrent 68.4% → gold ceiling 78.6% pass rate; MemCurrent closes >80% of the gap. MemCurrent lowest latency 252s and token usage 418K among backends; Mem0 43.9%. Headline: 3× pass rate, 1.35× faster, 1.44× cheaper vs no memory. (Claude Opus 4.6 agent + GPT-5.6 sol memory model, 3 repeats.)
  • Open-source benchmarks: MemCurrent avg 88.1% ≈ full context 87.8% at 8.4K vs 103K input tokens/question (~12× fewer); beats full context on the two longest-history benchmarks. (GPT-5.6 luna agent+memory model, plugin mode, mean over LangGraph + OpenAI Agents SDK harnesses × 3.)
  • Ablations: memory types — 22.3 / 35.8 / 66.1 / 68.4% (none / episodic / derived / both); extraction — online tools 53.9%, offline dreaming 63.5%, combined 66.1%.
  • Benchmark build: 12K+ sessions → 3K candidates → 114 test cases, 29 users, 2,233 history sessions; 7 adversarial-judge criteria; 5 memory types × 11 scenarios.
  • Workflow-reuse example: 6 min / 11 tool calls / 8 subagents → 41 s / 2 tool calls / 1 subagent.
  • Agent Bricks Memory CLI: end-to-end sample agent in <10 minutes.

Caveats

  • Tier-3 vendor post. All headline numbers are Databricks' own — the internal benchmark, its gold ceiling, and the backend comparison are constructed and scored by Databricks (LLM judges on Databricks rubrics), not independently reproduced. The open-source-benchmark result that MemCurrent matches full context is the most externally-checkable claim; the Mem0 reversal (frontier on open-source, 43.9% internal) is on Databricks' own action-completion benchmark.
  • Model names are forward/placeholder-dated (GPT-5.6 luna/sol, Opus 4.6) — the durable content is the architecture (episodic/derived split, three access patterns, dreaming consolidation), not the specific models.
  • Mechanism depth is partial. The dreaming pipeline's distillation/merge/ conflict-resolution logic, the memory-index generation, the search/fetch retrieval ranking, and the Lakebase schema are described at capability level, not implementation level.
  • Latency parity caveat: the post notes open-source-benchmark latency is similar (4–7s/question) across backends because most questions are single-hop; the latency/token wins are most pronounced on the long-history internal benchmark.

Source

Last updated · 854 distilled / 2,448 read