Databricks Agent Memory beta: decide what your agent forgets

An AI agent that forgets everything between conversations is a temp you retrain every morning. An agent that remembers everything is worse: it keeps the wrong price, the old policy, and the customer detail it should never have stored. Databricks Agent Memory, announced October 20 and now in beta, is Databricks' answer to the middle ground. The interesting part isn't the benchmark. It's that memory is now a database you have to govern.

What actually happened

Per Databricks' announcement, Agent Memory runs on Agent Bricks, its agent developer platform, and stores facts, preferences, and workflows an agent should keep. It's built on an architecture Databricks Research calls MemCurrent, with three parts:

• Plugins that log and load context automatically.
• Tools the agent calls on demand to search memory.
• An offline "dreaming" pipeline that consolidates memory in the background: it pulls durable facts from past sessions, removes duplicates, and replaces facts that were contradicted.

Sessions and memories are stored in Lakebase, Databricks' serverless Postgres, inside your own workspace. Databricks says developers can read, export, and delete per-user entries, and can tell pipelines what to keep.

The headline numbers are Databricks' own: the architecture "tripled agent pass rate on real enterprise tasks while using 31% fewer tokens." It also reports that sending full conversation history used about 12x more input tokens than well-designed memory at the same accuracy. These are vendor benchmarks, not independent results.

On cost, the Azure Databricks documentation says that during the preview you pay for the underlying Lakebase instance, with no extra charge for agent memory itself, and that pricing may change. It's a beta, so APIs and behavior can change too.

Why agent memory matters for your business

Memory is where your token bill hides. The 12x figure matches what we see: teams stuff the whole chat history into every call because it's easy. Distilled memory is cheaper per question, if it stays accurate.

"Replaces contradicted facts" is a policy, not a feature. When a customer says their address changed, who decides which version wins? When your return window changes from 30 days to 14, does the agent forget the old one? Write those rules down before a pipeline decides for you.

Memory is customer data. Per-user memories are records of what people told your agent. Treat them like your CRM: retention limits, a deletion path, and a clear list of what never gets stored (card numbers, health details, passwords).

Keep memory portable. Postgres in your own workspace is a good sign. Still, test the export before you depend on it. If you leave the platform, your agent's memory should leave with you.

Sources: Databricks, Microsoft Learn: Azure Databricks agent memory.