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:

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/

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