On 16 September 2026 Databricks put managed agent memory and managed agent sessions into beta (release notes). Both are fully managed stores for agent state, both are backed by Lakebase, and the note says they work from agents built on any framework. Memory is durable and long-term, persists across conversations and supports semantic search. Sessions hold conversation history that an agent reads at the start of a turn and appends to as it runs.
The part everyone writes themselves #
Every agent that does more than answer one question needs two things the model doesn't give it.
It needs to know what happened earlier in this conversation, and it needs to know what it learned about this user last month. Teams build both. The session store is usually a table or a Redis instance with a TTL, the memory store is usually a vector index with some hand-rolled logic about what's worth keeping, and neither gets the attention it deserves because neither is the interesting part of the project.
Then the agent goes to production and the state layer is where the problems live. Sessions that grow until a turn costs more than it should. Memory that never forgets something a user asked it to forget. Two agents that each keep their own copy of what they know about the same customer. None of that is hard to fix once, and all of it is tedious to fix in five places.
Why Lakebase underneath matters #
The release note names Lakebase as the backing store for both. That's the second time this month Lakebase has shown up as infrastructure underneath another Databricks feature, and it tells you how Databricks is thinking about it. The Lakebase chapter describes a Postgres that sits under your application. This is Databricks putting its own features on that Postgres.
For a team, the practical consequence is that agent state lands somewhere you can query. Conversation history in a real database is something you can join, audit and delete on request. That last one matters more than it sounds. When a customer asks what an agent remembers about them, a row in Postgres answers it with one query, and an opaque embedding blob turns it into a project.
Questions to ask before users depend on it #
The note says nothing about cost, retention controls, or what happens to memory when the underlying Lakebase project is branched or restored. It says nothing about limits on how much a single agent can remember. Those are the questions to ask before anything with real users depends on this, and we'd expect answers before general availability. It also leaves open what to remember, which is the actual hard problem. A managed store with semantic search will happily hold everything an agent ever saw, and an agent that recalls everything is worse than one that recalls the right five things. That judgment stays yours.
Where this lands in the guide #
This goes in Agents on Databricks, which currently treats state as something you bring. It touches Orchestrating Agents too, because shared memory across a set of agents is a different design than memory per agent, and a managed store makes the shared version easy enough that teams will reach for it without deciding they have.
Decide it deliberately.