How do I add long-term memory to AI agents?

Summary

• Long-term memory allows agents to retain and learn from multiple conversations, not just a single session.
• Databricks provides two approaches: self-managed memory using Lakebase PostgreSQL backends, or fully managed agent memory with Unity Catalog governance.
• Lakebase integrates natively with Databricks authentication and scales automatically, storing agent state, insights, and knowledge across sessions.
• Agents improve over time as they accumulate memory, a pattern called memory scaling that can make memory infrastructure a valuable investment alongside model selection.
• Short-term memory (thread-based conversation context) and long-term memory (user insights, learned patterns) can be implemented together in a single agent.

How do I add long-term memory to AI agents?

Long-term memory is the difference between an agent that forgets you after each conversation and one that knows who you are, what you've asked before, and what matters to you. Databricks provides two clear paths to implement it: self-managed memory where you control the storage and retrieval, or fully managed memory where Databricks handles the infrastructure.

Short-term vs. long-term memory

Agents have two distinct memory needs. Short-term memory is conversation-scoped: thread IDs and checkpoints that keep an agent coherent within a single session. Long-term memory crosses sessions: persisted insights, user preferences, and patterns learned from past interactions. Both can coexist in the same agent.

Storage and implementation approaches

Databricks agents store memory in Lakebase, a fully managed PostgreSQL backend that integrates natively with your Databricks workspace. Lakebase is registered in Unity Catalog, so memory governance and access control align with your data policies.

Approach	When to use	What you manage
Self-managed (LangGraph + Lakebase)	You want full control over memory architecture and retrieval logic.	Memory schema, retrieval patterns, checkpoint strategy. Databricks handles provisioning and scaling.
Self-managed (OpenAI Agents SDK + Lakebase)	You prefer OpenAI's agent framework with stateful multi-turn conversation history.	Conversation state, reply logic. Databricks scales infrastructure automatically.
Managed agent memory	You want Databricks to handle all infrastructure and governance. Currently available as a beta feature.	Only your agent logic. Databricks manages the store, retrieval, and updates.

How Databricks approaches long-term memory

Databricks agents store three layers of long-term memory in Lakebase: system prompts and agent capabilities (the agent's skills), structured and unstructured enterprise assets (your knowledge base), and episodic and semantic memories (what the agent has learned). This persistent store is fed to the language model at each step and updated after each interaction.
For self-managed setup, clone pre-built templates from the Databricks app templates repository. The LangGraph template includes both short-term and long-term memory with durable state management and checkpointing; the OpenAI Agents SDK template provides stateful multi-turn conversations with automatic history. Both run natively on Databricks Apps and Model Serving.
For managed memory, Databricks handles provisioning and governance automatically, storing per-user, cross-session memory without you managing the underlying store.

Memory scaling and agent improvement

As agents accumulate memory, they improve. This pattern, called memory scaling, shows that agent capability grows with memory depth. Agents with rich memory stores can achieve better results than agents running with minimal context. Memory is persistent: each interaction updates the store, so agents improve over time as they see more patterns, user preferences, and domain knowledge.

Real-world scenarios

Customer support agent: The agent recalls every prior conversation with a customer. When they return, the agent doesn't re-ask for context; it continues with full history. The agent learns which responses work best for this customer's communication style.
Research assistant: The agent maintains a knowledge base of papers you've asked about, insights you care about, and your research direction. In month three, it surfaces connections between your past queries that you hadn't noticed.
Enterprise data agent: The agent stores learned patterns about which data sources are relevant for each department, which queries run efficiently, and which transformations your team prefers. New team members get better answers because the agent has learned institutional knowledge.

FAQs

Does long-term memory require me to build a custom database?

No. Databricks provides Lakebase as the default storage, and it's automatically scaled and governed in Unity Catalog. If you use self-managed memory with LangGraph or OpenAI Agents SDK, Lakebase is already wired in. For fully managed agent memory, Databricks provisions and maintains the store for you.

How much long-term memory can an agent store?

Lakebase scales automatically with your workload, so memory capacity depends on your Databricks compute and storage. Practically, agents can store conversation history, extracted insights, and learned patterns from hundreds or thousands of sessions without performance degradation.

What happens to memory when I deploy an agent to production?

Memory persists across deployments. When you update an agent and redeploy, the long-term memory stays in Lakebase, and the new agent version picks up where the old one left off. You can fork or restart from any checkpoint if needed.

Can different users have separate long-term memory in the same agent?

Yes. Memory is scoped by user and organization, so each user's insights are isolated. One agent instance can serve multiple users while maintaining separate memory contexts.

How do I retrieve or update an agent's long-term memory?

For self-managed memory, you write retrieval and update logic in your agent code using LangGraph checkpoints or OpenAI Agents SDK state management. For managed memory, Databricks handles updates automatically after each interaction; you access the memory through the agent's context window at runtime.