One Customer Asked to Be Forgotten. Can Your Scheduled Agent Actually Forget Them?

The request is short and reasonable: one customer asks you to delete everything your agent remembers about them. You delete their chat thread, close the ticket, and move on. A week later, its summary still mentions that customer's company, their preferences, and the workaround built for their account. Nothing was done wrong on purpose. The deletion simply stopped at the most visible copy while the rest of the memory kept working.

That gap is the real problem. A scheduled agent does not keep one tidy record per customer. It keeps many records, in many forms, across many runs. Deleting one customer's data means finding every form, not just the conversation where the data first appeared.

Deleting a chat is not deleting a memory

Think about what a scheduled agent stores over a few months of runs. There is the conversation itself, but also the facts pulled out of it, the summary written at the end of each run, the handover note passed to the next run, the weekly digest that rolled several runs together, and the embeddings that let the agent search old conversations by meaning instead of keywords. Each of those is a separate copy, and each one can bring the customer back into a future answer even after the original chat is gone.

So treat a deletion request as a memory operation, not a chat operation. The question is not "where did we talk to this customer?" but "everywhere their information could surface again, what lives there, and how do we remove it?" If that question gets a shrug, the deletion is not finished, no matter how clean the inbox looks.

The five places a customer's data hides

Start with the full conversation history. It is usually the easiest copy to find and delete, and it is also the copy most teams stop at, which is exactly why the rest of this list matters.

Second, look at extracted facts and preferences. Agents routinely turn conversations into short statements: a contact name, a product, a preference, a constraint, a decision. Those statements often live apart from the conversation, in a facts table or a profile record, and they survive when the conversation is deleted. A fact like "prefers morning calls" looks harmless, but it is still that customer's data, and it can still shape how the agent treats them.

Third, check run summaries and handover notes. A scheduled agent writes these to brief its next run, and they are designed to be reused. A summary of last month's work can carry a customer's name, their issue, and the resolution into dozens of future runs. Deleting the source conversation does nothing to a summary that already absorbed it.

Fourth, check embeddings and search indexes. When a conversation is turned into vectors for semantic search, the customer's words become numbers in an index. Deleting the text record without deleting the vector rows leaves a searchable trace that can still influence retrieval, and derived rows such as entity records can carry the same subject identifier with no obvious link back to the original conversation.

Fifth, check logs, backups, and shared summaries. Run logs record what the agent did and why, and backups hold yesterday's version of everything. Shared summaries, such as a weekly team digest, can blend several customers into one document. A blended summary cannot simply be deleted, because it also belongs to other customers, so it has to be rewritten without the departing customer's contribution.

Design memory so one customer can be removed

The cheapest time to solve this is before the deletion request arrives, at the moment memory is written. Every memory record should carry the customer it belongs to, as a stable identifier, not just as a name mentioned in free text. A name in prose is hard to find reliably. An identifier on every record is a filter, and a filter is what makes "delete everything for this customer" an executable task instead of a search project.

Keep per-customer records separate from shared records. When a run produces a summary covering several customers, either keep the per-customer sections tagged and separable, or write the shared lesson without customer details. Anything that mixes customers together becomes undeletable for one of them.

Give each memory record a source link back to the run and conversation it came from. That link lets you walk from the customer to every derived record: the facts, the summaries, the handover notes, and the index rows. Without it, you are guessing at completeness.

Run a deletion drill before you need one

Pick a test customer, or a clearly marked test record, and walk the full path: find every record for that subject, delete each one, then ask the agent questions that used to surface that customer's information and confirm the answers no longer contain it. Check the facts store, the summaries, the handover notes, and the search index, not just the chat history. Then check what the next scheduled run actually loads, because a run that caches yesterday's summary can resurrect deleted data on its own.

Write down what the drill found. If a copy lives somewhere with no delete path, fix that gap now, while nobody is waiting on an answer. And settle the backup question in writing: a backup that restores deleted data on its next restore is a deletion that undoes itself.

Where a shared memory layer helps

The shape of the memory layer matters here. When memory is scattered across chat exports, spreadsheet notes, a vector store, and a folder of run summaries, a deletion request becomes a scavenger hunt across systems never designed to answer "everything about this customer." When memory lives in one hosted layer that every tool reads over the same connection, there is one place to audit and one place to clear.

Vilix AI is built on that shape: cloud-hosted memory with zero infrastructure to manage, the same memory available everywhere over MCP, and full conversation history stored alongside the facts. Your data stays portable: export everything or delete it anytime, with a free plan forever and a 7-day Pro trial with no credit card. For a scheduled agent, that means a deletion decision does not have to be repeated tool by tool.

The checklist for a real deletion request

When the request arrives, work through it in order. Find every record tied to that customer's identifier, across conversations, facts, summaries, handover notes, index rows, logs, and shared documents. Delete each one, or rewrite the shared documents without that customer's contribution. Verify by querying the way the agent queries, and by watching what the next scheduled run actually loads. Then reply to the customer with what was removed and what, if anything, remains for a stated reason, such as a legal retention requirement, so the answer is specific instead of vague.

Your scheduled agent forgets nothing on its own. That is the point of giving it memory. Deleting one customer's data is the other half of the job: proving that when someone asks to be forgotten, the forgetting reaches everywhere the remembering did.