Deep Agents Memory: A Production Setup That Survives Sessions

Deep Agents memory is filesystem-shaped, but persistence depends on the backend behind those files. The default StateBackend keeps files inside one thread. A StoreBackend makes selected paths durable across threads. A local FilesystemBackend writes real files, but should not be exposed unscoped in a deployed agent.

That distinction is the difference between “the agent wrote a note” and “the next session can safely use it.” For durable project knowledge, go one step further: make the source of truth files that people and multiple agents can read, edit, review, and self-host—not only records or embeddings hidden behind one runtime. Meshnote provides that shared Markdown layer over MCP while Deep Agents handles its own thread state and agent-specific behavior.

What Deep Agents actually persists

Deep Agents uses a virtual filesystem for context management, memory, skills, and large intermediate results. Its current documentation separates three useful backends:

StateBackend: thread-scoped files saved with graph state. They survive turns when a checkpointer is configured, but are not shared with a new thread.
StoreBackend: virtual files backed by a LangGraph store. These can survive across threads and should be namespaced by user, assistant, organization, or a combination.
FilesystemBackend: real disk access under an absolute root. It is convenient locally, but the production guidance warns against giving deployed agents direct host access.

CompositeBackend routes paths to different backends. This is the production-friendly pattern: keep scratch artifacts ephemeral, persist only /memories/, and isolate that route by identity. This complements the broader LangGraph memory model, where checkpointers preserve a thread and stores preserve cross-thread knowledge.

Runnable cross-session setup

The following Python example follows the current Deep Agents API. It routes only /memories/ to a durable store namespace and leaves other generated files in thread state. InMemoryStore proves cross-thread behavior within one process; replace it with your configured persistent LangGraph store in production. Set the model provider credential required by your selected model before running it.

python -m venv .venv
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
pip install deepagents langgraph

from deepagents import create_deep_agent
from deepagents.backends import CompositeBackend, StateBackend, StoreBackend
from langgraph.store.memory import InMemoryStore

store = InMemoryStore()
agent = create_deep_agent(
    model="openai:gpt-5.2",
    store=store,
    backend=CompositeBackend(
        default=StateBackend(),
        routes={
            "/memories/": StoreBackend(
                namespace=lambda _runtime: ("demo-user", "project-alpha")
            )
        },
    ),
    memory=["/memories/AGENTS.md"],
    system_prompt="""Use /memories/AGENTS.md for durable project facts.
When a fact changes, edit the existing entry instead of appending a conflict.
Never store secrets, credentials, or raw conversation transcripts.""",
)

first = agent.invoke(
    {"messages": [{"role": "user", "content":
        "Remember that Project Alpha deploys only after /health/ready passes."}]},
    {"configurable": {"thread_id": "thread-1"}},
)
second = agent.invoke(
    {"messages": [{"role": "user", "content":
        "What is Project Alpha's deployment gate?"}]},
    {"configurable": {"thread_id": "thread-2"}},
)
print(second["messages"][-1].content)

The important proof is the changed thread_id. Reusing one thread tests conversation continuity, not long-term memory. Also note that an in-memory store does not survive a process restart; production persistence requires a real store or the store provisioned by LangSmith Deployment.

The missing design decision: who owns each fact?

Most setup guides stop once a second thread recalls a preference. Production systems need an authority boundary. Use Deep Agents memory for agent behavior and user-scoped preferences. Put shared project truth in a repository or an agent-agnostic knowledge system. Otherwise the same deployment rule can diverge across assistants, users, and coding tools.

Information	Best home	Why
Current plan and tool output	StateBackend / thread	Temporary and execution-specific
User tone preference	User-scoped StoreBackend	Personal and cross-session
Agent response policy	Read-only agent or organization memory	Always loaded; writes should be controlled
Architecture decision or runbook	Reviewed Markdown project wiki	Shared, attributable, diffable, and portable
Semantic recall over many events	Vector or graph memory	Flexible retrieval when exact filenames are unknown

This two-store design is not duplication if one source is explicitly authoritative. A Deep Agent may cache a short pointer such as “deployment policy is in the project wiki,” but should not maintain a competing copy. The same principle supports shared memory across AI tools: clients can change without moving the project’s canonical knowledge.

How Deep Agents compares with other memory systems

Option	Strong fit	Trade-off
Deep Agents memory	Filesystem-shaped context, scoped backends, skills, and tight LangGraph integration	Application code still owns backend durability, namespaces, and write policy
Mem0	Automatic extraction and semantic retrieval across conversations	Retrieved memory is less naturally reviewed as a maintained document set
Zep / Graphiti	Temporal facts, relationships, and point-in-time graph retrieval	More infrastructure than teams need for a small set of project rules
Letta	Stateful agents that actively manage memory blocks and archival context	Memory is closely coupled to the agent runtime
Native ChatGPT or Claude memory	Low-friction personalization inside one product	Limited cross-tool control and portability
Meshnote	Readable Markdown, history, human correction, self-hosting, and MCP access	Deliberate curation is less automatic than extraction-first systems

These approaches can be combined. Use a retrieval system for high-volume observations, Deep Agents memory for runtime-specific preferences, and Meshnote for decisions that must remain inspectable and reusable by other agents. The vector memory versus readable memory guide covers that storage-versus-index distinction in detail.

A six-case memory acceptance test

Run this before calling any setup persistent:

Cross-thread: write a harmless preference in thread A and retrieve it from thread B.
Restart: restart the process and retrieve it again. This catches accidental use of InMemoryStore.
Isolation: query as a second user and confirm the first user’s memory is absent.
Correction: replace a fact, then verify retrieval returns the new value without presenting the old value as current.
Write control: ask the agent to modify an organization policy and confirm the backend or permission rule denies it.
Exit: export or inspect the durable knowledge without running the original agent. Confirm a human can reconstruct current policy and provenance.

The last test exposes the practical difference between persistence and ownership. A value can survive forever while remaining hard to audit, migrate, or repair. For a fuller lifecycle, use the promotion, correction, expiry, and recovery checks in the persistent LLM memory architecture.

Recommended production pattern

Keep scratch files and large tool results in StateBackend.
Route only durable memory paths through StoreBackend.
Namespace by both assistant and authenticated user unless sharing is intentional.
Make organization policy read-only and validate all agent-authored writes.
Promote stable project decisions into a reviewed, readable knowledge base.
Test correction, tenant isolation, restart persistence, and export in CI.

This gives Deep Agents fast, native memory without making one runtime the only place your organization can understand its own decisions. If several agents need the same project truth, connect them to Meshnote over MCP. Start syncing — $8/mo, or choose Self-hosted for teams from $10/seat/month.