Skip to main content
Last updated on

Agent memory and sessions

To hold context, an agent needs two kinds of state: the state of the interaction it is handling right now, and the durable knowledge it carries from one conversation to the next. Databricks provides a fully managed store for each, both backed by Lakebase and usable from agents built on any framework:

  • Managed agent sessions store an agent's session state: the state an agent or framework keeps for one interaction. Most commonly this is the conversation history (the ordered transcript of messages, tool calls, and results), but it can 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.
  • Managed agent memory stores durable facts, preferences, and decisions that an agent recalls in later, separate conversations, retrieved by semantic search.

How sessions and memory relate​

An agent reads and appends to a session store for the current conversation, and recalls and saves durable facts to a memory store that spans conversations.

Sessions are scoped to one interaction: the working state the agent replays to continue that interaction, such as its conversation transcript. A session grows within the interaction and is complete on its own.

Memories are scoped to a subject, not an interaction: the durable facts that should still matter in a future, unrelated conversation, such as a user's stable preferences, a past decision, or an ongoing project. The agent recalls them whenever they are relevant, regardless of which conversation surfaced them.

The two connect at the point where something in a conversation is worth keeping. As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory. The session is later cleared or ages out; the memory persists. This is why the stores are independent: deleting a session, or an entire session store, does not delete memory retained in a memory store.

Use both together for most use cases: sessions give the agent continuity within a conversation, and memory gives it continuity across conversations. You can also use either on its own. Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state.

Choose where to start​

    • Managed agent sessions
    • Persist and resume an agent's session state so an interaction survives restarts, and rebuild full context (including messages, tool calls, and reasoning) on a follow-up.
    • Managed agent memory
    • Remember a user's preferences, facts, and decisions across separate conversations, and personalize responses with what the agent learned earlier.

Legacy approaches​

The following earlier approach to agent memory is legacy and not recommended for new agents:

On this page