topic Re: Short Term Memory & Long Term Memory in Generative AI

Short Term Memory & Long Term Memory

prasuanu1222 — Thu, 16 Jul 2026 13:37:47 GMT

I am building an Agentic Application on Databricks using LangGraph (Classic Compute — Serverless cant be used so Agent Brickscant be used ).

I want my agent to have two types of memory:

Short-term memory → Remember the current conversation and tool outputs so the next tool/step has full context.
Long-term memory → Remember user preferences and behavior across sessions, so the next time the user logs in, the agent already knows them.

What I Need Help With

Recommended Delta table design for long-term memory (preferences, facts, summaries)? - how to design it
How to move data from short-term → long-term (when and what to save)?
How to load long-term memory back into the agent when the user logs in again?
Any reference examples or notebooks from Databricks for this pattern?

Re: Short Term Memory & Long Term Memory

Bitrip007 — Thu, 16 Jul 2026 15:08:39 GMT

Since you're using LangGraph on Databricks Classic Compute, you don't have Agent Bricks or Managed Agent Memory. I would build the memory layer directly on Delta Lake + Unity Catalog. This gives you full control, is scalable, auditable, and integrates naturally with Databricks.

In fact, the architecture is almost identical to how Databricks' newer self-managed memory works internally, except they use Lakebase/Postgres instead of Delta. The underlying concepts—thread memory, semantic memory, episodic memory, and memory consolidation—are the same.

I recommend never writing directly to long-term memory from every node. Instead, add a dedicated Memory Consolidation Node at the end of the graph.

Memory Layers

Instead of a single table, split memory into specialized Delta tables.

catalog.agent_memory

conversations
episodic_memory
semantic_memory
user_profile
memory_embeddings

1. Short-Term Memory (Conversation State)

Short-term memory should only exist during the current conversation and should be managed by LangGraph State/Checkpointing.

It should contain:

Conversation messages
Tool outputs
SQL query results
API responses
Intermediate reasoning
Planner outputs
Scratchpad/context

This memory is automatically passed between LangGraph nodes.

3. Semantic Memory (Long-Term Facts & Preferences)

This is the most important long-term memory.

Store only durable knowledge about the user.

Examples

User prefers SQL over explanations
User prefers charts over tables
User works with Databricks
User works in Retail Analytics
User prefers concise responses
User timezone is IST

Recommended Four-Layer Memory Model

For a production-grade implementation, I recommend extending beyond just short-term and long-term memory into four complementary memory types:

Memory Type Purpose Storage

Working Memory	Current conversation, intermediate reasoning, tool outputs	LangGraph State / Checkpoint
Semantic Memory	User preferences, permanent facts, profile	Delta Lake + Vector Search
Episodic Memory	Summarized past sessions, important experiences	Delta Lake
Procedural Memory	Reusable workflows, SQL templates, preferred tool sequences, successful reasoning patterns	Delta Lake (versioned)

This design closely aligns with Databricks' self-managed memory concepts while remaining fully compatible with LangGraph running on Databricks Classic Compute.

Reference Links:

Databricks Stateful Agents – https://docs.databricks.com/aws/en/agents/agent-framework/stateful-agents
Databricks Self-Managed Agent Memory – https://docs.databricks.com/aws/en/agents/agent-memory/self-managed-memory
LangGraph Memory Guide – https://docs.langchain.com/oss/python/langgraph/add-memory
LangGraph Conversation Memory Management – https://langchain-ai.github.io/langgraph/how-tos/memory/manage-conversation-history/

Re: Short Term Memory & Long Term Memory

Lu_Wang_ENB_DBX — Wed, 22 Jul 2026 00:12:48 GMT

Use two layers:

Short-term: LangGraph checkpointer for thread/session state.
Long-term: for your case, prefer Databricks Managed Memory if available; otherwise use self-managed Lakebase. Managed memory is the simplest cross-session option and works with LangGraph; short-term should still stay in the LangGraph checkpointer.

Delta design for long-term memory

If you specifically want Delta tables, keep them simple and semantic:

user_memories
- user_id
- memory_type (preference, fact, summary)
- topic (timezone, formatting, project, etc.)
- memory_text
- source_session_id
- importance
- confidence
- created_at
- updated_at
- expires_at nullable
- is_active

Optional:

memory_events for raw append-only writes/audit
session_summaries for one summary per conversation/session

Design rule: store distilled facts/preferences/summaries, not every message. Databricks internal guidance also separates semantic memory such as facts/preferences from short-term session state and recommends fewer long-term objects than short-term ones.

Short-term → long-term: what and when

Save to long-term only when the info is:

stable user preference
reusable fact
durable project context
end-of-session summary

Do not save transient tool output or every turn. Internal notes explicitly say long-term write does not need to happen every step and should be smaller than short-term memory.

Good trigger points:

explicit user statement: “I prefer…”, “Remember that…”
session end
after task completion
periodic background summarization/consolidation job

Load long-term on next login

At app start:

identify user_id
fetch top memories for that user
inject only the most relevant ones into the prompt/context
keep the rest searchable as a tool

For managed memory, Databricks recommends per-user scope and searching within that scope; one agent can also read personal scope plus shared org scope.

Best references

Managed agent memory docs — best current reference for cross-session memory with scope/path model.
agent-langgraph-advanced template — shows AsyncCheckpointSaver for short-term and AsyncDatabricksStore for long-term in LangGraph.
Lakebase AI Integration hands-on lab — explicitly covers short-term with CheckpointSaver and long-term with DatabricksStore for LangGraph.

Recommendation

For classic compute + LangGraph:

use LangGraph checkpointer for short-term
if allowed, use Managed Memory for long-term
if you must build it yourself in Delta, use one distilled user_memories table + optional session_summaries table, and write only curated memories