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.
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.mdindex 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. 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: 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 <pipeline-id>
Both stores run on Lakebase, Databricks’ production database layer. The important caveat: MemCurrent is managed infrastructure on Databricks, not an open-source library you can drop into any stack. If you’re already on Databricks, this is the clear path. If you’re not, Mem0 and Zep remain more portable options.
Where MemCurrent Fits #
The agent memory landscape in 2026 has options across the managed/self-hosted and open/proprietary axes. Zep leads on accuracy for temporal reasoning (63.8% on LongMemEval). Mem0 has the largest community and the easiest setup. Letta is the most flexible open-source option. MemCurrent’s advantage is the managed dreaming pipeline plus tight integration with Databricks infrastructure — if that’s your environment, you’re not building the maintenance layer yourself.
The broader pattern is worth noting: memory is becoming infrastructure, not a library you bolt on. MemCurrent, Mem0’s managed tier, and Zep’s hosted option are all moving in the same direction. The agents that will matter in enterprise in a year are the ones that accumulate institutional knowledge instead of resetting to zero every time someone opens a new session.