Long-Term & Agentic Memory: overview

Dana returns to Larkspur in a new conversation and expects the assistant to remember her plan and earlier work. You will choose the scope and writer of each memory layer, retrieve old facts and distinguish stored information from executable skills. The tutorials cover namespaces, semantic and episodic memory, procedures, tiered context and skill libraries.

The running example is a support assistant for Larkspur Cloud, the fictional host whose handbook T5.1 to T5.3 index. Dana runs a shop on an annual business plan. She tells the assistant facts about herself, comes back days later in a new chat, and asks billing questions the handbook answers: refunds within 30 days of purchase under 100 GB of outbound traffic, exports from Settings, then Data. The memory questions are the ones the T10.2 lab brief asks for: in a new thread, does the assistant still know her plan, and what it helped her with last time?

• A LangGraph Store holds JSON items under a namespace tuple and a key, shared by every thread. The namespace, built from trusted ids the server passes in the run's context, is what keeps one customer's memory away from another's.
• Semantic memory upserts facts under stable keys, episodic memory appends one item per event and prunes, procedural memory stores versioned instructions that a human approves through interrupt(). Same store, three write rules.
• Code should write the layers the model forgets. In the capstone's test runs gpt-4o-mini never called a save_episode tool (0 of 6), so a graph node records the episode after every answer.
• Preloading every item stops working as memory grows: search() returns 10 items unless you pass limit=, and every item costs prompt tokens on every call. Past that point, recall by similarity (an embedding index) or by graph traversal.
• MemGPT tiers make the agent manage its own context. In the lab, a 6-message window pages 5 of 11 messages to the archive by turn 6, and whether the agent gets a fact back depends on the words of its own search query.

Every turn reads memory before the model runs and writes it after. The ids decide which namespaces a turn can touch, so they come from the login and the visit, never from the conversation. Each layer has one writer: the model for facts, a graph node for episodes, the app for session items and a human for procedures.

The window and the archive: open the file in a browser. Start at a window of 6 and query outbound traffic: Dana's turn-2 message is in the archive and comes back at rank 1. Switch the query to how much traffic? and it is gone, because traffic? never matches traffic. Then slide the window to 9: the message is back in view with no search at all, and the prompt has grown from about 117 to about 156 tokens of conversation on every call.

• Before: T4.4 teaches the checkpointer and interrupt() that procedural memory reuses. T10.1 gives an agent memory inside one thread; this module adds memory across threads. T5.4 and T5.5 cover the embeddings and vector indexes behind recall by similarity, and the golden-set method from T5.1 is how you measure whether memory helps.
• Next: T11.1 to T11.3 give several agents shared and private memory. T13.2 stores graph memory in Neo4j, which lesson 4 of T10.2 previews.

• Scope memory by namespace and take every id from trusted server input. The model never chooses whose memory it reads.
• Give each layer its own write rule and its own writer: upsert facts by key, append and prune episodes, expire session items, and let a human approve procedures.
• Write in code what the model forgets to write, and let code make the final yes or no on what counts as a task or a fact.
• Preload while memory is small; once it outgrows the prompt, recall by similarity or traversal, and measure that recall on cross-thread questions.