The short answer
An AI agent should preserve state outside the running process, never only in memory or a chat transcript. Separate the state into three layers: conversation memory, an execution journal, and business records. Persist each layer in a suitable durable store so the agent can restart from a known point without forgetting context, repeating actions, or corrupting the system of record.
What does state mean in an AI agent?
State is the information an agent needs to continue work correctly after the current process disappears. That includes what the user already said, what the agent decided, which tool calls completed, which approvals were granted, and what the business now considers true. Those are different kinds of information. Putting all of them into one conversation history creates a system that looks persistent but cannot prove what happened.
A useful definition is simple: persistent agent state is the minimum durable record required to resume a workflow without losing context or repeating completed side effects. The word minimum matters. Saving every token forever creates cost, privacy, and retrieval problems. Saving too little turns every restart into guesswork.
This is not the same question as what happens when an agent crashes mid-task. Crash recovery is the incident. State design is the architecture that decides whether the incident becomes a safe resume, a duplicated action, or a manual reconstruction job.
Which three layers of state should you preserve?
The first layer is conversation memory. It contains user messages, relevant responses, tool results that still matter, preferences, and decisions needed for the next turn. OpenAI's Agents SDK documents session backends that automatically retrieve stored history by session ID, with options including SQLite, Redis, SQLAlchemy, MongoDB, Dapr, and server-managed conversations. The practical point is not the vendor list. It is that a stable session identifier and a persistent backend must outlive the worker handling the current request.
The second layer is execution state. This is the journal of the job itself: current step, completed steps, inputs, outputs, approvals, retry count, and side-effect status. Temporal describes Durable Execution as a way to guarantee that an application runs to completion despite failures. Its service records workflow events in persistent storage, allowing execution to resume from recorded history rather than starting blind.
The third layer is the business record. A qualified lead belongs in the CRM. An approved invoice belongs in the accounting system. A published page belongs at its canonical URL and in the site index. The agent's memory can reference those records, but it should not replace them. If the business truth exists only inside an agent session, the system has no independent source against which to verify the agent's claim.
These layers should connect without collapsing into each other. Conversation memory helps the agent interpret the request. The execution journal proves what the workflow attempted and completed. The business record proves the external result. That separation gives an operator somewhere concrete to look when the agent says, "done."
Where should each type of state live?
Conversation memory belongs in a session store designed for retrieval and retention. For a small, single-process installation, a durable local database may be enough. For multiple workers or machines, the store must be reachable by every worker that can resume the session. The design should define who can read it, how long it remains, and what gets removed or summarized.
Execution state belongs in an append-friendly journal or workflow engine that records durable boundaries. The important boundary is usually not every internal thought. It is every point that changes what can safely happen next: a tool returned a result, a human approved an action, an external request was accepted, or a verification check passed. OpenAI has described externalized state, snapshotting, and rehydration as mechanisms that let agent work continue in a fresh environment after the original one fails or expires.
Business records stay in the system that owns the business fact. This sounds obvious, but many agent demos quietly treat a chat transcript as the database. That works until two sessions disagree, an operator corrects a record, or a retry writes a second version. The agent should read from and write to the source of truth through bounded actions, then store the record identifier and verification result in its execution journal.
Long-term knowledge is a fourth concern, but it should be handled as curated memory rather than an unlimited transcript. Anthropic's guidance on context engineering warns that context is finite and can degrade as it grows. Its recommended patterns include compaction, structured note-taking, and memory persisted outside the active context window. Save durable facts and useful decisions. Do not confuse accumulation with memory quality.
How does an agent resume without doing the same work twice?
A safe resume starts by loading the workflow identity, not by asking the model to infer what probably happened. The runtime reads the latest durable checkpoint, reconstructs the next valid step, and verifies any external action whose outcome was ambiguous. If a request timed out after reaching a provider, the system checks the provider or business record before sending it again.
Every side-effecting action needs an idempotency strategy. That may be a provider-supported idempotency key, a unique business key, or a ledger that records the action before and after execution. The exact mechanism changes by system. The requirement does not: a retry must be able to distinguish "not attempted," "confirmed complete," and "outcome unknown." Treating unknown as failed is how duplicate emails, duplicate records, and duplicate charges happen.
Approvals must also survive restarts. If a person approved a specific payload, the journal should bind that approval to the payload or version that will execute. Restarting the agent should not silently broaden the approval or regenerate a materially different action. An approval without an attached object is just a vague note.
For the workflow itself, start with a bounded process. Choose one with repeatable value, usable inputs, and a clear acceptance test before designing persistence. State architecture cannot rescue a process whose owner cannot define what correct completion means.
What should you require from an agent installation?
Ask for a restart test, not a slide about reliability. Stop the worker after it has completed a real step but before the workflow finishes. The installer should show where the state was stored, how the new worker found it, which steps were skipped, and how the final result was verified in the owning system.
Ask for a state inventory. It should name the session store, execution journal, source of truth, retention policy, approval records, and recovery owner. If the answer is "the model remembers," the design is not finished. Models receive context. They do not create durable storage by themselves.
Ask what happens when storage and reality disagree. The CRM may show that a lead was updated while the agent journal still says pending. The external system should win for the business fact, while the mismatch becomes an incident to reconcile. Quietly overwriting either side destroys the evidence needed to understand the failure.
Ask how state is inspected and exported. Ownership means more than hosting a database. An operator should be able to review active jobs, see approvals, trace completed actions, correct durable business data, and move the records needed to continue operating. A durable agent execution checklist is a practical way to evaluate those boundaries before the agent receives production access.
A practical state design for one business workflow
Take a lead follow-up workflow. Conversation memory stores the buyer's latest message and the relevant thread summary. Execution state records that the lead was classified, a draft was prepared, and approval is still pending. The CRM stores the lead owner, status, required follow-up, and verified contact history. If the worker restarts, it reloads the pending approval instead of reclassifying the lead or drafting a different message.
After approval, the sender records a unique action key and attempts delivery. If the network response is ambiguous, the workflow does not assume failure and send again. It checks the delivery provider or conversation record. Once confirmed, it writes the receipt to the journal and updates the CRM. The final completion claim is based on both records, not on the model saying the task looks complete.
This pattern works because the agent is not treated as the database, the workflow engine, and the business system at the same time. It has enough memory to reason, enough history to resume, and a separate source of truth to prove the outcome.
Limitations
Persistence adds storage, access control, retention work, and operational cost. More checkpoints can also add latency. A low-risk research task does not need the same journal granularity as a workflow that sends money, messages, or contractual documents. Match the persistence boundary to the consequence of repetition or loss.
Durable state does not make bad reasoning correct. It can preserve the wrong decision perfectly. You still need acceptance tests, permissions, human approval for sensitive actions, and independent verification. State management makes execution recoverable and auditable. It does not replace judgment.
It also does not justify storing everything. Personal data, confidential documents, and raw conversation history need explicit retention and deletion rules. Keep the state required for operation and accountability, not an unlimited archive created because storage was available.
The decision
Do not buy an agent installation that can only demonstrate the happy path. Ask where conversation state, execution state, and business truth live after the process dies. Then ask the installer to restart it in front of you.
If the system cannot show what it already did and what it will do next, it is not persistent. It is guessing with a longer prompt.