Three mechanisms, one word: how "the agent remembers" hides your resume bug

A dev.to post published under the handle mahakfaheem pulls apart three terms that most teams collapse into one: state is what is true for an agent execution at a particular point, memory is information retained so it can be useful later, and checkpointing is the mechanism used to persist execution state at defined points ^[0][2][3][4]. The author's argument is that the three are closely related, that some frameworks deliberately connect them, and that they are still not interchangeable ^[5].

The collapse happens in speech first. When an agent recalls a user's name, resumes an interrupted task, or knows which tool it called a moment ago, we say it has memory, and that single word hides several different mechanisms ^[6].

Look at what the post says can sit in state: conversation messages, current task, intermediate results, tool outputs, the next step to execute, retry counters, approval status, retrieved documents, generated artifacts, and errors encountered during execution ^[7]. That is ten kinds of data ^[19], and several of them are not beliefs about a user at all. They are positions in a workflow. The worked example is a travel agent holding destination Jaipur, travel dates in November 2026, a budget of 40000, hotel_search_completed set to False and waiting_for_user_approval set to True ^[8]. The post models the agent as a system that repeatedly moves from current state through a step to an updated state, with tool calls, model responses, human decisions or workflow rules doing the updating: no destination selected, destination selected, flights retrieved, waiting for approval, booking confirmed ^[10][11].

State also does not have to live in the context window. It can sit in application memory, a database, a workflow engine or another persistent system, with the model receiving only a selected portion when it is invoked ^[9]. So "the agent remembers" often means the database remembers and the model was handed a slice.

Memory in the post is a separate axis: short-term maintains continuity inside one thread, which is what lets "can you find hotels there" resolve to Jaipur ^[13][14], while long-term survives beyond a thread and carries things like a preferred airline and a meal preference for user_42 into a new conversation ^[16][17]. And memory, the author notes, requires selection ^[18].

The fusion point is named explicitly: in LangGraph, short-term memory is maintained as part of the thread's state and can be persisted through checkpoints ^[15]. That is a defensible design, and it is also why one vocabulary ends up covering two different obligations. A single durability mechanism carries both conversational recall and workflow position, so restoring "memory" also restores assertions about the outside world. A checkpoint holding flight_options and waiting_for_user_approval: True ^[8] is a claim about what was true when it was written. Resume it later and the flags come back as crisp as the day they were saved; the flight prices behind them do not. Nothing in the definition of checkpointing as persisting execution state at defined points ^[4] distinguishes a durable fact from a perishable observation.

The replay problem sits in the same gap. The transition model puts a step between two states ^[10]. If the checkpoint lands on the state boundary and the step in between calls a booking API, resuming from that boundary runs the step again. The excerpt ends mid-sentence inside the memory section ^[18], so it never reaches that question. Read the one-line checkpointing definition as a definition, not as a design.

Worth checking in your own graph: whether anything sourced from an external system carries a read timestamp, whether tool calls that cause effects are keyed so a second attempt is a no-op, and what your approval flag means on restore. On the post's own example, waiting_for_user_approval ^[8] is the field most likely to wake up in a world where the human already answered.