What you will be able to do
- Tell apart working state that only lives in the prompt during a run from state that has to be persisted outside the model
- Spot the scenario triggers (restart, resume, follow-up rebuild, branching, cross-conversation recall) that call for a durable state store
- Once state has to persist, decide whether it belongs in a session store or a memory store
Key concept
Durable agent state — Agent state that is written to a managed store outside the model's context, so it can be read back later. A multi-step agent needs it as soon as its work has to survive the end of the running process, be picked up again later, or be forked. State held only in the prompt for the current run can do none of these.
1.Prompt-only working state vs. a persisted state object
An agent working through a multi-step task builds up intermediate material as it goes: user messages, tool calls, tool results, partial reasoning. The simplest place to keep that material is the context itself. Each step's output is appended to the prompt, and the model reads it on the next step. This lesson calls that an in-context scratchpad. It costs nothing to set up, and it exists only while the current run is alive.
The alternative is to write that state to a store outside the model and read it back when needed. Databricks frames an agent's context needs as two kinds of state: the state of the interaction it is handling now, and the durable knowledge it carries from one conversation to the next. The platform provides a managed store for each kind.
The Lakebase documentation gives the reason a store exists at all: agents need persistent storage to keep context across turns and sessions. Lakebase supplies that storage as a fully managed Postgres backend that integrates with Databricks authentication and scales automatically. Agents built with LangGraph or the OpenAI Agents SDK keep their conversation state and long-term memory there.
Checkpoint 1 of 5· Check yourself
According to the Lakebase documentation, why do agents need a persistent storage backend?
The documentation says agents need persistent storage to maintain context across turns and sessions, which a prompt-only scratchpad cannot provide beyond the live run.
“Agents need persistent storage to maintain context across turns and sessions.”Source: docs.databricks.com
2.The triggers that make a durable store mandatory
A task with many steps is not, on its own, a reason to persist state. If the whole task runs inside one live process and nothing has to read its state afterwards, the in-context scratchpad is enough. A durable store becomes necessary when the state has to exist outside that process. The Databricks documentation names these situations directly:
- Survive restarts and resume later. The history has to outlast the process that produced it. - Rebuild full context on a follow-up. A later request reconstructs the interaction, including tool calls and reasoning, rather than starting from nothing. - List, resume, and branch past conversations from your own UI. The application has to enumerate and reopen interactions. - Resume or fork from any checkpoint. On Model Serving, Lakebase-backed checkpoints support LangGraph time travel. - Recall across separate conversations. Preferences, facts, and decisions have to carry into an unrelated future conversation.
If a scenario contains any one of these, a scratchpad that exists only for one run cannot meet the requirement. The state has to be persisted.
| Requirement in the scenario | Prompt-only scratchpad enough? | Durable store that fits |
|---|---|---|
| Intermediate tool results used only within the current run | Yes | None required |
| Interaction survives restarts and can be resumed later | No | Managed agent sessions |
| Reconstruct full context (tool calls, reasoning) on a follow-up message | No | Managed agent sessions |
| List, resume, and branch past conversations from your own UI | No | Managed agent sessions |
| Resume or fork from any checkpoint on Model Serving | No | Lakebase-backed LangGraph checkpoints |
| Remember preferences, facts, and decisions across separate conversations | No | Managed agent memory |
Checkpoint 2 of 5· Check yourself
A team deploys a LangGraph agent to a Model Serving endpoint. Reviewers want to go back to step 4 of a past run and try a different branch from there. What does this require?
Forking from an earlier point needs persisted checkpoints. The documentation states that Lakebase-backed checkpoints on Model Serving support time travel to resume or fork from any checkpoint.
“Supports LangGraph time travel to resume or fork conversations from any checkpoint.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
An agent runs a multi-step data migration that can take up to three days to complete, with the underlying compute occasionally restarting between steps. The team needs the agent to resume exactly where it left off after any restart. Which memory design best fits this requirement?
Correct answer: B — Persist step progress to a Lakebase-backed state table and reload it on restart
- A. Incorrect: an in-context scratchpad is lost whenever the process restarts or the session ends, so it cannot survive a multi-day job with compute restarts.
- B. Correct: a Delta-backed state store like Lakebase persists across restarts and sessions, letting the agent read back exactly where it stopped and resume reliably.
- C. Incorrect: resummarizing conversation history does not recover durable checkpoint data and still depends on context that may already be gone after a restart.
- D. Incorrect: an in-process variable is held in memory and is wiped out the moment the process restarts, offering no durability.
3.Once state has to persist: session store or memory store?
After you decide state has to leave the context, the next question is how far it has to reach. Databricks provides two independent Lakebase-backed stores, and they differ in scope.
Managed agent sessions hold session state: the working state of one interaction, most often 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. A session grows within the interaction and is complete on its own.
Managed agent memory holds durable facts, preferences, and decisions that an agent recalls in later, separate conversations, retrieved by semantic search. Memories are scoped to a subject, such as a user, not to an interaction.
The two connect at the point where something in a conversation is worth keeping. As a session accumulates, the agent or 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.
| Dimension | Managed agent sessions | Managed agent memory |
|---|---|---|
| Scoped to | One interaction | A subject, not an interaction |
| Typical content | Conversation history: messages, tool calls, results | Preferences, facts, and decisions |
| Gives the agent | Continuity within a conversation | Continuity across conversations |
| Use it alone when | You only need in-interaction state | Your framework already manages session state |
Checkpoint 4 of 5· Match them up
Match each requirement to the store that serves it
Tap a term, then the definition that fits it.
Sessions give continuity within one interaction and memory gives continuity across interactions. The documentation recommends using both for most use cases.
“sessions give the agent continuity within a conversation, and memory gives it continuity across conversations”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
A support agent answers a single user question by drafting an outline, refining it twice, and then producing a final reply, all within one short conversation turn that completes in seconds. Which memory approach is most appropriate for the intermediate outline and drafts?
Correct answer: B — Keep the drafts in the in-context scratchpad for the duration of the turn
- A. Incorrect: writing every intermediate draft to Delta adds durability overhead with no benefit, since the drafts are only needed within the single, short-lived turn.
- B. Correct: for transient reasoning that lives and dies within one turn, an in-context scratchpad is sufficient and avoids unnecessary persistence overhead.
- C. Incorrect: Lakebase is meant for durable, cross-session state; using it for throwaway intermediate drafts adds latency and cost without a durability need.
- D. Incorrect: Unity Catalog governs durable, shareable data assets, which is unnecessary overhead for transient in-turn reasoning that no other process needs.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A durable store is needed only for cross-conversation memory. State within a single interaction can always stay in the context.Why is that wrong?
A single interaction also needs persisted state if it has to survive a restart, be resumed later, or be rebuilt on a follow-up. That is exactly what managed agent sessions are for.
2.A session store gives the agent long-term memory of a user across conversations.Why is that wrong?
Sessions hold the state of one interaction. Cross-conversation recall of preferences and decisions belongs in managed agent memory.
Covered in Once state has to persist: session store or memory store?
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“To hold context, an agent needs two kinds of state”
↩︎ Prompt-only working state vs. a persisted state object“Sessions are scoped to one interaction: the working state the agent replays to continue that interaction”
↩︎ Once state has to persist: session store or memory store?“Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state.”
↩︎ Once state has to persist: session store or memory store?“The session is later cleared or ages out; the memory persists.”
↩︎ Once state has to persist: session store or memory store?“To hold context, an agent needs two kinds of state”
↩︎ Key concept“sessions give the agent continuity within a conversation, and memory gives it continuity across conversations”
↩︎ Checkpoint - 2.
“Agents need persistent storage to maintain context across turns and sessions.”
↩︎ Prompt-only working state vs. a persisted state object“Supports LangGraph time travel to resume or fork conversations from any checkpoint.”
↩︎ Checkpoint - 3.
“Agents built with LangGraph or the OpenAI Agents SDK store conversation state and long-term memory in Postgres.”
↩︎ Prompt-only working state vs. a persisted state object - 4.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”
↩︎ The triggers that make a durable store mandatory“List, resume, and branch past conversations from your own UI.”
↩︎ The triggers that make a durable store mandatory“Persist an agent's conversation history so it survives restarts and can be resumed later.”
↩︎ Exam trap 1“Managed sessions hold the state of a single interaction (short-term, in-session state).”
↩︎ Exam trap 2“Persist an agent's conversation history so it survives restarts and can be resumed later.”
↩︎ Prediction - 5.
“Remember user preferences, facts, and decisions across separate conversations.”
↩︎ The triggers that make a durable store mandatory