Persisting an agent's intermediate memory or structured state

GenAI applications often need a persistent store to retain conversation history, agent memory, or structured intermediate outputs across sessions and requests. On Databricks, this is typically implemented using Delta tables in Unity Catalog, or lower-latency key-value/document stores integrated via Feature Serving or external online stores, so state survives beyond a single model invocation.

1 · Learn the must-know

• 1Delta tables in Unity Catalog are the standard Databricks-native option for durable storage of chat history, session state, or structured memory, giving ACID transactions, governance, and lineage.
• 2For low-latency read/write access needed in real-time agent interactions, Databricks Online Tables (backed by Feature Serving infrastructure) can expose Delta-managed data as a fast key-value store.
• 3Unity Catalog governs access control and lineage for any persistent datastore used by an application, so tables storing memory or intermediate state should be registered as UC-managed assets rather than ad hoc storage.
• 4Structured intermediate information (e.g., tool call outputs, retrieved context, agent scratchpad data) should be written using a defined schema so it can be queried, audited, and reused across pipeline runs.
• 5Storing conversation/session memory outside the model call is essential for multi-turn agent applications, since the serving endpoint itself is stateless between invocations.
• 6When persisting data from a Model Serving endpoint, writes should go through a governed path (e.g., a Databricks job, Lakehouse app backend, or feature-serving write path) rather than embedding storage credentials directly in the model artifact.

2 · Check your understanding