What you will be able to do
- Fix an agent that searches long-term storage for context it should replay from the current session
- Fix an agent that relies on session history for facts that need to persist across conversations
- Wire sessions and memory together so durable facts are distilled from sessions, recalled only when needed, and outlive the session
1.When the answer is in this conversation: replay the session
Say a diagnosis shows the agent searching long-term memory for something the user said earlier in the same conversation. The fix is to load the conversation itself into context. Managed agent sessions are built for this: they reconstruct full context, including tool calls and reasoning, on a follow-up message. The agent doesn't have to search for the earlier turns, because they are already stored in order.
The session documentation's pattern is short. On a follow-up request, reload the session by its ID and read its full history in chronological order to rebuild context. One detail matters for correctness: list_items returns newest-first by default, so the sample asks for chronological order explicitly.
Checkpoint 1 of 5· Fill the gap
Which session store call completes this line so that it rebuilds the conversation's context?
history = [item.data for item in session. ? (order_by="create_time asc")]Rebuilding context means reading the session's ordered items back with list_items, sorted by create_time ascending. search is a memory-store operation, and append_items writes items rather than reading them.
Source: docs.databricks.comFrameworks such as the OpenAI Agents SDK and the Claude Agent SDK already work this way: they read history at the start of a run and append new items at the end. So the session store slots in without changing the agent's flow.
| Framework operation | Session store call |
|---|---|
| Read history | list_items in chronological order (order_by="create_time asc") |
| Add turn items | append the new items |
| Undo last item | pop the most recent item |
| Clear the thread | clear the session's items |
Sources1
2.When the answer is from an earlier conversation: recall from memory
The opposite diagnosis is an agent that only has the current transcript when the context it needs came from a previous conversation. Here the fix is managed agent memory. Each memory entry has free-form content, a short description used for retrieval, an actor_id naming whose memory it is, and a path that organizes entries within that actor, such as /preferences/response-style.md. The optional session_id on an entry only records which session the memory came from, for tracing and provenance. You leave it unset for memory that isn't tied to a particular session.
To let the agent decide when to save and recall, Databricks wraps the store's operations as tools and tells the agent in its system prompt when to use them:
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]Notice that actor_id is a parameter of make_memory_tools, not something the model passes to search_memory. This is deliberate. Memory is scoped to a subject, so the subject has to be fixed by the application from the verified end-user identity. If the model could pick it, the agent might recall or overwrite another user's memories.
Checkpoint 2 of 5· Check yourself
A team adds memory tools to its agent and lets the model supply actor_id on each search_memory call, so the agent can 'figure out who it is talking to.' What is wrong with this design?
Memory is scoped to a subject, and the subject must come from trusted identity. Databricks says outright that the model must not choose whose memory to read or write.
“Never let the model choose whose memory to read or write.”Source: docs.databricks.com
Sources2
3.Using both: distill, recall only when needed, keep memory current
Most production agents need both stores, which makes the connection between them the next place things can go wrong. Databricks describes the hand-off: as a session builds up, the agent or the application distills the durable facts out of it and writes them to memory. The session is later cleared or ages out, and the memory stays. That is why the stores are independent, which answers the predict: deleting a session, or a whole session store, does not delete memories held in a memory store. If an agent forgets returning users once old sessions are cleaned up, the distillation step is missing. More session retention would not fix it.
Having both stores can also bring back the first mismatch. An agent that searches memory on every turn will pull in long-term entries even when the conversation already has the answer. The legacy page's example recall instructions guard against this. They tell the agent to use memory 'deliberately, not by reflex', and to recall personalized information only when it doesn't already have it from this conversation. They also say to skip memory when the answer doesn't depend on who is asking.
The last risk is a conflict between stores. If the user says something in this session that contradicts a stored memory, the current statement wins, and the instructions say to update or replace the stored entry rather than keep both. Otherwise the stale memory goes on misleading future conversations.
Checkpoint 3 of 5· Put it in order
Put the lifecycle of a durable fact in the order Databricks describes
- 1.The agent or application distills it out of the session and writes it to memory
- 2.The session is later cleared or ages out
- 3.The fact comes up as the session accumulates during a conversation
- 4.The memory persists and is recalled in a later, unrelated conversation
Durable facts are distilled from the session into memory before the session ends. Because the stores are independent, the memory remains for later conversations.
“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
Checkpoint 4 of 5· Check yourself
Earlier in the current conversation, a user gave the agent their deployment region. On the next turn the agent calls search_memory for 'deployment region' and answers with an older, different region it finds. What is the right correction?
The answer was already in the session, so the memory lookup was the mismatch. The example recall policy limits recall to information the agent doesn't already have from this conversation, and replaces contradicted entries.
“If the user's info changes or contradicts what's stored, update or replace it rather than keeping both”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
A meal-planning agent has a persistent Lakebase record noting that a user is "vegetarian," written a month ago. In today's session, the user says "Actually, I've started eating fish again — please include seafood in tonight's suggestions." The agent's next recommendation still excludes seafood because it re-reads and applies the older persisted preference instead of the correction just given in the current turn. What is the correct fix?
Correct answer: C — The agent should give the current session's correction precedence over the persisted long-term value for this turn, and update the persisted record with new preference.
- A. Incorrect. Deleting the vegetarian preference entirely discards a persistent fact that may still be useful; the fix should update the stored value rather than erase it, so future sessions can reflect the correction.
- B. Incorrect. Abandoning Lakebase and relying solely on in‑context memory reintroduces the risk of losing preferences across sessions; the issue is about correctly ordering conflicting information, not eliminating long‑term storage.
- C. Correct. When a fresher explicit statement exists in the current session, it should take precedence over an older persisted value for the immediate response, and the persisted store must be updated so future turns reflect the correction. This resolves the precedence mismatch without discarding the value of persistent memory.
- D. Incorrect. Querying Lakebase more frequently does not change which source gets priority—the older persisted value would still be favored over the correction just provided in the current turn. The problem is a precedence rule, not a refresh frequency.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Deleting a session store also clears the long-term memories that were captured from those sessions.Why is that wrong?
Managed sessions and managed memory are independent. Memories distilled from a session persist after the session or the whole session store is deleted.
Covered in Using both: distill, recall only when needed, keep memory current
2.An agent with long-term memory should search it on every turn to be safe.Why is that wrong?
Searching memory by reflex puts long-term entries in context even when the current conversation already has the answer. The example recall policy limits recall to information the agent doesn't already have from this conversation.
Covered in Using both: distill, recall only when needed, keep memory current
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”
↩︎ When the answer is in this conversation: replay the session“On a follow-up request, reload the session and read its full history in order to rebuild context”
↩︎ When the answer is in this conversation: replay the session“read conversation history at the start of a run and append new items at the end”
↩︎ When the answer is in this conversation: replay the session“Managed sessions and managed memory are independent.”
↩︎ Using both: distill, recall only when needed, keep memory current - 2.
“session_id (optional): records which session the memory was captured from, for tracing and provenance.”
↩︎ When the answer is from an earlier conversation: recall from memory“wrap the client operations as tools and instruct the agent on when to use them in its system prompt”
↩︎ When the answer is from an earlier conversation: recall from memory“Set the actor_id in trusted application code from the verified end-user identity.”
↩︎ When the answer is from an earlier conversation: recall from memory“Never let the model choose whose memory to read or write.”
↩︎ Checkpoint - 3.
“The session is later cleared or ages out; the memory persists.”
↩︎ Using both: distill, recall only when needed, keep memory current“deleting a session, or an entire session store, does not delete memory retained in a memory store.”
↩︎ Exam trap 1“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ Checkpoint - 4.
“Use it deliberately, not by reflex.”
↩︎ Using both: distill, recall only when needed, keep memory current“Skip memory only when the answer truly doesn't depend on who's asking (general knowledge, math, coding) or you already have what you need.”
↩︎ Using both: distill, recall only when needed, keep memory current“and you don't already have it from this conversation”
↩︎ Exam trap 2“If the user's info changes or contradicts what's stored, update or replace it rather than keeping both”
↩︎ Checkpoint