Skip to main content
Deep Agents use their filesystem to store and retrieve information. How long that information is available for depends on which backend you configure.

Short-term memory

By default, the agent’s filesystem uses StateBackend, which stores files in the LangGraph thread state. Files persist across turns within a single conversation but are lost when the conversation ends. This is useful for scratch work (drafts, intermediate results, working notes) that the agent doesn’t need to remember later.

Long-term memory

To persist information across conversations — user preferences, learned instructions, project context — use a CompositeBackend that routes /memories/ to a StoreBackend. The agent’s scratch files stay ephemeral while anything written to /memories/ persists in a LangGraph Store.

Setup

You can extend Deep Agents with long-term memory by using a CompositeBackend that routes specific paths to persistent storage. This enables hybrid storage where some files persist across threads while others remain ephemeral.

Setup

Configure long-term memory by using a CompositeBackend that routes the /memories/ path to a StoreBackend:

Namespace scoping

The namespace parameter on StoreBackend controls who can see what data. See namespace factories for the full API. For deployed agents, always set a namespace factory to isolate data.

Cross-thread persistence

Files in /memories/ can be accessed from any thread:

Path routing

The CompositeBackend routes file operations based on path prefixes:
  • Files with paths starting with /memories/ are stored in the Store (persistent)
  • Files without this prefix remain in transient state
  • All filesystem tools (ls, read_file, write_file, edit_file) work with both
CompositeBackend strips the route prefix before storing. For example, /memories/preferences.txt is stored as /preferences.txt in the StoreBackend. The agent always uses the full path. See CompositeBackend for details.

Accessing memories from external code

If deploying your agent on LangSmith Deployment, you can read or write memories from server-side code (outside the agent) using the Store API. The namespace you use must match the one configured in your StoreBackend namespace factory. The examples below use the default legacy namespace (assistant_id, "filesystem").
When using CompositeBackend, the key does not include the /memories/ prefix because the route prefix is stripped before storing. See Path routing for details.
For more information, see the Store API reference.

Use cases

The examples below omit the namespace parameter for brevity. In production, always set a namespace factory on StoreBackend to isolate data per user or tenant.

User preferences

Store user preferences that persist across sessions:

Self-improving instructions

An agent can update its own instructions based on feedback:
Over time, the instructions file accumulates user preferences, helping the agent improve.

Knowledge base

Build up knowledge over multiple conversations:

Research projects

Maintain research state across sessions:

Store implementations

Any LangGraph BaseStore implementation works. When deploying to LangSmith Deployment, the platform provisions a store automatically — you don’t need to configure one yourself.

InMemoryStore (development)

Good for testing and development, but data is lost on restart:

PostgresStore (production)

For production, use a persistent store:
Files stored via StoreBackend use the following schema:
You can use the create_file_data helper to create properly formatted file data:
For more details on backend protocols, see Backends.

Best practices

Use descriptive paths

Organize persistent files with clear paths:

Document the memory structure

Tell the agent what’s stored where in your system prompt:

Prune old data

Implement periodic cleanup of outdated persistent files to keep storage manageable.

Choose the right storage

  • Development: Use InMemoryStore for quick iteration
  • Production: Use PostgresStore or other persistent stores
  • Multi-tenant: Set a namespace factory on StoreBackend to isolate data per user (for example, namespace=lambda ctx: (ctx.runtime.context.user_id,))