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:

• 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.
• 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

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.

Memory pipelines distill sessions into memories. A memory pipeline reads the conversations in a session store, extracts the durable facts, and writes them to a memory store, on demand or on a schedule. Use one to build memory from conversation history without adding memory-writing tools to your agent.

Sessions and memories connect at the point where something in a conversation is worth keeping. A memory pipeline, your agent, or your application distills the durable facts out of a session and writes them to memory. The session is later cleared or ages out, but 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

• • 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.
• • Agent memory
  • Remember a user's preferences, facts, and decisions across separate conversations, and personalize responses with what the agent learned earlier.
• • Agent memory pipelines
  • Distill long-term memories from the conversations in a session store, on demand or on a schedule, without adding memory-writing tools to your agent.

Legacy approaches

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

• Managed agent memory (legacy): the earlier managed memory store, governed by Unity Catalog.