Series: Deepagent (8/10)

Long-Term Memory: Let the Agent Remember Important Information Across Conversations
When a conversation ends, most agents' state resets to zero.
The next conversation starts fresh — it doesn't remember the preferences you mentioned, doesn't know which work is already done, doesn't have the project context you provided. You need to re-explain everything, and it starts over. This is fine for short tasks, but when you're running long-term projects with an agent, the cost of "re-introducing yourself every time" adds up noticeably.
Long-term memory is what lets the agent carry important things across sessions.
How Long-Term Memory Works
Deep Agents' long-term memory is based on LangGraph Memory Store — a key-value storage layer accessible across threads and sessions.
The agent can actively perform two operations:
- Store: save information worth keeping from the current conversation into Memory Store
- Retrieve: at the start of the next conversation, pull relevant memories from Memory Store
Unlike filesystem tools: the filesystem is "the task's workspace," holding intermediate outputs of the current task; Memory Store is "the agent's long-term memory," holding information that has value across tasks and over time.
Basic Setup
from deepagents import create_deep_agent
from langgraph.store.memory import InMemoryStore
# Create memory storage (InMemoryStore for development, PostgresStore etc. for production)
memory_store = InMemoryStore()
agent = create_deep_agent(
tools=[...],
store=memory_store,
system_prompt="""You are a personal assistant.
Important principles:
- When users mention preferences, habits, or project background, store them to long-term memory
- At the start of each conversation, retrieve relevant memories to understand the user's situation
""",
)Passing store in gives the agent the ability to access Memory Store.
Using Persistent Storage in Production
InMemoryStore is for development — memories disappear when the program restarts. Production environments need a genuinely persistent backend:
from langgraph.store.postgres import PostgresStore
# Connect to PostgreSQL
memory_store = PostgresStore.from_conn_string(
"postgresql://user:password@localhost/mydb"
)
agent = create_deep_agent(
tools=[...],
store=memory_store,
)Other backends are also supported — the LangGraph official documentation has a complete list. The key point is the API is the same; switching backends doesn't require changing the agent's logic.
When the Agent Automatically Remembers
With an appropriate system_prompt, the agent will judge what's worth storing based on the conversation:
- Preferences the user explicitly states ("I prefer concise output formats")
- Project context ("this project is a TypeScript REST API")
- Completed work ("yesterday we finished the auth module")
- User work habits ("always produce a summary version after each analysis")
You can also more explicitly define in the prompt "what should be remembered" and "what doesn't need to be" — fine-grained control depends on your application scenario.
Managing Memory with Namespaces
As memories accumulate, using namespaces to separate different types of memory makes retrieval easier and maintenance cleaner:
# Agent can access memories across different namespaces
# Example: user preferences, project background, task history
agent = create_deep_agent(
tools=[...],
store=memory_store,
system_prompt="""Memory management rules:
- User preferences go in namespace: preferences
- Project information goes in namespace: projects/{project_name}
- Historical task summaries go in namespace: tasks/history
""",
)The benefit of namespaces is more precise retrieval — you don't need to load all memories, only pull what's relevant.
Long-Term Memory vs. Filesystem: Division of Responsibility
These two features can look similar, but they serve different purposes:
| Long-term memory (Memory Store) | Filesystem | |
|---|---|---|
| When to store | Information with cross-task value | Current task's intermediate outputs |
| What to store | User preferences, background knowledge, learned facts | Drafts, analysis results, working documents |
| Lifecycle | Long-term, cross-session | Usually follows the task |
| Who accesses | Agent's memory layer | Agent's workspace |
Simple decision rule: will this information be needed "next conversation"? If yes, put it in Memory Store. If it's only for this task, put it in the filesystem.
Quality Matters More Than Quantity
There's one common trap — trying to make the agent remember everything. This isn't a good strategy.
When there's too much memory:
- Retrieval noise increases, and relevant memories become harder to surface
- Old memories may not match the current situation, but the agent still uses them
- Storage costs and management complexity both increase
A better strategy is to establish "retention criteria" for memory — only store high-value, long-term stable information. Temporary or one-time things don't need to go into long-term memory.
Making this standard clear in system_prompt is more useful than "remember everything."
One Sentence Summary
Long-term memory transforms the agent from "a stranger every conversation" into "an assistant that knows you" — not remembering everything, but holding onto information that truly has long-term value.
Combined with the planning capability, filesystem management, and subagents from previous articles, the agent now has a fairly complete operational foundation. The next article covers the Skills system — teaching the agent your standards and preferences.
Previous: Subagents: Delegate Complex Tasks with the task Tool Next: The Skills System: Teach Your Agent Your Standards and Preferences