Every memory system ships with two operations you use daily: add and search. The third operation, delete, is the one you discover you need at the worst possible moment. Your agent keeps citing a fact you know is wrong, and rewriting the prompt does not help, because the wrong fact is not in the prompt. It is in memory.
Deleting one memory without wiping everything turns out to be its own discipline. Here is how it works, what the common patterns look like, and why scheduled agents make it harder.
Delete is not the same as correct
First, decide whether the memory should be deleted or corrected. These are different operations, and mixing them up causes the exact problem you are trying to fix.
Correct when the fact changed: the pricing tier moved, the deploy process was automated, the routing rule was updated. You do not want the old version erased from history so much as you want the new version to win. In systems with last-write-wins semantics, saving the corrected fact once is enough. The old entry stays in storage, but retrieval prefers the newest save. Vilix AI works this way: say "we are not doing that decision anymore" once, and the new save becomes the truth going forward.
Delete when the memory should never have existed, must not be referenced again, or must not exist at all:
- A wrong fact the agent memorized from a bad run
- Personal data a customer asked you to remove, the GDPR right-to-be-forgotten path
- Credentials, tokens, or secrets that leaked into memory
- A preference that belonged to someone who left the company
The rule of thumb: correct supersedes, delete erases. If any system that audits or exports memory could still surface the old entry, deletion is the honest choice.
The three deletion patterns
Almost every agent memory layer implements some version of these three, because the underlying storage forces it.
1. Delete by ID
The precise scalpel. Search memory for the offending entry, get its ID, delete that ID.
Mem0's API is the clearest example: client.delete(memory_id) removes one memory, and client.delete_all(user_id=user_id) purges everything for a user. The two-step flow matters. You recall first to find the exact record, then delete. Skipping the recall step is how you delete the wrong thing.
In CLI-style tooling the same pattern shows up as slash commands. One mem0 integration ships /mem0-forget <query>, which searches and deletes with a confirmation dialog. The confirmation step is load-bearing: semantic search can match entries you did not intend, and a delete you cannot undo deserves a pause.
2. Delete by scope
Sometimes the problem is not one entry, it is a category. A project ended. A data source turned out to be compromised. A quarter of the memory belongs to a client who churned.
Scoped deletion removes everything matching a filter instead of a single ID. The mnemoir agent spec documents the pattern well: its forget call takes an id for a single memory, a project name to delete all memories in a project, or an older_than duration like "30d" to drop old memories, and the parameters can be combined.
Scope deletion is where scheduled agents benefit most, because their memory accumulates category-shaped problems: all the run notes from a retired workflow, all the vendor facts from before a migration.
3. Full wipe
The nuclear option, and the one your compliance story depends on. A customer invokes their right to be forgotten, or you rotate to a fresh environment, and every memory for a user has to go. delete_all per user is the API shape; an account-level wipe is the product shape.
If your memory layer cannot do this, you do not have a memory layer, you have a liability. Test it before you need it.
Why scheduled agents make forgetting harder
In a chat session, a human notices the wrong memory and says so. In a scheduled agent, nobody is watching. The agent wakes up, reads memory, acts on the poisoned entry, writes new memories derived from it, and goes back to sleep. The bad fact does not just persist; it reproduces.
Three consequences follow.
The delete has to land in the store the agent actually reads. Deleting a line from your prompt template does nothing if the agent pulls context from a vector store at runtime. Forgetting is a storage operation, not a prompt operation.
You need a way to see what the agent remembers. You cannot delete what you cannot find. A memory dashboard, a list endpoint, or a browse command that shows stored memories by category: pick one and use it before every deletion. The mem0 integration's /mem0-tour, which browses all memories grouped by category, exists precisely for this.
Deletion has to be visible to every surface that reads the memory. If your agent reads from three different stores, or three tools each keep their own copy, deleting from one leaves the other two poisoned. This is the quiet argument for a single shared memory store: one place to delete, and every tool sees the deletion at once.
Where this lands in practice
If you are running scheduled agents across n8n, Make, or your own cron jobs, the honest setup is four things: a browse path so you can audit what accumulated, a delete-by-ID path for surgical removals, a scoped path for category cleanup, and a full wipe for compliance. Wire the delete path into the same tooling the agent uses, so the operator's deletion and the agent's reads cannot disagree about what exists.
This is also where a hosted memory layer earns its keep. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to manage: your agents read and write the same memory over MCP, whether they run in Claude, Codex, Cursor, OpenClaw, or a headless scheduler. It stores full conversation history, not just extracted facts, so you can see exactly what the agent memorized and why. You can list, update, and delete individual memories from any connected AI tool or from the dashboard at app.vilix.ai, and wipe the whole account instantly when you need a clean slate. Your data is isolated per user and exportable in a portable format anytime. The free plan is free forever, with a 7-day Pro trial that needs no credit card.
The checklist
Before your next scheduled agent goes to production with memory enabled:
- Confirm the delete path exists and you have tested it, including the full wipe.
- Confirm you can browse what the agent remembers, not just search it.
- Decide your delete-versus-correct policy and write it down where the next operator will find it.
- If memory is shared across tools, confirm a deletion in one place is visible everywhere.
Memory that cannot forget is a write-only log with extra steps. The agents that stay trustworthy over hundreds of runs are the ones whose operators can reach in and remove the one wrong thing.
Top comments (0)