Agent Memory vs Workflow State: What to Store and What to Forget

Evidence check: 25 October 2026. Product details reflect the referenced documentation observed at this cutoff; exact plans, prices, regional eligibility and unverified release dates are not claimed. This is an editorial guide, not a hands-on test.

Three storage problems

Conversation context helps the model respond coherently during a session. Workflow state records what has already happened and what must happen next. Long-term memory retains selected facts across interactions. A system can have one without the others. An agent that resumes after approval needs a checkpoint even if it forgets every conversational aside; a personal assistant may retain preferences without having permission to replay old tool actions.

Design data by retention need

Store execution state with a task ID, owner and expiration policy. Store approval records as auditable events with content hashes. Store long-term user facts only when their use is justified and subject to correction or deletion. Don’t indiscriminately save every tool result or entire conversation forever. In many applications, current records should be re-read from the source system rather than recalled from memory.

Framework distinctions

LangGraph’s documentation separates thread-scoped checkpointers from cross-thread stores. OpenAI Agents SDK documents sessions that preserve history across runs. Cloudflare documents durable SQLite state but warns that in-memory variables vanish when an agent is evicted. These mechanisms are not interchangeable: each has its own owner, durability and access-control implications.

Security isolation

A shared memory store can leak one customer’s information into another person’s task if tenant and access scopes are not enforced. Retrieval permissions must apply at query time, including after access revocation. Treat memories as untrusted contextual material when they originated from external documents; a remembered instruction from a webpage should never become a standing authorization.

Correctness on resume

Before resuming, check the current workflow version, user permission, approval expiry and relevant live data. Old prices, account permissions or task assumptions may have changed while the agent waited. Mark stale state as needing review instead of quietly executing based on it.

Suggested test protocol

Create two users with overlapping topic names, then check strict separation of retrieval and execution state. Interrupt a task, rotate a credential, delete a source document and restart a worker. The expected outcome is faithful reconstruction of approved steps without unauthorized persistence or replay.

A storage classification example

For a recurring travel-planning assistant, a completed booking reference belongs in the authoritative booking database, not only in a conversational summary. A run checkpoint holds pending step IDs and approval state, while a user preference such as “prefer trains” may belong in consensual long-term memory. An ephemeral browser screenshot should normally have a shorter retention period than a financial transaction audit entry. These objects should not all inherit the same backup and deletion rules.

Prove forgetting and resumption

Construct tests that delete a user preference, revoke access to a document and restart a workflow after an approval. Verify the deleted preference does not reappear from embeddings, cached summaries or old checkpoints. Confirm a restored workflow does not silently retry a completed payment or message send. Identify storage encryption and cross-tenant access paths explicitly. A feature described as “memory” in a framework may be merely in-process conversation history; check persistence guarantees and operational recovery against the exact runtime version.