Imagine the agent is handling a billing dispute. It has opened ticket 413, requested a read of the ledger, and drafted an explanation. The customer once said they prefer short emails. These facts should not all live in the same “memory” blob.

Execution state is the durable record that lets the system resume without inventing what happened: run and step IDs, ticket version, accepted tool results, outstanding operations, approvals, idempotency keys, and whether an external effect is confirmed or unknown. It belongs to the workflow and is changed by controlled transitions. A model summary saying “ledger checked” cannot replace the receipt of the actual read, and “credit issued” cannot replace the payment system's confirmed result.

Short-term context is the selected material the model sees for this turn: the user's current request, relevant ticket messages, current policy excerpt, permitted tool results, and perhaps a compact working summary. It is a view, not the source of truth. Rebuild it from authorized records when the agent resumes. Keep source IDs and revision labels with the excerpts. A context window expiring should not erase a pending credit operation. A context summary repeating an old preference should not override a revocation.

Long-term memory is a deliberate cross-run retained fact that can improve future service, such as a customer's language preference, with a clear owner, purpose, scope, source, consent basis where required, expiry, and a way to edit or delete it. A ticket's private details do not become memory because the model mentioned them twice. Separate memory extraction and approval from ordinary conversation. Restrict retrieval by the current identity and permissions, and record why a memory was included in a response. The exact retention and audit rules are product and legal choices, not properties of the LLM.

Now the user revokes permission to retain the short-email preference. Stop using that memory on new turns immediately. Put a durable revocation or tombstone in the authoritative memory store, so an older checkpoint, replica, delayed extraction job, or cache cannot resurrect it. Remove the preference from active memory projections and derived indexes, invalidate relevant caches, and track the deletion of retained copies according to the product's documented retention contract. An in-progress run should rebuild context or at least filter that preference before its next generation. If the user is asking in this message to forget it, the message may need to be processed to honor the request, but it should not be promoted back into long-term memory.

There is a real edge case here: a support ticket transcript or financial audit log may contain the original sentence. Deleting the preference from personalization memory and preventing future use does not automatically mean deleting every historical record. Tell the user accurately what was removed and what records have separate retention obligations. If the product promises erasure of those records as well, implement that separately with source and derivative tracking. Do not quietly call a hidden copy “execution state” to evade the user's choice.

On resume I would apply current permission and revocation before loading any old checkpoint's context. An immutable checkpoint can describe what the agent previously saw for audit, while the next working context excludes revoked material. This is why source-of-truth state, model context, and retained memory have separate access and lifecycle rules. Microsoft's agent memory documentation illustrates the distinction between a conversation and persistent memory, and its usage guide documents scope and delete operations in that product. The support agent's guarantees still have to be specified by us.

I would test an old checkpoint replay, a delayed memory writer, a second device, and a cache hit after revocation. If any one of them causes the preference to reappear in a new answer, the delete flow is unfinished, however clean the memory table looks.