A stateful AI agent can continue work across steps, interruptions and sessions. That does not mean the model itself “has state.” Reliable statefulness comes from external persistence and explicit transition rules around the model.
This is easiest to understand by separating four things commonly called memory.
Four Different Forms of Continuity
Working context
Working context is what the model can see in the current call: messages, instructions, retrieved evidence, tool results and a state summary. It is temporary and bounded by the context window.
Checkpointed run state
A checkpoint records where a workflow or agent run currently stands. LangGraph, for example, distinguishes thread-scoped checkpoints from a cross-thread store. Checkpoints support interruption, resumption, time travel and fault recovery.
Checkpoint data may include the current step, messages, partial outputs and pending work. It answers “where was this run?”
Long-term memory
Long-term memory preserves information across runs: preferences, distilled episodes, reusable procedures or facts. It answers “what may be useful to remember?”
Memory is not guaranteed to be complete or current. Retrieval may miss it, and summarization may have changed its detail.
The dedicated Agent Memory Architecture separates working, episodic, semantic and procedural memory and defines how each type is written, consolidated, retrieved and forgotten.
Authoritative domain state
Domain state answers “what is true now?” It may live in a transactional database, event-sourced aggregate, graph or external service. It carries stronger semantics than memory because other operations depend on it.
An agent should not infer that an order is still open from yesterday’s conversation when the order system says it is closed.
The State Ownership Rule
Every important field needs an owner.
| Information | Typical owner |
|---|---|
| Current run step | workflow runtime/checkpointer |
| User preference | profile or memory store |
| Account balance | authoritative business system |
| Entity relationships | domain graph |
| Proposed plan | agent run state |
| Approved plan | production state store |
| Tool observation | event/trace log |
The model may read and propose changes to these fields. It should not become their implicit storage mechanism.
Model State as a Transition, Not a Rewrite
A robust state change follows a small protocol:
current state + event
→ proposed transition
→ validation and policy
→ accepted next state
→ recorded event and provenance
This makes change inspectable. It also allows optimistic concurrency or version checks: if another process updated the object after the agent read it, the proposed transition can be rejected and replanned.
Without that boundary, an agent may act on a stale snapshot and overwrite a newer decision.
Checkpoints Are Necessary but Not Sufficient
Checkpointing a run improves durability. If a worker fails after completing three of five steps, it can resume instead of repeating every model and tool call. Pending successful writes can be preserved, and a human approval interrupt can suspend execution until a response arrives.
But a checkpoint captures a run’s view at a moment. External state may continue changing. On resume, the runtime should distinguish:
- values safe to restore directly;
- external facts that must be refreshed;
- completed side effects that must not be repeated; and
- plans that must be invalidated after a state change.
This is why tool calls need idempotency and why state snapshots need versions.
Human Approval Is a State Transition
Human-in-the-loop design is often treated as a message: “ask the user before continuing.” Architecturally, approval is stronger.
PROPOSED → WAITING_FOR_APPROVAL
WAITING_FOR_APPROVAL → APPROVED | REJECTED | EXPIRED
APPROVED → EXECUTED | FAILED
Each transition has an actor, timestamp and payload. The agent cannot reinterpret silence as approval, and a changed proposal cannot reuse approval granted to an earlier version.
Graphs for Relational State
State becomes graph-shaped when validity depends on connections. A research claim is supported by a source. A task is blocked by a dependency. An agent is allowed to use a tool for one tenant but not another. A story character knows one fact but not a second.
A knowledge graph makes those relations queryable. Constraints and application logic still decide which writes are accepted. The graph is a representation of state, not permission for the model to mutate it freely.
Failure Modes to Design For
Stale memory promoted to truth
The agent recalls an earlier fact and skips the authoritative lookup. Fix this by marking context with its source and authority level.
Duplicate side effects after retry
The run resumes and sends the same message or payment twice. Use stable operation IDs, idempotent tool contracts and a side-effect ledger.
State hidden inside prose
A critical task status exists only in the conversation summary. Extract it into a typed state field with an owner and transition rule.
Unbounded state growth
Every observation is appended forever. Separate audit logs from the concise current snapshot and from selectively retrieved memory.
Approval detached from the artifact
A human approves “the plan,” but the plan changes before execution. Bind approval to an immutable version or content hash.
A Stateful Agent Checklist
Before calling an agent stateful, verify that it can:
- resume from a durable checkpoint;
- refresh external facts after resumption;
- distinguish memory, evidence and authoritative state;
- prevent duplicate side effects;
- detect conflicting concurrent updates;
- record who accepted each important transition; and
- rebuild its context without depending on one model vendor’s hidden session.
Stateful agents are not created by remembering more tokens. They are created by making continuity an explicit system property.