Short Term Memory & Long Term Memory

[prasuanu1222]

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:

1. Short-term memory → Remember the current conversation and tool outputs so the next tool/step has full context.
2. 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

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

[Bitrip007]

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/

[Lu_Wang_ENB_DBX]

Use two layers:

1. Short-term: LangGraph checkpointer for thread/session state.
2. 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