State, Memory & Checkpointing in AI Agents, Explained

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:

• State represents what is true for an agent execution at a particular point.
• Memory represents information retained so that it can be useful later.
• Checkpointing is the mechanism used to persist execution state at defined points.

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:

• the conversation messages
• the current task
• intermediate results
• tool outputs
• the next step to execute
• retry counters
• approval status
• retrieved documents
• generated artifacts
• errors encountered during execution

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.

• Short-term memory Short-term memory maintains continuity within the same conversation or execution thread.

It may contain:

• recent messages
• earlier tool results
• decisions made during the current task
• a summary of an extended conversation
• temporary facts relevant to the active thread

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.

• Long-term memory Long-term memory survives beyond one conversation or execution thread.

It may include:

• user preferences
• stable user facts
• previous interactions
• application-specific knowledge
• learned instructions
• successful solutions from earlier tasks

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:

• what should be remembered
• when it should be written
• how it should be retrieved
• when it should be updated
• when it should expire or be deleted
• how conflicting memories should be resolved

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:

• 1. understood the request
• 2. collected travel dates
• 3. searched for flights
• 4. shortlisted three options
• 5. asked the user for approval

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:

• recovery after failures
• interruption and resumption
• human-in-the-loop workflows
• inspection of previous states
• replay or debugging
• branching from an earlier state
• durable, long-running execution

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?

1. Understand the example Let us pause the travel agent after it has found flight options.

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:

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:

• State tells us where the agent is.
• Memory helps the agent use what happened before.
• Checkpointing lets the agent continue from where it left off. But this is only the first layer.

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