In this article
Before you start
This page is one question inside the AI agent architecture learning path, and it assumes you can write a basic prompt.
Why interviewers ask this
Long agent runs fail in the middle, and the question tests whether you plan for that. A run that lasts minutes or hours can hit a crash, a timeout, a rate limit or the end of its context window. Anthropic's post on long-running agents describes the core problem as agents losing memory between sessions, which led to incomplete features, duplicated work or premature project completion (a ZenML summary states the same).
A weak answer says "put the history in the prompt" or "use a bigger context window." A strong answer says where the state lives, when it is saved, how a run resumes, and what repeats after a resume. A Staff-level answer adds the part that is easy to miss: the outside world does not roll back, so a repeated step must not repeat its side effects. If you want the wider set of agent questions, see agentic AI interview questions.
State management in agent workflows from first principles
- Agent state
- Agent state is the data an agent needs to continue its work: the messages so far, the results of tool calls, the plan and the next step to run. It is held outside the model, because the model keeps nothing between calls and sees only the text in its current context window.
- Super-step
- A super-step is a round of a graph-based agent runtime that runs every scheduled step before the graph advances. The boundary between two super-steps is where the runtime has a consistent state to save.
- Idempotent tool call
- An idempotent tool call is a call whose effect is the same whether it runs once or several times, for example "set the status to done" rather than "send an email". It makes a repeated step after a resume safe.
In plain words
Think of a video game with save points. If the game crashes, you reload the last save and lose only what came after it. An agent run works the same way, because the model itself is a worker with no memory between calls, so the notes must be kept somewhere else. The analogy breaks in one place. A game save holds the whole world, but an agent's actions also change the real world, such as a sent email, and a reload cannot unsend it.
In one precise sentence: you keep the agent's state in a durable store outside the model, save it at fixed boundaries, and restore from the last save, with repeated tool calls made safe.
Step 1: Keep the state outside the model's context window
The agent's state lives in a store outside the model's context window. The model reads only the text in its current call, so anything that is not written down elsewhere disappears when the session ends or the run crashes.
Anthropic's published pattern shows the idea. In its post on long-running agents, the harness, which is the code around the model that starts sessions and manages files, has two parts: an initializer agent that sets up a structured environment on the first run (a feature list, a git repository, which is a folder whose changes are tracked with history, and a progress-tracking file), and a coding agent that makes incremental progress session by session. Anthropic's repository says its patterns come from that November 2025 post and a March 2026 post on harness design.
A bigger context window delays the problem but does not remove it. A crash, a timeout or a new session still starts from an empty window. The work done so far is written to files or database rows that any new session can read. You now know where state lives; the next step is when to save it.
Step 2: Save a checkpoint at every super-step boundary
In the sync and async durability modes, a checkpoint is saved at every super-step boundary. LangGraph is an open-source library from LangChain for building agents as graphs of steps. As a third-party paper describes it, each run's history is keyed by a thread_id, the key that names one run, and a configured checkpointer saves a StateSnapshot, a saved copy of the run's state, at every super-step boundary. The snapshot holds the accumulated state plus the pending next tasks.
The checkpointers documentation lists in-memory, SQLite and Postgres savers; SQLite and PostgreSQL are databases. Checkpoints accumulate per thread, so plan how old threads are deleted. The documentation also says LangGraph persists writes from individual node executions inside a super-step, so if a sibling node fails, the successful writes need not be recomputed on resume. These task writes are not full snapshots, so time travel, LangGraph's feature for re-running from an earlier checkpoint, resumes from full checkpoints at the boundaries.
Durability modes: when the save happens
A durability mode is a setting that controls when a checkpointer writes. The durable execution page names three: exit persists changes only when execution exits, whether it succeeds, errors or stops at a human-in-the-loop interrupt; async, the default, writes while the next step starts; sync completes the write before the next step begins. The exit mode is fastest, but a process killed mid-run loses the progress since the start, while sync waits for each write before moving on. Pick exit for short, cheap runs you can simply restart, and sync or async when a crash would waste real work. The choice trades write speed against the amount of progress a crash can cost you.
Step 3: Resume from the last checkpoint and make side effects safe to repeat
A crashed run resumes by loading the last checkpoint for its run key and continuing from the pending tasks. Only the unfinished work repeats, which is cheap for a pure computation and risky for a tool with side effects. The usual remedy, standard practice in durable-execution systems, is to make each tool call idempotent, for example by sending a unique request key with it so that the receiving service ignores a repeat. The risk is real: the arXiv paper on resuming agents reports a duplicate-payment attack on LangGraph that abuses resume and rollback.
The saving is easy to compute. Take an illustrative run of 20 steps with one tool call per step, where a crash during step 15 means 14 steps finished and the 15th did not.1 Without checkpoints the run restarts and redoes 15 steps. With a checkpoint every step it redoes 1.1 A crash at step 15 costs 15 redone steps without checkpoints and 1 with a checkpoint every step.
Averaged over every crash point
Averaged over every possible crash point, the same run redoes 10.5 steps without checkpoints, 3 with a checkpoint every 5 steps and 1 with a checkpoint every step.1 A checkpoint every step caps the redo at one step, however late the crash comes. The price is one write per step: the illustrative 20-step run writes 20 checkpoints with a save every step but 4 with a save every 5 steps. That is why a coarser save can be right for cheap steps, and why the choice rests on redo cost against write cost.
Text description of the diagram
- A crash at step 15 costs 15 redone steps without checkpoints and 1 with a checkpoint every step.
- A checkpoint every step caps the redo at one step, however late the crash comes.
Step-by-step description
- State lives in a store, not the window.
- Each super-step saves a checkpoint.
- A crash loads the last checkpoint.
- The agent's state lives in a store outside the model's context window.
- A checkpoint is saved at every super-step boundary.
- A crashed run resumes by loading the last checkpoint for its run key and continuing from the pending tasks.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How do you handle state management in a long-running agentic workflow?
I keep the state outside the model, because the context window is lost when a session ends or a run crashes. The runtime saves a checkpoint at every step boundary, keyed by a run identifier, in a durable database. After a crash I load the latest checkpoint for that run and continue, so only the unfinished step repeats.
Tools with side effects get idempotency keys, so a repeated step does not send a second email. I keep run state apart from long-term memory, which lives in its own store and outlives runs. I version the state schema so an old checkpoint still loads after a code change, and I compact old messages before they go back into the window. The trade-off is checkpoint frequency against write cost and storage growth.
What makes it Staff-level is that it names the failure mode of a resume, a repeated side effect, separates run state from long-term memory, and covers schema changes and window size, not just the mechanism.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Keeps history in the prompt | Stores state outside the model | Separates state, checkpoint and long-term memory |
| Depth | "Save the state" | Saves at step boundaries, keyed by a run | Versions the state schema and compacts what returns to the window |
| Trade-offs | None given | Notes cost of saving often | Weighs write cost, retention and redo cost |
| Communication | Lists tools | States where, when, how | Gives the sentence order and an example |
| Follow-up readiness | Stumbles on a repeated step | Mentions idempotency | Plans tests, retention and approvals |
Three variants of this question
How do you make an agent resume after a crash?
Load the last checkpoint for the run's key and continue from its pending tasks. Only the unfinished step repeats, so make that step safe to repeat.
How do you keep an agent coherent across many context windows?
Write progress to files that each new session reads first, such as a feature list and a progress log, as in Anthropic's two-part harness. The agent then continues from recorded work instead of from its memory.
What happens when the workflow waits days for a human approval?
The interrupt saves a checkpoint and the run stops; when the approval arrives, the run resumes on the same thread_id, however many days later. See human in the loop AI agents.
Common mistakes
- "I just use a bigger context window." (wrong) A crash or new session still starts empty. (right) "I keep the state in a durable store outside the model."
- "A checkpoint is long-term memory." (wrong) A checkpoint belongs to one run. (right) "A checkpoint restores a run; long-term memory is a separate store that outlives runs."
- "Resuming replays everything safely." (wrong) A repeated step can repeat a side effect. (right) "Only unfinished work reruns, and my tool calls are idempotent."
- "I save after every node, always." (wrong) Saving boundaries and modes vary by runtime. (right) "I choose the save frequency by redo cost against write cost."
Follow-up questions
How does a resumed agent avoid repeating a tool call that already ran?
It relies on idempotent tool calls: each call carries a unique key, and the service ignores a repeat. Per-task writes also keep successful node results, so those nodes need not run again after a sibling fails.
Is a checkpoint the same as long-term memory?
No. A checkpoint restores one run at a point in time, scoped to a thread, while long-term memory is a separate store that other runs can read. The AI agent architecture overview places both inside a full design.
Can a bigger context window replace state management?
No. A larger window holds more text per call but is empty at the next session, and a crash discards it. Context rot and context folding explain how long windows degrade anyway.
How often should an agent checkpoint?
Checkpoint where the redo cost of a crash exceeds the cost of a write. In the illustrative 20-step run, a checkpoint every step redoes exactly 1 step, against 3 on average for a checkpoint every fifth step. For how the main agent frameworks differ, see the framework comparison, and test resume with agent evaluation. For a full design, see how to design an AI agent system.
- Agent state lives in a durable store outside the model's context window.
- In the
syncandasyncmodes a checkpoint is saved at each super-step boundary and keyed by a run. - Resuming loads the last checkpoint, so only unfinished work repeats.
- Make tool calls idempotent, because the real world does not roll back.
- Choose checkpoint frequency by redo cost against write cost.
Sources
- Checkpointers (LangGraph documentation) — LangChain, 26 Oct 2026
- Harness Primitives for Long-Running Claude Agents — Anthropic (GitHub), 1 Mar 2026
- Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback (arXiv 2608.29381) — arXiv, 1 Aug 2026
- Long-Running Agent Harness for Multi-Context Software Development — ZenML LLMOps Database, 1 Nov 2025
- Effective harnesses for long-running agents — Anthropic, 1 Nov 2025
- Durable execution (LangGraph documentation) — LangChain, 26 Oct 2026
