An agent with no memory repeats on Tuesday the mistake a user corrected on Monday, and an agent that replays every past conversation pays for the history in tokens and gets confused by the stale parts of it. MemCurrent, which Databricks' AI research team published on 20 October 2026, is the memory architecture now behind Agent Bricks Memory and Genie, and on an internal benchmark of 114 test cases drawn from real Genie conversations it took an agent's pass rate from 22.3% with no memory to 68.4%, using 31% fewer tokens and running 26% faster than the same agent with no memory (Databricks blog).
What changes for a team building agents #
The products aren't new. Managed agent memory and sessions have been in beta since 16 September 2026, as the agents chapter covers. What MemCurrent adds is the evidence for how to wire them, and the documentation now maps the research onto the resources one to one: the session store holds episodic memory, the memory store holds derived memory, and a memory pipeline is the dreaming process (agent memory and sessions). We'd read the post as a design guide for those three pieces.
The result we'd act on first is in the ablations. Given only the raw history, the agent searched it in about a third of test cases and passed 60% of those when it did. Injecting an index of derived memory at the start of each session lifted the pass rate to 66.1%, because the agent could see what memory held before it started work. If your agent's memory today is a vector table it queries when it happens to think of it, that's the gap, and a short index of what's stored, loaded into the prompt at session start with search and fetch as tools, is the first change we'd make to it.
The second result settles where writes happen. Offline dreaming alone scored 63.5% against 53.9% for online memory tools alone, and the two together reached 66.1%. We'd keep a save tool for explicit requests ("email me, never call"), because a scheduled pipeline runs about every 24 hours and the interval can't be changed (memory pipelines), and leave everything implicit to the pipeline, which bills as serverless compute plus Foundation Model Serving, off the request path.
Where we'd use it, and where we wouldn't #
We'd use it for agents with returning users whose corrections recur, and for data agents that rediscover the same joins. Databricks' own example is a question that took 11 tool calls, 8 subagents and nearly six minutes, then a related follow-up answered in 41 seconds once the workflow was saved to memory. That's Genie-shaped work, and the benchmark was built from Genie sessions, so we'd treat the headline numbers as a result for that kind of agent and rerun the comparison on our own traces before promising anyone a figure. The benchmark choice moves the ranking too: Mem0, which Databricks reports was also on the cost-accuracy frontier on the earlier benchmarks, trailed at 43.9% on the internal one.
We wouldn't use it as a tenant boundary. The actor_id on an entry separates memories but isn't an access control: any principal that can reach a store can read and write every actor's entries, so strict isolation means a store per tenant (agent memory). The earlier memory store, now deprecated, was a Unity Catalog securable with its own READ MEMORY STORE and WRITE MEMORY STORE privileges (legacy managed memory). The new one grants access per store through its creator or a workspace admin, so a team moving off the legacy store loses those catalog privileges and should plan its tenants as separate stores from the start. A pipeline also fails on a session store with more than about 1,200 actors keyed by UUID. And we'd keep anything an auditor asks about out of free-text memory altogether, for the reasons in our post on securing agent memory.
A lender's support agent, as a scenario #
Take a hypothetical consumer lender whose support agent handles a borrower's hardship request across several conversations over three weeks. The borrower shouldn't have to repeat that they want email, that they've already been told which documents to upload, or that they asked twice about the forbearance timeline. That's memory. The balance, the rate and the hardship decision are live values that belong in the servicing system, read through a governed tool on every request, and the pipeline is designed to skip live values and secrets anyway. We'd narrow it further with instructions:
agentbricks memory pipeline create \
--session-store servicing-agent-sessions \
--memory-store servicing-agent-memory \
--instructions "Keep the borrower's contact preferences and what they have already been told about open requests. Never record balances, rates, payment amounts or eligibility decisions. Organize entries under /preferences/ and /requests/."In the agent, the borrower's identity comes from the verified login and never from the model, which is the rule the documentation states for actor_id:
from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient
client = AgentKitClient(WorkspaceClient())
sessions = client.session_stores.create("servicing-agent-sessions")
memory = client.memory_stores.create("servicing-agent-memory")
# borrower_id from the authenticated session, case_id from the servicing system
session = sessions.add(actor_id=borrower_id, session_id=case_id)
recalled = memory.search(actor_id=borrower_id, query="contact preferences and open requests", limit=10)Where we'd start #
Take an agent already in production and add the session store first, which changes nothing the user sees. Run the pipeline once by hand, since the first run processes each actor's full history, and read what it wrote before any agent reads it. Then evaluate the same held-out conversations with and without the memory index, as the evaluation section describes, and switch the pipeline to scheduled only if the pass rate moves. During the beta you're billed for the Lakebase instance behind the stores and nothing extra for memory or sessions, with pricing subject to change (agent sessions).
Questions people ask #
What is MemCurrent in Databricks? #
MemCurrent is a persistent memory architecture for production agents from Databricks' AI research team, published on 20 October 2026. It combines episodic memory of raw sessions with derived memory distilled into files, written by agent tools and an offline dreaming pipeline, and it powers Agent Bricks Memory and Genie.
Is Databricks agent memory generally available? #
No. Agent memory, agent sessions and memory pipelines are in Beta, according to the Databricks documentation updated on 17 October 2026.
What does Databricks agent memory cost? #
During the preview you pay for the Lakebase instance that stores memory entries and sessions, with no additional charge for agent memory or sessions themselves. Memory pipeline runs bill as serverless general compute for the job and Foundation Model Serving for the model calls.
Does actor_id keep one user's memories private from another? #
It separates them but doesn't secure them. Memory stores are workspace-scoped, and any principal that can reach a store can read and write every entry across all actors, so Databricks recommends a separate memory store for each strict isolation boundary.