by Sirui Sun and Nihit Desai
Today we're introducing agent memory on Agent Bricks, Databricks' agent developer platform. Agent memory improves agent quality while decreasing costs and latency by storing critical facts, preferences, and workflows that an agent should remember. It's available in Beta today, runs on Lakebase for high reliability and low latency, and is built on Databricks' latest memory research.
Without memory, agents risk rediscovering key facts, forgetting user preferences, and repeat mistakes it was already corrected on. In response, many developers are rolling their own memory solutions, but run into numerous design questions - for example, where should memories be stored? How should memories get synthesized? And once generated, how should they be retrieved?
To address this, Databricks Agent Memory is built on the MemCurrent architecture, pioneered by Databricks Research. MemCurrent combines three access patterns: plugins to log and load context automatically, tools the agent calls on demand, and an offline dreaming pipeline that consolidates memory in the background. All of this is served with extremely low latency using Lakebase. In our internal benchmarks, implementing this memory architecture tripled agent pass rate on real enterprise tasks while using 31% fewer tokens.
Agent Memory joins the rest of Agent Bricks, including agent hosting, Databricks Sandbox, Unity Gateway, pre-built MCP servers, and tracing and evaluation, providing developers all the infrastructure capabilities needed to build production agents.
Two problems show up as soon as an agent moves from a demo to daily use.
Agent developers, and the platform teams that run their agents, have two common workarounds. Each one trades one problem for another:
What teams need is memory that makes agents cheaper and more personal at the same time, without standing up another system to get it.
Figure 1. Agent Memory on Agent Bricks. The agent appends each turn to managed sessions, recalls and saves memories directly, and a memory pipeline distills sessions into long-term memory in the background.
Agent Memory has three parts:
Everything runs on Lakebase, Databricks' serverless Postgres, provisioned in your workspace and operated by Databricks. This ensures that storing and retrieving memories is lightning fast, and that your stores can scale along with your agent traffic.
Agent Memory is a production implementation of MemCurrent, the memory system described in MemCurrent: Designing Memory for Enterprise Agents. Our researchers’ central finding is that memory works best in two layers: a raw record of what happened, and a distilled record of what's worth remembering, kept current by a background process rather than written ad hoc by the agent mid-task.
Built that way, memory improved quality and efficiency at the same time. Agents passed about three times as many tasks as agents without memory, finished faster, and used fewer tokens. The same infrastructure already powers memory in Genie, Databricks' natural-language experience for business users.
Figure 2. Agents with and without memory on Databricks' internal memory benchmark of enterprise data tasks. Source: MemCurrent research.
None of this requires new infrastructure on your side. The Agent Bricks CLI can help you deploy an agent with memory and sessions in minutes.
From then on, your agent's next conversation with each user starts with what it learned from the previous ones. For more info, see the quickstart to create a new agent with memory, or our tutorial for adding memory to an existing agent.
Agent Memory is one part of Agent Bricks, Databricks' agent developer platform for building, running, and improving custom agents at scale, with any model, framework, or harness. Explore Agent Bricks to see the rest of the platform.
Subscribe to our blog and get the latest posts delivered to your inbox.