Agent state
Agent state is the running record an AI agent keeps while it works, so a task can pause, resume, or recover from a crash.
An AI agent is a program that uses a language model to get a job done in steps. Say you ask it to book a flight to Lisbon. It reads your request, then uses a tool (a helper program, like a flight search). It reads the result, asks you a follow-up question and tries again. Agent state is the running record of all that: the goal, the messages so far, the steps done, what each tool sent back and what comes next. Google’s Agent Development Kit (ADK) calls it the agent’s scratchpad for one conversation. One value in it might say the current intent, meaning what you want right now, is book_flight.
The language model does not keep this record itself. A separate program, often called a runner, does the remembering. In the OpenAI Agents SDK, before each run (each time you send a message) the runner fetches the saved history for that conversation and puts it in front of your new message. After the run it writes the new items back: your words, the agent’s replies and every tool call.
Now slow the booking down. The agent finds flights and is ready to pay. Paying is sensitive, so the builder has told it to wait for a person’s yes. The run pauses, and its state is packed into a form that can be stored. An hour later you tap “approve”. The agent loads the saved state and carries on from where it stopped, without searching again.
Or imagine the server restarts mid-job. LangGraph, a toolkit for building agents, saves a checkpoint after each step: a snapshot of the state at that moment. If a step fails, the job restarts from the last step that worked, not from the beginning.
To find the right snapshot, the program needs a label called a thread ID. Think of a coat-check ticket: your coat is safe, but you only get it back with the ticket. Lose the thread ID and the agent cannot load its state or resume. Where state lives matters too. ADK warns that state kept only in the computer’s working memory is lost when the program restarts.
State also comes in scopes, meaning how long it lasts. In ADK, session state belongs to one conversation. Some is tied to the user and shared across all their chats, and some lasts for a single run and is then thrown away.
State is not long-term memory, and it is not judgement. It records what happened, but a well-saved record can still hold a bad plan. Facts that should last across many conversations go in a separate store.
An agent's work spreads across many steps, and any of them can be interrupted.
Follow one flight booking as the agent saves, pauses and resumes.
- 1 · recordThe agent keeps a record of the conversation so far, including user messages, its own replies and every tool call.
- 2 · updateAfter each step, the new facts, such as the search results or the current goal, are written into the state.
- 3 · saveA saved snapshot of the state is stored under a thread ID, a label that names this one conversation.
- 4 · pauseWhen an action needs a person's approval, the run stops and its state is packed into a form that can be stored.
- 5 · resumeLater, the agent loads the saved state and continues where it left off rather than starting again.
The model itself remembers nothing: the program around it writes the state down and hands it back each time the agent runs.
| Who | What they ask | What it works with |
|---|---|---|
| Travel app builder | “Can the agent wait for the traveller to approve the fare, then finish booking?” | The paused run and its saved state |
| Support team | “The customer came back after lunch, what did we already try?” | The session history for that conversation |
| Platform engineer | “A server restarted during a long job, do we have to rerun everything?” | The last successful checkpoint for the thread |
| Chat app builder | “How do we keep a user's preferred language across all their chats?” | Data stored at the user level, not in one conversation |
- An agent can keep the thread of a conversation across many turns without the developer resending the history by hand.
- A run can stop for a human decision and continue afterwards.
- After a failure, work can restart from the last successful step instead of from the beginning.
- Humans can look at the saved state, interrupt it and approve the next step.
- Short-lived state belongs to one conversation. Remembering facts across many conversations needs a separate long-term store.
- Where state lives matters. State kept only in memory is lost when the program restarts.
- Saved state is only useful if you keep its label. Without the thread ID, a checkpointer cannot load the state or resume after an interruption.
- State is not judgement. It records what happened, but it does not make the agent's next choice a good one.
Sources used
This explainer is written in original language. The links below support its factual claims.
- docsPersistence, LangChain · read 28 Sept 2026
- docsCheckpointers, LangChain · read 28 Sept 2026
- docsSessions, OpenAI Agents SDK · read 28 Sept 2026
- docsHuman-in-the-loop, OpenAI Agents SDK · read 28 Sept 2026
- docsState: The Session's Scratchpad, Google Agent Development Kit · read 28 Sept 2026
- docsSession: Tracking individual conversations, Google Agent Development Kit · read 28 Sept 2026