Databricks MemCurrent: Agent Memory That Triples Pass Rates Databricks released Agent Memory in beta this month, built on an architecture called MemCurrent that raises agent task completion from 22.3% without memory to 68.4% with it on a Databricks internal benchmark of 114 tasks drawn from 2,233 real enterprise sessions across 29 users. MemCurrent splits memory into an append-only episodic log of raw session traces and a derived knowledge base of distilled facts, with an asynchronous "dreaming" pipeline that runs after each session to extract implicit learnings, split oversized files, merge duplicates and resolve contradictions. Databricks says MemCurrent already powers Genie and is available to developers through the Agent Bricks CLI, though the company acknowledges the benchmark is internal and may not translate outside its own environment. Databricks shipped Agent Memory in beta this month, and they attached a number to the launch that’s hard to ignore: agents without memory complete 22.3% of enterprise tasks; agents with MemCurrent complete 68.4%. If those numbers hold outside a Databricks-controlled benchmark, that’s the gap between a proof of concept and a production system worth running. The architecture behind that claim is called MemCurrent, it already powers Genie, and developers can start using it today via the Agent Bricks CLI https://www.databricks.com/blog/introducing-agent-memory-databricks . Why Agents Keep Failing in Production The LLM statelessness problem is not new, but it’s still the most common reason agents stay demos. Every session starts from a blank context window. The agent doesn’t know it helped this user last Tuesday, doesn’t remember that the /tmp directory is off-limits, and has no idea the workflow it’s supposed to follow changed three weeks ago. Databricks cites a figure from the field: 72% of enterprise AI failures trace directly to context loss and session amnesia in multi-step workflows. That’s consistent with what most teams building production agents report. The naive fix — stuff the entire conversation history into every prompt — fails at scale. A full-context approach consumes roughly 26,000 tokens per query. Past a certain history length, accuracy actually drops as the context grows; the model loses the signal in the noise. You need selective memory, not unlimited memory. How MemCurrent Works: Two Layers MemCurrent stores memory in two layers with distinct roles: - Episodic memory is an append-only log of raw session traces — exactly what happened, step by step. It’s the full record. - Derived memory is a structured knowledge base of distilled facts and preferences extracted from those traces. An auto-generated memory.md index sits at the top, describing what each file contains. The analogy that holds up: episodic memory is the raw notes from every meeting. Derived memory is the onboarding handbook you’d hand to a new hire — only the things that actually matter, organized so they’re findable. Most DIY implementations get one layer or the other. Episodic-only drowns the agent in noise. Derived-only loses the audit trail. The Dreaming Pipeline Is the Real Differentiator Agents can write to derived memory explicitly during a session — calling add memory , update memory , or delete memory tools when they encounter something worth remembering. But that only captures what the agent knows to flag. Implicit patterns — the kind of thing a good employee learns without being told — get missed. That’s what the dreaming pipeline handles. It’s an async background process that runs after each session completes. It extracts implicit learnings from session traces, splits oversized memory files, merges duplicate facts, and resolves contradictions. You don’t trigger it manually; it runs on a schedule. Databricks named it after sleep memory consolidation in humans, and the analogy is apt: the agent works during the day and learns at night. This is what Mem0 and Zep don’t automate https://atlan.com/know/best-ai-agent-memory-frameworks-2026/ . Both require you to build your own memory maintenance logic, which is where most DIY implementations quietly degrade over time — stale facts pile up and retrieval quality falls off. About That Benchmark The 22.3% → 68.4% improvement comes from a Databricks internal benchmark https://www.databricks.com/blog/memcurrent-designing-persistent-memory-production-agents : 114 tasks drawn from 2,233 real enterprise sessions with 29 users. It’s a real dataset, not synthetic data, and the test design is reasonable — memory feeds multi-step actions, not just fact retrieval, which is a fairer measure of real agent usefulness. That said, it’s internal. The tasks are enterprise workflows inside a Databricks environment, meaning the improvement may not translate directly to your stack. Treat the number as directional, not definitive. The problem it’s solving is real enough that a 2-3x improvement is plausible even if your actual numbers differ. Getting Started Agent Memory is available in beta on Agent Bricks. The fastest path in is via the CLI: pip install agentbricks agentbricks init agentbricks sessions bind my-agent-sessions agentbricks memory bind my-agent-memory agentbricks deploy To run a memory pipeline that distills session history into long-term memory: agentbricks memory pipeline create \ --session-store my-agent-sessions \ --memory-store my-agent-memory \ --model system.ai.claude-sonnet-5 agentbricks memory pipeline run