Context, State, Memory, and Checkpoints

Model input, execution state, reusable memory, and recovery snapshots need different rules for selection, updates, and retention.

Lifetimes and responsibilities

Consider an agent that resumes after an interruption while preparing a report. A conversation summary saying "report complete" does not identify its location or confirm delivery. Feeding every execution record into the next model call also makes the model read work that is already finished.

Context, State, Memory, and Checkpoint separate these concerns by how information is used. They mean model input, execution state, reusable knowledge, and recovery snapshots, respectively. The distinction depends on who reads and updates the information, rather than its file format.

This classification explains design responsibilities; frameworks do not all use the same names. LangGraph's persistence documentation calls stored conversation state short-term memory. It distinguishes this from a separate store for long-term information shared across conversations, as checked in September 2026.

Context selection and compaction

Context is the input a large language model (LLM) directly receives for a particular call. It includes the instructions, messages, tool descriptions, and retrieved material actually included in that request. A fact stored in a database is not directly available to the model in that call until the application brings it into the input.

Anthropic's context engineering article describes input selection and compaction of long conversations. Compaction removes repetition but can also remove conditions needed later. Verification must check what survives, as well as how short the summary becomes.

For the report example, retained information could include accepted evidence, source identifiers, unresolved objections, and submission requirements. The full text of processed search results can remain at a retrievable source location. Keeping only a summary removes the means to check a fact that was summarized incorrectly.

Compacting Context does not automatically shrink the stored State. The code that builds model input can select specific State fields or use a separate summary. The application must decide what to exclude from that input.

State updates and execution facts

State is structured data used to determine execution progress. It holds control values such as the current phase, completed work, artifact identifiers, and remaining budget. Keeping these values explicit makes transition conditions easier to define, even when the application also stores the full conversation.

For example, changing a report from "awaiting review" to "delivered" requires an actual delivery result. A transition based only on the model's completion statement could overlook a failed tool call. The recommended design here lets the model propose changes while execution code checks results and conditions before updating State.

State must also be distinguished from the external system's current condition. A record can say that a file was saved even after another user has deleted it. External facts needed for reuse require another lookup; the record alone cannot guarantee current existence or access.

Memory write policies

Here, Memory means long-term information intended for reuse in later work. Examples include output preferences and verified rules for recurring tasks. Storing failed search results or temporary hypotheses as facts passes those errors into later decisions.

The timing of memory writes is also a design choice. LangChain's memory overview distinguishes writes during execution from writes performed in a separate background task. Immediate writes can inform the next decision but add work to the response path; background writes can leave readers waiting for the latest information.

For a report preference, useful metadata includes its source, scope, and confirmation time. Establish whether "use a short format" applies only to this request or to future reports as well. Define permission to retain it, its validity period, and how conflicting requests will be resolved before storing it.

Writing Memory to a file or search index does not automatically place it in the next Context. The application must retrieve relevant information, assess its applicability, and include it in the input. Even a highly ranked memory should not be applied unchanged when it conflicts with the current request.

Checkpoint recovery boundaries

A Checkpoint records State at a particular point together with information needed to resume execution. Its purpose is to restore a continuation point, which differs from summarizing an earlier conversation. Recovery design must specify when to save, where to save, and which execution boundaries support resumption.

LangGraph's persistence documentation explains that checkpoints held only in memory disappear when the process ends. Recovery across process failure requires persistent storage.

A Checkpoint does not undo external actions. Report delivery might succeed just before the process stops, leaving its completion unsaved. Resuming from the earlier Checkpoint could execute delivery again.

An operational design for this case retains an external operation identifier and checks whether the operation completed before resuming. It should also consider idempotency, where repeating a request does not duplicate its effect. An idempotency key only helps when the system performing delivery recognizes repeated uses of that key.

Storage and resumption criteria

A recovery test needs to do more than read saved data. It must establish whether the agent can select the next action without repeating external work. For the report example, interruptions immediately before and after delivery are distinct cases to check.

These criteria do not require separate databases. A shared store can still support different update owners, retention periods, and read paths. Start with a small implementation while keeping a conversation summary from carrying every responsibility.

Summary

Context supplies the current decision, while State controls execution progress. Memory preserves information for later work together with the conditions under which it applies. A Checkpoint provides a recovery point but does not reverse changes in external systems. Distinct lifetimes and update responsibilities allow smaller model inputs, continued execution, and protection against duplicate actions.