Managed agent memory
This feature is in Beta.
Managed agent memory gives your agents durable, long-term memory that persists across conversations. Databricks stores the memory in Lakebase and manages the storage, indexing, and semantic search for you, so your agents can remember user preferences, past decisions, and accumulated context without you operating a database.
During the preview, you are billed for the underlying Lakebase instance that stores your memory entries. No additional charges apply for managed agent memory itself. Pricing is subject to change as the preview progresses.
Use managed memory when you want your agents to:
- Remember user preferences, facts, and decisions across separate conversations.
- Personalize responses based on what an agent learned in earlier sessions.
- Share accumulated knowledge across agents and projects.
- Improve in accuracy and efficiency over time.
Managed memory works with agents built on any framework. For short-term conversation history within a single interaction, use managed agent sessions.
How managed memory works
Managed memory has two levels:
- A memory store is the workspace-scoped container for an agent's memories. Creating a store provisions the backing Lakebase storage automatically. You address a store by its
display_name. - A memory entry is an individual piece of content in a store. Each entry has a free-form text
content, a shortdescriptionused for retrieval, and a set of fields that organize and partition it:actor_id(required): who the memory belongs to, such as an end user or another agent.session_id(optional): records which session the memory was captured from, for tracing and provenance. Leave it unset for memory that isn't tied to a specific session.path(required): a filesystem-like path that organizes entries within an actor, such as/preferences/response-style.md.
An entry is uniquely identified by the combination of actor_id, session_id, and path.
Retrieval
Retrieve memory two ways:
- List entries for an actor, optionally filtered by
session_idor apathprefix. Use this to browse or render an index of what an agent knows. - Search entries for an actor with a natural-language query. Search returns the most relevant entries ranked by a full-text (BM25) relevance score.
Requirements
- Python 3.10 or above, to use Mason (Databricks' Python client and CLI for agent APIs), which the examples below use. You can also call the REST API directly from any language, with no Python requirement.
Get started
These examples set up managed memory for a support agent: they create a memory store, save a user's preference, and recall it in a later conversation. Choose the client that fits your project. A memory store's display_name must be 3 to 56 characters, start with a lowercase letter, end with a letter or number, and contain only lowercase letters, numbers, and hyphens.
- Mason
- REST API
Mason is Databricks' Python client and CLI for agent APIs. It authenticates with the Databricks SDK's WorkspaceClient.
-
Install Mason:
Bashpip install databricks-mason -
Create a memory store for your agent.
MasonClientauthenticates with yourWorkspaceClientcredentials:Pythonfrom databricks.sdk import WorkspaceClient
from databricks_mason import MasonClient
mason = MasonClient(WorkspaceClient())
memory_store = mason.memory_stores.create("support-agent-memory") -
Save a memory after the agent learns something durable about a user.
actor_idis whose memory this is,pathorganizes it within that actor, anddescriptionimproves retrieval:Pythonmemory_store.add(
actor_id="user-123",
path="/preferences/communication.md",
content="Prefers email over phone. Timezone: PST. Enterprise subscription.",
description="User 123 communication preferences",
) -
Recall the user's memories in a later conversation with a natural-language search:
Pythonresults = memory_store.search(actor_id="user-123", query="communication preferences", limit=10)
The clients call the REST API under /api/2.0/agents/memory-stores. Call it directly for languages other than Python.
-
Generate an OAuth token with the Databricks CLI:
Bashdatabricks auth login --host ${DATABRICKS_HOST}
export DATABRICKS_TOKEN=$(databricks auth token | jq -r .access_token) -
Create a memory store for your agent:
Bashcurl -X POST "https://${DATABRICKS_HOST}/api/2.0/agents/memory-stores" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" -H "Content-Type: application/json" \
-d '{"display_name": "support-agent-memory", "description": "Support agent memory"}' -
Save a memory entry for a user.
actor_idis whose memory this is,pathorganizes it, anddescriptionimproves retrieval:Bashcurl -X POST "https://${DATABRICKS_HOST}/api/2.0/agents/memory-stores/support-agent-memory/entries" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" -H "Content-Type: application/json" \
-d '{"actor_id": "user-123", "path": "/preferences/communication.md", "content": "Prefers email over phone.", "description": "Communication preferences"}' -
Recall the user's memories with a natural-language search:
Bashcurl -X POST "https://${DATABRICKS_HOST}/api/2.0/agents/memory-stores/support-agent-memory/entries:search" \
-H "Authorization: Bearer ${DATABRICKS_TOKEN}" -H "Content-Type: application/json" \
-d '{"actor_id": "user-123", "query": "communication preferences"}'
Give your agent memory tools
To let an agent decide when to save and recall memory, wrap the client operations as tools and instruct the agent on when to use them in its system prompt. Set the actor_id in trusted application code from the verified end-user identity. Never let the model choose whose memory to read or write.
The following example wraps the Mason memory_store from Get started as tools for the OpenAI Agents SDK.
from agents import Agent, function_tool
def make_memory_tools(memory_store, actor_id: str):
@function_tool
def search_memory(query: str) -> str:
"""Search long-term memory for relevant facts about the user."""
results = memory_store.search(actor_id=actor_id, query=query, limit=10)
return "\n\n".join(f"{r.memory.path}: {r.memory.content}" for r in results) or "No memory found."
@function_tool
def save_memory(path: str, content: str, description: str = "") -> str:
"""Save a durable, long-term memory about the user."""
memory_store.add(actor_id=actor_id, path=path, content=content, description=description)
return f"Saved memory at {path}"
return [search_memory, save_memory]
agent = Agent(
name="Support agent",
instructions="Save durable user preferences and recall them when relevant.",
tools=make_memory_tools(memory_store, actor_id="user-123"),
)
The same pattern works with the Claude Agent SDK and other frameworks: wrap the store's search and add operations as the framework's tool type.
Partition and secure memory
Within a store, actor_id is how you separate whose memories are whose. Every list and search is scoped to a single actor_id, so pick the strategy that matches what your agent needs to remember:
- Private memory for each user: Set
actor_idto the verified end-user identity. Each user gets their own partition, and the agent only recalls that user's entries.- Example: A support agent remembers one user's communication preferences and past tickets.
- Shared memory for a group: Set
actor_idto a fixed key you choose, such as a team, project, or organization ID. Everyone reads and writes the same memories.- Example: A team agent remembers a shared glossary of company terms and internal conventions.
- Memory split by something else: Build
actor_idfrom your own values, such as a tenant ID or auser:projectcomposite.- Example: A multi-tenant app sets
actor_idto{tenant}:{user}so each customer's users stay isolated from one another.
- Example: A multi-tenant app sets
Set actor_id in your application code from trusted caller context: the verified end-user identity for per-user memory, or a trusted team or project key for shared memory. Never let the model choose it. If your strategy depends on an end-user identity, reject requests that don't carry one rather than falling back to a shared actor_id.
actor_id separates memories, but it is not an access control. Managed memory stores are workspace-scoped, so any principal that can reach a store can read and write every entry across all actors. The store, not the actor, is the security boundary. For strict isolation between tenants or users, create a separate memory store per boundary.
To let another principal, such as your agent's service principal, use a store, grant it access with the store's grant-permission operation (memory_store.grant_permission(principal_id) in Mason).
Limitations
- Managed memory provides long-term memory only. For short-term conversation history, see managed agent sessions.
- Search is a relevance-ranked, full-text (BM25) operation that returns a top-N result set of up to 100 entries. It does not support pagination or vector similarity search.
- Access control is enforced at the store level. Per-entry and per-actor access control are not available.
- The store
display_nameis immutable after creation. Onlydescriptioncan be updated.