What you will be able to do
- Tell apart the two kinds of agent state Databricks provides: session state scoped to one interaction, and memory scoped to a subject across interactions
- Spot the two ways an agent goes wrong: pulling from long-term memory when the answer is already in the current session, and relying on session history when the need spans sessions
- Use the 'future, unrelated conversation' test to decide which store a piece of information belongs in
Key concept
Memory scope (interaction vs. subject) — Every piece of agent context belongs to a scope. Session state belongs to one interaction and is replayed to continue it. Memory belongs to a subject, such as a user, and is recalled in any later conversation where it is relevant. A memory mismatch means the agent is reading from the store whose scope doesn't fit the information it needs.
1.Two kinds of state, two scopes
Databricks describes agent state as two separate needs: the state of the interaction the agent is handling right now, and the durable knowledge it carries from one conversation into the next. Each has its own fully managed store, both backed by Lakebase and both usable from any agent framework.
Managed agent sessions hold session state. Usually that is the conversation history: the ordered transcript of messages, tool calls and results. It can also be any state a framework persists, such as a LangGraph graph. The agent reads it at the start of a turn and appends to it as the interaction runs. The documentation puts the boundary plainly: a session belongs to one interaction, grows within it, and is complete on its own.
Managed agent memory holds durable facts, preferences and decisions that the agent recalls in later, separate conversations. A memory is not tied to the conversation that produced it. It belongs to a subject, for example a user, and the agent recalls it whenever it is relevant, whichever conversation first surfaced it.
The predict above targets the most common misreading. Both stores are durable, because both are Lakebase-backed, so durability is the wrong way to tell them apart. Ask instead what the information is scoped to. The Lakebase agent-state page makes the same split in its own terms. Short-term memory captures context within one conversation session using thread IDs and checkpointing. Long-term memory extracts and stores key insights across multiple conversations.
The interaction. It is in the current transcript, which the session already holds and the agent replays at the start of every turn. Nothing in the user's message says it needs to outlive this conversation.
Checkpoint 1 of 5· Check yourself
Which statement correctly separates managed agent sessions from managed agent memory?
Both stores are Lakebase-backed and durable. What separates them is scope: one interaction for sessions, a subject across conversations for memory.
“Sessions are scoped to one interaction”Source: docs.databricks.com
2.The two directions a mismatch can run
With the scopes clear, a degraded agent can be diagnosed by asking two questions: where does the information it needs actually live, and which store is it reading from? There are two ways to get this wrong, and each fails differently.
| Symptom | What the agent is doing | Where the information actually lives | Correct source |
|---|---|---|---|
| Agent ignores or contradicts something said earlier in this same conversation, or searches for it as if it were a stored fact | Querying long-term memory for context | Earlier turns of the current interaction | Managed agent sessions: replay the session's history |
| Agent asks a returning user to repeat preferences or decisions from a previous conversation | Relying only on the current session's history | A fact about the subject, from an earlier and separate conversation | Managed agent memory: recall entries for that actor |
| Personalization stops working once old conversations are cleared or age out | Treating session history as the long-term record | Nowhere durable, because nothing was distilled into memory | Write durable facts to memory as the session accumulates |
Long-term memory used for in-session information. If the user stated something in this conversation, it is already in the session transcript. The managed memory documentation sends this case elsewhere: short-term conversation history within a single interaction belongs in managed sessions, not in memory. An agent that searches memory for it is looking in a store built for facts about the subject, not for the turn-by-turn flow of the current exchange.
Session history used for cross-session needs. The opposite failure happens when the needed context came from an earlier, separate conversation. A session holds the state of one interaction, so a new conversation starts with a new transcript, and a stable preference the user gave last week is not in it. Managed memory exists for exactly this: remembering preferences, facts and decisions across separate conversations, and personalizing responses with what the agent learned earlier.
The third row is the same cross-session failure seen over time. Sessions are cleared or age out. If the durable facts were never written to memory, they disappear with the session.
Checkpoint 2 of 5· Match them up
Match each agent need to the store operation that should supply it
Tap a term, then the definition that fits it.
In-interaction continuity, including branching a conversation, comes from sessions. Anything learned in a different, earlier conversation has to come from memory, and it is only there if it was written to memory before the session was cleared.
“sessions give the agent continuity within a conversation, and memory gives it continuity across conversations”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
A scheduling assistant helps a user plan a multi-week home renovation. On Monday, the user tells the agent their preferred contractor is "BuildRight Co." When the user returns on Thursday to continue planning, in a brand-new conversation, the agent has no memory of the preferred contractor and asks the user to repeat it. The agent currently keeps all state only in the in-context conversation buffer, which is discarded when each session ends. What is the correct memory strategy to fix this?
Correct answer: C — Persist the contractor preference to a Lakebase-backed record keyed by user identity, and retrieve it at the start of each new session
- A. Incorrect. A session-scoped scratchpad is discarded when the conversation ends, which is precisely the mechanism causing the information loss described — it cannot satisfy a cross-session information need.
- B. Incorrect. A longer system prompt only helps within the same session; it does not carry information forward into an entirely new conversation started days later.
- C. Correct. The information need spans multiple, separate sessions days apart, which requires durable, cross-session persistence. Writing the preference to a Lakebase-backed store keyed by user identity and retrieving it when a new session starts is exactly the memory type this scenario needs.
- D. Incorrect. A larger context window does not help once a session has fully ended and its conversation buffer has been discarded; the Thursday session starts with an empty context regardless of window size.
3.The test: would it matter in a future, unrelated conversation?
Whenever it is unclear which scope a piece of information has, Databricks gives one test: would it still matter in a future, unrelated conversation? Its definition of memory is built on that test, describing memories as durable facts that should still matter later, such as a user's stable preferences, a past decision or an ongoing project.
The example system prompt for managed memory turns the test into a rule for what to save. It comes from the legacy managed memory page, which Databricks no longer recommends for new agents, but the scoping logic still applies. It says to save only what will still matter in a future, unrelated conversation, and it excludes passing chatter, the agent's own guesses, secrets and anything scoped to the current chat. A 'for now' label fails the test, so it belongs in the session. A stated, stable preference passes, so it belongs in memory.
Run the test in both directions when diagnosing. If the information fails it, any configuration that sends the agent to long-term storage for it is a mismatch. If it passes but the agent can only see the current transcript, the opposite mismatch applies. Neither store is better than the other. Most agents need both, and Databricks recommends using them together in most cases. Sessions alone are enough when only in-interaction state is needed. Memory alone is enough when the framework already manages session state.
Checkpoint 4 of 5· Check yourself
An agent's framework already persists and replays conversation threads itself. The team wants the agent to remember users' stable preferences between conversations. What is the minimal correct addition?
Cross-conversation preferences need memory. Because the framework already handles in-interaction state, Databricks supports using memory on its own.
“Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state.”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
Which statement accurately describes Lakebase's role in an agent memory architecture?
Correct answer: C — Lakebase is a fully managed Postgres database that can serve as a durable state store for agent memory that must persist across sessions
- A. Incorrect. Lakebase is a durable database, not an in-memory, session-scoped cache; it is designed to persist data beyond a single conversation, not to be cleared when a session ends.
- B. Incorrect. Lakebase is a managed database product, not a system-prompt mechanism; hard-coding facts into instructions is a form of in-context memory, which is a different memory type entirely.
- C. Correct. Lakebase is a fully managed Postgres database integrated into the Databricks platform, and one of its documented use cases is serving as a state store for AI agents, giving durable, cross-session persistence for agent memory.
- D. Incorrect. Lakebase is a relational (Postgres) database used for transactional/state storage; semantic similarity search over embeddings is the role of a vector search index, not Lakebase.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Managed sessions are ephemeral, so anything that has to survive an agent restart has to go into long-term memory.Why is that wrong?
Managed sessions are durable and Lakebase-backed. They survive restarts and can be resumed. Choosing between sessions and memory is about scope (one interaction or a subject across conversations), not durability.
Covered in Two kinds of state, two scopes
2.Anything the user explicitly states should be written to long-term memory so the agent never forgets it.Why is that wrong?
Memory is only for information that still matters in a future, unrelated conversation. Chat-scoped items, such as a 'for now' label, belong in the session. Saving them to memory pollutes later recall.
Covered in The test: would it matter in a future, unrelated conversation?
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The agent reads it at the start of a turn and appends to it as the interaction runs.”
↩︎ Two kinds of state, two scopes“A session grows within the interaction and is complete on its own.”
↩︎ Two kinds of state, two scopes“The agent recalls them whenever they are relevant, regardless of which conversation surfaced them.”
↩︎ Two kinds of state, two scopes“The session is later cleared or ages out; the memory persists.”
↩︎ The two directions a mismatch can run“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ The two directions a mismatch can run“the durable facts that should still matter in a future, unrelated conversation”
↩︎ The test: would it matter in a future, unrelated conversation?“Use both together for most use cases”
↩︎ The test: would it matter in a future, unrelated conversation?“The following earlier approach to agent memory is legacy and not recommended for new agents”
↩︎ The test: would it matter in a future, unrelated conversation?“Memories are scoped to a subject, not an interaction”
↩︎ Key concept“Sessions are scoped to one interaction”
↩︎ Checkpoint“sessions give the agent continuity within a conversation, and memory gives it continuity across conversations”
↩︎ Checkpoint“Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state.”
↩︎ Checkpoint - 2.
“Captures context within a single conversation session using thread IDs and checkpointing.”
↩︎ Two kinds of state, two scopes“Extracts and stores key insights across multiple conversations.”
↩︎ Two kinds of state, two scopes - 3.
“For short-term conversation history within a single interaction, use managed agent sessions.”
↩︎ The two directions a mismatch can run“Remember user preferences, facts, and decisions across separate conversations.”
↩︎ The two directions a mismatch can run“Search entries for an actor with a natural-language query.”
↩︎ The two directions a mismatch can run - 4.
“Managed sessions hold the state of a single interaction (short-term, in-session state).”
↩︎ The two directions a mismatch can run“parent_session_id (optional): links a session to the one it was forked from, to represent branched conversations.”
↩︎ The two directions a mismatch can run“Persist an agent's conversation history so it survives restarts and can be resumed later.”
↩︎ Exam trap 1“Persist an agent's conversation history so it survives restarts and can be resumed later.”
↩︎ Prediction
Also cited
“Save only what will still matter in a future, unrelated conversation”
↩︎ Exam trap 2“Don't save your own suggestions or guesses, passing chatter, secrets, or anything scoped to this chat”
↩︎ Prediction