What you will be able to do
- Distinguish session state (one interaction) from durable memory (one subject, many conversations), and say which Databricks store holds each
- Explain why deleting a session store leaves memory intact
- Describe how a managed memory store and its entries are structured, and how entries are retrieved
Key concept
Managed agent memory (cross-session durable store) — A Lakebase-backed store, managed by Databricks, that holds facts, preferences and decisions about a subject so the agent can recall them in later conversations that have nothing to do with the first one. It persists after the conversation that produced it is gone, because the agent pulls the durable facts out of the session and writes them to a separate memory store.
1.Two kinds of state, both on Lakebase
An agent that remembers anything holds two different kinds of state. The first is the state of the interaction it is running right now. The second is what it should still know next week, in a conversation that has nothing to do with this one. Databricks gives each its own fully managed store. Both run on Lakebase, the managed Postgres backend, and both work with agents built on any framework.
Managed agent sessions hold session state. Usually this is the conversation history: the ordered transcript of messages, tool calls and results. It can also be any other state a framework persists, such as a LangGraph graph. The agent reads it at the start of a turn and appends to it while the turn runs.
Managed agent memory holds durable facts, preferences and decisions. The agent recalls them in later, separate conversations.
The two differ in what they are scoped to. A session belongs to one interaction. It grows during that interaction and is complete on its own. A memory belongs to a *subject*, such as a user, a team or a project. The agent recalls it whenever it is relevant, no matter which conversation first produced it.
The two stores meet at the moment something in a conversation is worth keeping. As the session grows, the agent or your application pulls out the durable facts and writes them to memory. Configuring persistent memory is mostly about this hand-off: what you keep, whose memory it goes under, and where it is stored.
Both managed stores are Beta features. During the preview you are billed for the underlying Lakebase instance that holds your data, with no additional charge for the managed feature itself, and pricing can change as the preview progresses.
No. The docs say you can use either store on its own. Use memory alone when your framework already manages session state, and sessions alone when you only need state within one interaction. For most use cases, though, the recommendation is to use both.
Checkpoint 1 of 5· Exam question
An engineer wants to test a new memory-write schema change for an agent without risking corruption of the production memory data currently in use. Which Lakebase capability directly addresses this need?
Correct answer: A — Creating an isolated branch of the database from a point in time to test the schema change safely
2.Why memory outlives the session
This independence follows from how the hand-off works. Once the durable facts have been pulled out of a session and written to memory, the session can be cleared or left to age out, and the memory stays. That is the reason the two stores are separate. Deleting one session, or a whole session store, does not delete anything kept in a memory store.
In practice, cleaning up transcripts is safe for an agent's long-term knowledge. The flip side is that anything never written to memory goes away when the session does. If a preference only ever existed in the transcript, it is gone once the transcript is gone.
Checkpoint 2 of 5· Check yourself
What has to happen for a fact stated in a conversation to still be available in a later, unrelated conversation?
Memory only holds what has been written to it. The agent or application distills durable facts from the session and writes them to memory, so the memory survives when the session is cleared.
“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”Source: docs.databricks.com
Sources1
3.Short-term and long-term memory on Lakebase
The Lakebase documentation describes the same split as short-term and long-term memory. Lakebase supplies the Postgres backend for both. It uses Databricks authentication and scales automatically with the workload. One agent can use either memory type or both.
| Memory type | Scope | What it gives the agent |
|---|---|---|
| Short-term memory | A single conversation session, using thread IDs and checkpointing | Answers follow-up questions with awareness of earlier turns |
| Long-term memory | Key insights across multiple conversations | Personalized responses based on past interactions; a user knowledge base that improves over time |
Lakebase-backed memory works on two deployment targets. On Databricks Apps, agents can have short-term or long-term memory through LangGraph checkpointers or the OpenAI Agents SDK, and Databricks handles authentication between the app and Lakebase. On Model Serving, agents use Lakebase-backed checkpoints, with LangGraph time travel to resume or fork a conversation from any checkpoint.
In the managed stores, short-term memory corresponds to managed sessions and long-term memory to managed memory. The next paragraphs and table build up the session side, which is separate from the memory store covered in the next section.
Managed sessions have three levels. A session store is the workspace-scoped container for an agent's sessions, and you choose a workspace-unique session_store_name. A session is one durable interaction, typically a conversation thread, inside that store. A session item is one entry in the session's ordered history, such as a message, tool call, tool result or reasoning block. Databricks assigns each item an item_id and a create_time, and items are immutable once appended.
| Level | Identifier or field | Meaning |
|---|---|---|
| Session store | session_store_name | Workspace-unique name of the container for an agent's sessions |
| Session | actor_id (required) | Who the session belongs to; groups all of one subject's sessions so you can list and filter them |
| Session | session_id (optional) | Caller-chosen ID for the interaction; the service generates one if you omit it |
| Session | parent_session_id (optional) | Links a session to the one it was forked from, to represent branched conversations |
| Session item | item_id, create_time | Assigned by Databricks; the item's data is opaque and immutable after it is appended |
Checkpoint 3 of 5· Match them up
Match each requirement to the store or mechanism that fits it
Tap a term, then the definition that fits it.
Sessions hold the state of one interaction. Memory holds what should carry across conversations. Checkpoint time travel and parent_session_id both deal with branching conversations, not with cross-session knowledge.
“Managed sessions hold the state of a single interaction (short-term, in-session state).”Source: docs.databricks.com
4.Inside a managed memory store
Managed agent memory (in Beta) has two levels. A memory store is the workspace-scoped container for an agent's memories, and you refer to it by its display_name. When you create a store, Databricks provisions the backing Lakebase storage automatically. Databricks also handles storage and indexing, so you never run the database yourself. During the preview you pay for the underlying Lakebase instance, and managed memory itself carries no extra charge.
A memory entry is a single piece of content inside a store. Its fields are listed below.
| Field | Required | Purpose |
|---|---|---|
| content | — | Free-form text of the memory |
| description | — | Short description used for retrieval |
| actor_id | Yes | Who the memory belongs to, such as an end user or another agent |
| session_id | No | Which session the memory was captured from, for tracing and provenance; leave unset if not tied to a session |
| path | Yes | Filesystem-like path organizing entries within an actor, such as /preferences/response-style.md |
There are two ways to read memory back. List returns an actor's entries, optionally filtered by session_id or a path prefix. Use it to browse or build an index of what the agent knows. Search takes a natural-language query and returns the actor's most relevant entries, ranked by a full-text (BM25) relevance score.
The overview describes memory as retrieved by semantic search. The search operation itself is documented as a natural-language query ranked by a BM25 full-text relevance score, so read "semantic search" at the overview level as this natural-language search, and use the BM25 description when reasoning about how results are ranked.
Two further rules matter when you configure a store. First, naming: a 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. Second, isolation: actor_id separates memories within a store, 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, so for strict isolation between tenants or users you create a separate memory store per boundary. Set actor_id from trusted application code, never from a model's choice.
Checkpoint 4 of 5· Check yourself
An agent writes two entries for actor_id "user-123" at the same path, /preferences/communication.md. Neither entry has a session_id. What decides whether these count as the same entry?
An entry's identity is the combination of all three fields. Path alone is not enough, and description only helps retrieval.
“An entry is uniquely identified by the combination of actor_id, session_id, and path.”Source: docs.databricks.com
Checkpoint 5 of 5· Check yourself
Which display_name is valid for a new managed memory store?
A display_name must be 3 to 56 characters, start with a lowercase letter, end with a letter or number, and use only lowercase letters, numbers and hyphens. The other options break one of these rules: uppercase letters and underscores, a trailing hyphen, and too few characters.
“A memory store's display_name must be 3 to 56 characters, start with a lowercase letter, end with a letter or number”Source: docs.databricks.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Deleting an agent's session store also wipes the memories that were captured from those sessions.Why is that wrong?
Session and memory stores are independent. Facts written to memory stay after the session, or the whole session store, is deleted.
Covered in Why memory outlives the session
2.Every memory entry has to carry the session_id of the conversation it came from.Why is that wrong?
On a memory entry, session_id is optional and only records provenance. Leave it unset for memory that isn't tied to a specific session.
Covered in Inside a managed memory store
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Memories are scoped to a subject, not an interaction”
↩︎ Two kinds of state, both on Lakebase“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ Two kinds of state, both on Lakebase“Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state.”
↩︎ Two kinds of state, both on Lakebase“The session is later cleared or ages out; the memory persists.”
↩︎ Why memory outlives the session“Managed agent memory stores durable facts, preferences, and decisions that an agent recalls in later, separate conversations”
↩︎ Key concept“deleting a session, or an entire session store, does not delete memory retained in a memory store.”
↩︎ Exam trap 1“deleting a session, or an entire session store, does not delete memory retained in a memory store.”
↩︎ Prediction“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ Checkpoint - 2.
“During the preview, you are billed for the underlying Lakebase instance that stores your sessions.”
↩︎ Two kinds of state, both on Lakebase“parent_session_id (optional): links a session to the one it was forked from”
↩︎ Short-term and long-term memory on Lakebase“A session store is the workspace-scoped container for an agent's sessions.”
↩︎ Short-term and long-term memory on Lakebase“Items are immutable after they are appended.”
↩︎ Short-term and long-term memory on Lakebase“Managed sessions hold the state of a single interaction (short-term, in-session state).”
↩︎ Checkpoint - 3.
“Lakebase provides a fully managed Postgres backend for storing agent state and memory”
↩︎ Short-term and long-term memory on Lakebase“Supports LangGraph time travel to resume or fork conversations from any checkpoint.”
↩︎ Short-term and long-term memory on Lakebase - 4.
“Creating a store provisions the backing Lakebase storage automatically.”
↩︎ Inside a managed memory store“Search returns the most relevant entries ranked by a full-text (BM25) relevance score.”
↩︎ Inside a managed memory store“actor_id separates memories, but it is not an access control.”
↩︎ Inside a managed memory store“The store, not the actor, is the security boundary.”
↩︎ Inside a managed memory store“Leave it unset for memory that isn't tied to a specific session.”
↩︎ Exam trap 2“An entry is uniquely identified by the combination of actor_id, session_id, and path.”
↩︎ Checkpoint“A memory store's display_name must be 3 to 56 characters, start with a lowercase letter, end with a letter or number”
↩︎ Checkpoint