If you've built a chatbot before, you probably assumed "memory" meant "keep appending messages to the prompt." That intuition breaks down fast once you start building real agents, and this week is about replacing it with a more precise mental model — one that matches how production frameworks like LangGraph and LangMem actually implement memory.
The single biggest mindset shift this week: in LangGraph, memory is part of the graph's state, not a separate object bolted onto the agent. Every LangGraph agent runs as a graph, and that graph carries a state object as it moves between nodes. Short-term memory — the conversation history and tool outputs accumulated within a single thread — persists because a checkpointer saves that state after every step. When you resume a thread by its thread_id, the checkpointer loads the saved state back in, and the agent picks up exactly where it left off. This is why swapping checkpointer backends (say, from an in-memory saver to a SQLite-backed one) doesn't change your agent logic at all — it only changes where the state snapshots live. Long-term memory is a different mechanism entirely. It persists across sessions and threads, not just within one, and it lives in a store organized by namespace + key — conceptually similar to a filesystem path plus a filename. A namespace might be (user_id, "preferences"), and within it you write and read individual memory keys. Because the store is addressed independently of any thread, an agent can start a brand-new conversation tomorrow and still recall what it learned about you today.
Long-term memory itself isn't a single bucket. It splits into three types, each doing different work:
| Type | What it stores | Example | Effect on the agent |
|---|---|---|---|
| Semantic | Stable facts and preferences about the world or the user | "The user prefers Python over JavaScript" | Personalization, consistency |
| Episodic | Specific past experiences/interactions to retrieve and adapt from | "Last time this error occurred, restarting the worker fixed it" | Learning from precedent — reactive → adaptive |
| Procedural | Workflow templates, tool-use policies, standard operating procedure | "Always confirm before deleting a record" | Consistent execution, encoded skill |
Episodic memory deserves special attention because it's the type that moves an agent from reactive (respond to the current input) to learning (recognize "I've been here before" and adapt its approach). Without it, every session starts from zero experience even if the agent has run the same task a thousand times.
A common misconception is that vector search alone is "memory." The actual retrieval pattern has several stages: new input is embedded into a vector; the vector store returns the K nearest neighbors purely on embedding distance, with no awareness of recency; those raw candidates are then filtered by namespace (so you don't retrieve another user's memories) and by recency (discarding stale or superseded facts); and finally the survivors are ranked by a combined relevance-and-recency score before being injected into the context window. Skipping the filter/rank steps is how agents end up confidently repeating outdated preferences — the nearest embedding was simply the oldest.
This week's core misconception to correct: "a big context window is the agent's memory." It is not. The context window is working memory — think RAM, not persistent storage. Everything in it vanishes the moment the session ends. Worse, research on long-context models consistently shows that information placed in the middle of a long context is often under-weighted or ignored entirely — the so-called "lost in the middle" effect. That means even a model that technically fits your entire chat history in-context may still fail to act on a preference you mentioned 40 turns ago. A closely related misconception: "just use a model with a bigger context window instead of building memory." Even frontier long-context models get distracted by stale or irrelevant content, and measured performance often degrades well before the advertised token limit. Long-term memory is not "cram more tokens in" — it's storing information externally, then retrieving only the relevant slice back into context when it's actually needed. A 2-million-token context window does not replace a well-designed store; it just delays (and sometimes masks) the failure. Finally, don't conflate the two systems: short-term and long-term memory are distinct mechanisms, not one thing called "agent memory." An agent that only has short-term (checkpointed) memory forgets everything between sessions. An agent that shoves everything into long-term storage and re-injects it all every turn re-creates the "lost in the middle" problem inside a permanently bloated context. Most real production failures attributed to "the model isn't smart enough" are actually memory-architecture failures — the right fact existed somewhere, but the retrieval/consolidation pipeline never surfaced it at the right moment.
LangMem is LangChain's dedicated long-term memory library. It extracts durable facts out of raw conversation transcripts, works with arbitrary storage backends (so you aren't locked into one database), integrates natively with LangGraph's state and store abstractions, and ships real-time memory-management tools suited for production traffic rather than notebook demos. All of this leads to the single most consequential design decision in agent memory architecture: the consolidation policy — the rule that decides when and how information graduates from short-term conversation into the long-term store. Consolidate too aggressively and you pollute long-term memory with one-off, low-value chatter. Consolidate too conservatively and the agent never learns anything durable. We'll design one of these policies together in this week's discussion.