Databricks Agent Memory: How It Works and What It Costs
Databricks announced Agent Memory on October 20, 2026, as a Beta part of Agent Bricks, its platform for building agents. It gives agents you deploy on Databricks a session store and a long-term memory store. A pipeline turns the first into the second. Both live in Lakebase, Databricks' serverless Postgres. By the end you will know how Databricks Agent Memory works and what the Beta costs. You will also know which limits to check before real users arrive.
What is Databricks Agent Memory, in one sentence?
Databricks Agent Memory is a Beta service in Agent Bricks that distills an agent's recorded conversations into per-user long-term memory in Lakebase, which later sessions search.
Databricks calls it a production implementation of MemCurrent, a memory design from its research team. The same post says this infrastructure already runs memory for Genie, the company's natural-language tool for business users. The research behind it is a MemCurrent post from Databricks AI Research, published the same day. We found no separate paper for MemCurrent.
How does Agent Memory differ from sessions and full chat history?
Databricks ships sessions and memory as separate stores. The usual alternative is to put the whole history back into the prompt. The MemCurrent post tests that as its "full context" baseline.
| Agent sessions | Agent memory | Full history in context | |
|---|---|---|---|
| What it holds | Ordered items for one interaction: messages, tool calls, results | Durable facts, preferences and procedures per user | Every past message |
| Who writes it | The agent appends each turn | Memory tools during a run, or the pipeline afterward | Your application |
| How the agent reads it | Loads history at the start of a turn | Search, ranked by keyword and semantic match | All of it, every call |
| Edits | Items are immutable once appended | Entries can be replaced, patched or deleted | You rewrite the prompt |
| Input tokens per question | Not stated | 8.4K on Databricks' open-source runs | 103K on the same runs |
Token figures come from the MemCurrent results on public benchmarks, and they are Databricks' own measurements. Deleting a session, or a whole session store, does not delete what the memory store kept.
How does Databricks Agent Memory work?
A memory store is a workspace-scoped container. Creating one provisions its Lakebase storage, per the agent memory docs. Each entry holds content plus a short description. It sits at a path and belongs to an actor ID, with an optional session ID. The actor ID is how you keep one user's memories apart from another's.
There are two ways to write memory.
The first is tools. The tutorial for existing agents gives the model four of them: recall, remember, forget and list_memories. Each set is bound to one actor, so the model cannot touch another user's entries. You can also skip tools and search memory with each incoming message, then add the top five results to the system prompt.
The second is a memory pipeline. It reads a session store and writes distilled entries into a memory store, under the same actor IDs. The pipeline docs describe three stages: distill new conversations, merge them into topic entries, then combine overlaps and split oversized entries. You can give it instructions about what to keep. Runs are manual by default. A scheduled pipeline runs about every 24 hours, and you cannot set another interval.
Reading is search. It combines BM25 full-text and semantic matching over each entry's content and description. The announcement adds that the agent loads an index of what memory holds at session start. MemCurrent's design describes that index as an auto-generated memory.md file at the top of a table that simulates a file system.
Setup is one Python package, databricks-agentbricks (0.6.0 or later), which bundles the AgentKit SDK with the CLI. It also carries adapters for the OpenAI Agents SDK and LangGraph. Other languages call the REST API. The Agent Bricks quickstart says no workspace setting is required to enable the Beta.
What does Databricks Agent Memory cost?
During the preview, you pay for the Lakebase instance that holds your entries. Databricks says no additional charge applies for agent memory itself, and that pricing may change. Sessions follow the same rule.
The pipeline is billed separately. Each run is a job on serverless general compute, plus Foundation Model Serving for the distillation model. A daily pipeline over many users is a recurring model bill. You pick the distillation model when you create the pipeline, and a default applies if you skip it.
What limits matter before production?
The docs warn that the actor ID "is not an access control." Any principal that can reach a store can read and write every entry for every user, because permissions exist only per store. Your application has to supply the right actor ID, and a strict tenant boundary means separate stores.
Other limits from the docs:
- Search returns up to 100 entries, with no pagination.
- Replacing an entry with a put call is not atomic.
- A pipeline can rewrite or delete any entry for an actor it processes, including entries your agent saved on purpose.
- One pipeline per pair of stores, and one run at a time.
- A run fails above roughly 1,200 actors with UUID actor IDs, because actor IDs are capped at 48 KiB per run.
If a user asks the agent to remember an exact phrasing, the next pipeline run may merge it into a topic entry. The announcement says developers can export and delete what an agent keeps about each user, so you can audit those runs.
What should you read in the fine print?
The headline number is Databricks' own. The announcement says its memory design "tripled agent pass rate" on internal enterprise tasks and used 31% fewer tokens. The MemCurrent post gives the detail. Its internal benchmark, built from real Genie conversations, has 114 test cases across 29 users and 2,233 past sessions. MemCurrent passed 68.4%, against 22.3% with no memory and 78.6% for a ceiling that injects only the correct memories. Mem0, one of the open-source backends it tested, scored 43.9%.
That benchmark is not public, so nobody outside Databricks can rerun it. On the public sets (LoCoMo, LongMemEval and ConvoMem), MemCurrent averaged 88.1% against 87.8% for full context. There its edge is the token bill, at about 12 times fewer input tokens. TechTarget's report of October 22, 2026, notes the results were "not independently verified." Sanjeev Mohan of SanjMo told TechTarget that actual deployments will show how well it runs.
We read the gap between 68.4% and the 78.6% ceiling as the honest part. Distillation drops details, and the post's own ablation shows raw session traces win some back: adding them lifted the pass rate from 66.1% to 68.4%.
The bottom line
If you build agents on Databricks, try Agent Memory with the pipeline on manual. Read what it writes before you schedule it. Design your actor IDs and store boundaries before launch, because the store is the only security boundary. Treat the 3x figure as a vendor result until someone reproduces it.
How do coding agents share memory outside Databricks?
Say you spend a week building an Agent Bricks agent for your analysts, mostly in Claude Code. Agent Memory will remember each analyst's preferences under their actor ID. Nothing remembers what you learned while building it, such as how your actor IDs are formed and which store holds which tenant. Agent Memory reaches only agents that call the AgentKit SDK or the REST API, and Claude Code is not one of them. Open Cursor for an afternoon and you explain the store layout again.
| Databricks Agent Memory | memU | |
|---|---|---|
| Who reads it | Agents you build and deploy, through the SDK, its adapters or REST | Coding-agent hosts such as Claude Code, Codex and Cursor, sharing one memory backend |
| What a person can open | Rows in Lakebase, read and patched through the SDK or REST. MemCurrent keeps its memory.md index in that database too | Readable Markdown files you open and fix |
| Who does the distilling | A pipeline job, billed for compute and model calls | Your coding agent. The judgment stays in the agent, and memU's MemoryService makes no LLM calls |
| Where it lives | Your Databricks workspace, billed for Lakebase | Hosted on memu.so, free and cross-device, or self-hosted on one machine |
If your agents serve customers or analysts on Databricks data, use Agent Memory. It sits in the same workspace as that data and adds no charge beyond Lakebase during the Beta. memU covers the coding agents you use while you build that agent.
To try the hosted version, get an API key from memu.so and send your coding agent one message:
Read https://memu.pro/SKILL.md, follow its instructions to install and configure memU, API Key is
YOUR_MEMU_API_KEY.
The self-hosted setup and the support matrix are in the memU GitHub repository. For the wider choice between retrieval and memory, see agentic RAG vs agent memory. Our Mem0 explainer covers the backend MemCurrent was compared against.
FAQ
Is Databricks Agent Memory free?
During the Beta, Databricks charges for the Lakebase instance that stores sessions and memories, with no additional charge for the memory feature. Memory pipeline runs are billed as serverless compute plus model serving. Databricks says pricing may change.
What is MemCurrent?
MemCurrent is the memory design from Databricks AI Research that Agent Memory implements. It keeps raw session traces and a distilled layer of memories, and updates the distilled layer in the background.
Which agent frameworks work with Databricks Agent Memory?
The databricks-agentbricks package has adapters for the OpenAI Agents SDK and LangGraph. Other Python frameworks can call the AgentKit SDK directly, and the REST API works from any language.
Can users see or delete what the agent remembers?
Developers can change or delete entries through the SDK or REST API, and the agent's forget tool removes a fact on request. The announcement says you can also export each user's entries.
Does actor ID keep users' memories private from each other?
Only inside your application logic. The docs say actor ID is not an access control: anyone with access to a store can read all of its entries, so isolation needs separate stores.