What should a conversation remember, and for whom?

A visitor tells your assistant their preferred workshop time. After a page refresh, the preference disappears. On another test, the next visitor sees it. These are different memory failures: one loses state, and the other shares it with the wrong person.

Before you begin: Understand authentication boundaries, context limits, and agent state.

Name the kind of memory

Conversation history stores messages for a thread. A working state stores current task facts such as a selected room or unresolved question. Long-term memory stores information intended for use across sessions. A summary compresses earlier material. A model's learned parameters are another mechanism entirely.

Do not use “memory” as if it were one feature. For each item, decide what is stored, where, for how long, how it is retrieved, and who may use or delete it. These decisions shape the user experience more than the name of the framework class.

Scope a thread to an identity

Current LangChain agents use graph state and checkpointers for short-term memory. A thread identifier selects the conversation state. The application must ensure that the authenticated user can access that thread. A client-provided thread ID is not proof of ownership.

For a two-user test, create separate threads and distinct harmless facts, such as preferred session times. Ask each thread for its fact, refresh, and repeat. Then attempt to use the other thread ID. The server should reject unauthorized access before any history is loaded into the model.

Persistence needs a storage implementation

An in-memory checkpointer is useful for local development but loses data when its process ends. A durable backend can preserve state across restarts if configured correctly. You still need schema setup, credentials, concurrency behavior, backups, and lifecycle policies appropriate to the application.

The existence of a checkpointer does not automatically make external tool actions exactly-once. If a node is retried after a crash, an external effect may already have occurred. We will handle action identity and reconciliation in later workflow lessons.

Decide what enters the context

Stored history can exceed the model's context budget. Select recent messages, retrieve relevant facts, or summarize earlier material. Each approach loses or changes information in a different way.

A summary should preserve task constraints and unresolved uncertainty. “The visitor prefers afternoons but cannot attend Friday” must not become “prefers Friday afternoon.” Keep source messages available where important and test summaries on negation, corrections, and conflicting preferences.

Long-term memory should not turn every sentence into a permanent personal fact. “I might prefer mornings next month” is tentative and time-bound. Record provenance and allow correction or deletion when the product stores user preferences.

Work through a correction

Turn one says, “Use Room 4.” Turn two says, “Correction: use Room 8; Room 4 is unavailable.” The current task state should identify Room 8 as selected and preserve why the earlier value was replaced. Blindly appending both facts without a resolution rule can confuse later retrieval.

If multiple requests update the same thread concurrently, define how conflicts are handled. An older response arriving late should not overwrite a newer user correction. This is application state management, not something a more expressive prompt can reliably fix.

Test what survives a restart

Save a harmless thread fact, stop the process, restart it, and ask for the fact using the same authorized thread. A local UI refresh alone may leave the server process alive, so it does not prove durable storage.

Next, you will build a small application whose input, evidence, and response can be inspected without a large framework scaffold.

Reference

The current LangChain short-term memory guide documents checkpointers and thread state. Use the documentation for your selected persistent backend rather than presenting an in-memory example as durable production storage.

Continue to the next lesson.