Agent State, Memory & Checkpointing: Three Things That Sound Similar but Aren’t

A developer explains the distinctions between agent state, memory, and checkpointing in AI agents, emphasizing that while related, they serve different purposes. The post clarifies that state is the current execution data, memory is retained information influencing future behavior, and checkpointing is the persisted representation of state for resuming workflows.

Hi. While making my agents orchestrate, remember, resume or anything for that matter, I found myself thinking about how naturally we do some of these things ourselves. We register things, retain some, forget some, recall what matters and somehow continue from where we left off. And somewhere in trying to make agents do a version of that, I kept running into three terms: state, memory and checkpointing. I understood what each did individually, but somewhere between building workflows and making them persist, their boundaries started to feel a little fuzzy. The more I worked with them, the more I realised the distinction matters. So, I wanted to break them down, starting from the simplest way I understand them. So, let’s untangle them a little. When an AI agent remembers a user’s name, resumes an interrupted task, or knows which tool it called a moment ago, we often say the agent “has memory.” But that single word hides several different mechanisms. State, memory and checkpointing are closely related and some frameworks deliberately connect them. They are not, however, interchangeable. A simple way to begin is: The distinction matters because each solves a different problem. 1. Agent state State is the data carried through an agent’s execution. It may include: Consider a travel-planning agent. Its state might look conceptually like this: state = { "messages": ... , "destination": "Jaipur", "travel dates": { "start": "2026-11-04", "end": "2026-11-10" }, "budget": 40000, "flight options": ... , "hotel search completed": False, "waiting for user approval": True } This is not necessarily memory. It is simply the data required to describe and continue the current workflow. State also does not have to exist only inside an LLM’s context window. It may be held in application memory, a database, a workflow engine, or another persistent system. The LLM may receive only a selected portion of that state when it is invoked. State changes as the agent works. An agent can be viewed as a system that repeatedly performs state transitions: Current state → Agent step → Updated state For example: No destination selected ↓ Destination selected ↓ Flights retrieved ↓ Waiting for approval ↓ Booking confirmed Each tool call, model response, human decision, or workflow rule may update the state. State therefore answers: Where is this agent execution right now, and what data does it currently have? 2. Memory Memory is information retained from the past so that it can influence future behaviour. That definition is intentionally broad. Agent memory is not one specific database or framework feature. It is a capability that can be implemented in several ways. Memory is commonly divided into two scopes. It may contain: Suppose the user says: I want to visit Jaipur in November. A few messages later, they ask: Can you find hotels there? Short-term memory allows the agent to understand that “there” refers to Jaipur. In systems such as LangGraph, short-term memory is maintained as part of the thread’s state and can be persisted through checkpoints. It may include: For example: user memory = { "user id": "user 42", "preferred airline": "Air India", "meal preference": "vegetarian", "prefers direct flights": True } A new travel-planning conversation could retrieve these memories even if it begins in a different thread. Long-term memory therefore answers: What information from the past should this agent retain and use again? Memory requires selection. A system should not treat every historical detail as equally useful memory. Practical memory systems need policies for: A complete transcript is historical data. It becomes useful agent memory only when the system can make relevant parts of it available at the right time. 3. Checkpointing A checkpoint is a persisted representation of execution state at a particular point. Checkpointing allows a system to recover or continue without restarting the entire workflow. Suppose our travel agent has already: If the process stops while waiting for the user, a checkpoint can preserve the state reached after step four. When the user returns, the application can restore that state and continue from the approval step instead of searching for the flights again. Checkpointing can support: In LangGraph specifically, a checkpointer saves graph-state snapshots at execution steps and organizes them into threads. These checkpoints support features such as fault tolerance, human intervention, state history, replay and thread-level conversational continuity. Checkpointing answers: How can the system preserve where an execution reached and continue from there? State { "destination": "Jaipur", "dates": "2026-11-04", "2026-11-10" , "flight options": ... , "current step": "awaiting approval" } This describes the current execution. Memory { "prefers direct flights": True, "meal preference": "vegetarian" } This is retained information that may be useful in this and future travel conversations. Checkpoint Thread: trip-planning-781 Checkpoint: step-4 Saved state: awaiting approval Saved at: 2026-08-15T10:30:00Z This is a persisted execution snapshot from which the workflow can resume. The relationship can be summarized as follows: | Concept | Main purpose | Typical scope | Example | |---|---|---|---| State | Represent the current execution | Current run or thread | Flight options and current workflow step | Memory | Retain useful information for later | Same thread or across threads | User prefers direct flights | Checkpointing | Persist progress for recovery or continuation | Specific execution or thread | Snapshot saved before requesting approval | To wrap up, in this blog, I covered state, memory, and checkpointing and how they differ, even though they often appear together in agent systems and are easy to confuse. For now, the simplest distinction to keep in mind is: In the next blog, I’d like to cover where these boundaries start to blur: how checkpointing can enable short-term memory, why a checkpoint is not automatically long-term memory, how application state differs from an LLM’s context, and what should actually be stored where. This continues soon. Mahak