Your AI Agent Should Forget: How to Delete Old Memories From Scheduled Agents

"How do I give my n8n AI agent persistent memory?" gets asked weekly, and the answers always point to external stores: Redis, Supabase, a Postgres table, a sheet of summaries injected into the prompt.

Nobody asks the opposite question, and it is the one that breaks them: how do you make the agent forget?

A memory that never forgets rots

After six months of daily runs, a scheduled agent remembers every workaround for an API that has since changed, every failed approach it tried in March, every note about a contractor who no longer works with you. All of it sits in the store with the same weight as yesterday's decisions.

Three things go wrong when nothing ever gets deleted:

Retrieval quality decays. Vector retrieval ranks by similarity, not freshness. A memory from March that closely matches today's query will outrank a fresher memory that uses different wording. Your agent ends up acting on stale facts while the correct, newer information sits lower in the results. It is not hallucinating. It is faithfully quoting a memory you stopped believing six weeks ago.

Context windows fill with junk. Every run injects retrieved memories into the prompt. When the store holds thousands of low-value memories, each run drags back more noise, which means more tokens per run, which means the memory is quietly bloating your own API bill every single morning.

Corrections stop sticking. You tell the agent the new pricing, the new process, the new tool. The old memory is still there, though, and it still matches queries. Now the agent has two conflicting memories and has to guess which one wins. Some setups handle conflicts with last-write-wins semantics, which helps, but it only helps if the agent actually saves the correction and the old one is truly superseded rather than sitting alongside it as an independent fact.

Three forgetting strategies that actually work

Real memory pipelines do not have one "forget" button. They combine three patterns, and the mix depends on what the agent does.

1. Expiry (TTL): memories with a built-in death date.

Not every memory deserves to be permanent. "The staging API key rotates on the 15th" has a known shelf life. "Competitor X launched feature Y" matters until the next planning cycle, then it is trivia. When you save a memory, you can attach a time-to-live, and expired memories stop appearing in recall entirely. This is the cheapest form of forgetting because it requires zero judgment later. The memory decides its own funeral at birth.

This works best for facts you already know are temporary: prices, schedules, campaign dates, temporary workarounds. If your scheduled agent monitors something seasonal, expiry is the difference between a store that stays clean by itself and one that needs surgery every quarter.

2. Importance decay: let neglect do the pruning.

Expiry only handles memories you knew were temporary. Decay handles everything else. Each memory carries an importance score that drops over time unless the memory gets accessed or reinforced. Frequently recalled memories stay strong. Memories nobody has touched in 90 days sink below a threshold and get pruned.

This mirrors how human memory works: the things you keep using stay sharp, the rest fades.

The danger is the threshold. Set the half-life too short and you delete the annual tax-deadline preference. Set it too long and nothing ever decays. Most operators land between 30 and 90 days for operational memories, and keep a pinned list exempt from decay entirely: identity, standing preferences, compliance facts.

3. Explicit forget plus an audit trail: the human stays in charge.

Some memories need a human decision to die. A business rule changed. A client relationship ended. A workaround became the official process. For these, the agent or the operator calls an explicit delete, ideally after a dry run that previews what would be removed.

The important part is the trail. Pruned memories should be gone from retrieval, but knowing what was deleted and when matters when the agent starts behaving differently. Some setups keep a tombstone log; others archive pruned memories to cold storage. For compliance-heavy workflows, archiving is the only option that survives an audit.

Scheduling the forgetting itself

Here is the pattern most operators miss: forgetting should be a scheduled job, same as everything else the agent does. A weekly or monthly "memory hygiene" run that:

1. Lists memories past their TTL and removes them.
2. Scores the rest by age and last access, and prunes below the threshold.
3. Flags near-duplicates and superseded facts for review.
4. Writes a short report of what was pruned, so a human can spot a mistake.

In n8n, this is just another workflow on a Schedule Trigger: query the store, apply the policy, log the results. In Make, it is a scenario that runs monthly. The tooling does not matter. What matters is that forgetting is scheduled and automatic, not something you remember to do during a crisis. And dry runs first: preview what would be deleted before deleting it. Run the hygiene job in preview for the first month. You will be surprised what your agent remembered.

What this looks like with a memory layer

The DIY version of all this is a pile of scripts: TTL columns in Postgres, a cron job for decay scoring, a delete API with logging. It works, and plenty of operators build it. The problem is that it is the fourth automation you maintain for your automation, and it only exists because the memory store does not handle lifecycle itself. With Vilix AI, your scheduled agents share one memory over MCP instead of each keeping their own files or tables, so forgetting happens once, in one place, and every tool sees the same cleaned-up store. You can delete individual memories or wipe the entire account instantly from the dashboard at app.vilix.ai, and pull everything out in a portable format whenever you want. When two tools save conflicting facts, the most recent save wins, so corrections actually stick instead of piling up next to the outdated original.

It is cloud-hosted, so there is no database to maintain, no prune cron to babysit. The same memory follows the agent whether it runs in n8n, Make, a Python script, or a chat client, and the full conversation history is stored too, not just extracted facts, so you can see what a memory was based on before you delete it. There is a free plan that stays free forever, and a 7-day Pro trial that does not ask for a credit card.

The takeaway

Memory for scheduled agents is not a write-only log. Attach expiries to temporary facts, let importance decay handle the long tail, keep explicit deletes human-reviewed with an audit trail, and schedule the whole thing as its own job.

An agent that remembers everything will eventually remember wrong. An agent that forgets on purpose keeps getting sharper. Build the forgetting in from the start, and six months from now your agent's memory will be the reason it is still useful instead of the reason it is not.