Free forever, no credit card.Get Started for Free →
← All posts
September 26, 2026 · 6 min read

Scheduled Agents That Never Forget Slowly Rot. Here's the Memory Hygiene Routine

Scheduled Agents That Never Forget Slowly Rot. Here's the Memory Hygiene Routine A scheduled agent that has been running for a year knows a lot. It also remembers a lot of things that stopped being true months ago, and it cannot tell the difference. Most of the advice about agent memory stops at getting memories into the store. Persistence, retrieval, semantic search, the right vector database. All of that assumes every memory keeps its value forever. It does not. The weekly digest agent that

Scheduled Agents That Never Forget Slowly Rot. Here's the Memory Hygiene Routine

A scheduled agent that has been running for a year knows a lot. It also remembers a lot of things that stopped being true months ago, and it cannot tell the difference.

Most of the advice about agent memory stops at getting memories into the store. Persistence, retrieval, semantic search, the right vector database. All of that assumes every memory keeps its value forever. It does not. The weekly digest agent that still believes last quarter's pricing, the lead-qualification agent that keeps disqualifying people against rules you revoked in February, the reporting agent that formats everything the way you asked it to before the rebrand. These are not prompt problems. They are hygiene problems. Nothing ever got deleted.

Why stale memory is worse than no memory

An agent with no memory between runs is dumb but predictable. It starts blank, follows its instructions, and does the job. An agent with a bloated, unpruned memory is unpredictable in a way that is much harder to debug. It does not fail loudly. It just drifts.

The mechanics are simple: retrieval ranks memories by similarity to the current query. Similarity does not know about truth. A memory saved in January saying "the trial is 14 days" will match a query about trial length just as strongly in September, even though the trial has been 7 days since April. If the correction was saved as a separate memory rather than overwriting the original, the agent now holds two answers and picks whichever ranks higher. Nobody told it the first one was wrong.

Meanwhile the bill creeps up. Every run retrieves more memories because there are more memories to retrieve, and every injected token costs money. Operators notice their scheduled agents getting more expensive over time and blame the model or the workflow. Sometimes it is just the weight of a memory store that has never been cleaned.

And corrections stop sticking. This is the symptom operators describe most often, usually in the form of "I keep telling it and it keeps doing the old thing." You are telling it. It is just that the old instruction is still in the store, still matching queries, still outranking the correction on some phrasings. Telling is not deleting.

The routine: expiry, decay, and deliberate deletion

A healthy memory store runs three forgetting mechanisms at once. Each one catches what the others miss.

Give temporary facts an expiration date. Some knowledge arrives with a known shelf life. A promotional price that ends Friday. A workaround for an API that gets fixed next release. A temporary approver covering a vacation. When the memory is saved, attach a time-to-live, and let expired memories drop out of retrieval automatically. This is the only form of forgetting that requires no later judgment at all, which makes it the one you should use most aggressively. The question to ask at save time is simple: "will this still be true in three months?" If the answer is no, it gets an expiry.

Let importance decay prune the long tail. Expiry covers facts you knew were temporary. Decay covers everything else. Every memory gets an importance score that fades with time and revives on access. The memories the agent keeps using stay strong. The ones it has not touched in months sink and get removed. This is a self-cleaning store: the working set of a daily workflow reinforces itself just by running, and the residue of old experiments and one-off corrections fades away on its own.

Decay needs guardrails. Keep a small pinned set that is exempt: who you are, standing rules, anything compliance-related. And pick the half-life deliberately. Thirty to ninety days fits most operational workflows. Annual facts need pinning, not decay.

Keep a human in the loop for deliberate deletion. Some things should only die by human decision: a changed business rule, a dead client relationship, a strategy pivot. The operator or the agent calls an explicit delete, with a dry run first to preview what would be removed. And keep a record of what was pruned. When the agent's behavior shifts and you need to reconstruct why, the deletion log is the first place you look. For regulated workflows, archive pruned memories to cold storage instead of destroying them.

Make forgetting a job, not a chore

The part operators skip is turning this into a recurring workflow. Memory hygiene should be its own scheduled run, sitting right next to the agent workflows it serves:

  • A weekly pass that removes expired memories and anything past the decay threshold.
  • A monthly review of near-duplicates and superseded facts, flagged for a human glance.
  • A short log of everything pruned, so mistakes surface fast.

Whether it is an n8n workflow on a Schedule Trigger or a Make scenario on a monthly timer does not matter. What matters is that it runs without anyone remembering to run it. The first month, run it in preview mode so you can see what your agent has been carrying around. Most operators find memories they forgot existed, which is exactly the point.

The lazy version: let the memory layer handle lifecycle

The honest version of the routine above is a maintenance burden. TTL columns, decay scoring, delete endpoints with audit logs. You can build all of it in Postgres in an afternoon, and then you get to maintain it forever.

The alternative is a memory layer where lifecycle is built in. Vilix AI is cloud-hosted with zero infrastructure, so there is no database whose TTL columns you maintain. Scheduled agents in n8n, Make, Python scripts, or chat clients all read and write the same memory over MCP, which means one cleanup applies everywhere instead of per-tool. You can delete individual memories or wipe the whole account instantly, no waiting period, and export everything in a portable format at any time. When something changes, save the correction once: the most recent save wins, so the old fact is superseded instead of lingering alongside the new one.

The full conversation history is stored as well, not just extracted facts, so before you delete a memory you can check what it was based on. There is a free plan that never expires, and a 7-day Pro trial with no credit card required.

Start this week

If your scheduled agents have been running for months with no cleanup, do not try to fix the whole store at once. Run one pass: list everything older than 90 days that has not been accessed in 30, review it, delete what is wrong. Then set expiries on everything new from now on. Then schedule the recurring hygiene run.

Memory is the reason scheduled agents can be useful over time instead of just running the same prompt forever. But a memory that only grows is a liability with a delay. The operators whose agents stay sharp after a year are not the ones with the best retrieval. They are the ones who taught their agents to forget.

Get Started for Free

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get Started for Free

Free forever, no credit card.

Keep reading
Tray.ai Remembers the Conversation. Your Scheduled Agent Still Starts From Zero.

Tray.ai Remembers the Conversation. Your Scheduled Agent Still Starts From Zero. Tray.ai ships with memory. That sentence is true, and it is also the source of most of the confusion about what the platform does between scheduled runs. In June 2025, Tray.ai released a major update to its Merlin Agent Builder that added what the company calls "maximum short- and long-term memory." Agents built on the platform can track session history and refer back to prior conversations automatically. Sliding c

Your Mastra Agent Remembers the Thread. Your Scheduled Runs Keep Starting New Ones.

Your Mastra Agent Remembers the Thread. Your Scheduled Runs Keep Starting New Ones. Your Mastra agent ran at 2 AM. It pulled the overnight support tickets, drafted replies, escalated the three it could not resolve, and shut down. At 2 AM the next night it ran again, and it asked for the escalation policy it had already been told about the night before, re-drafted replies to tickets it had already answered, and flagged a ticket as brand new that it had escalated yesterday. Nothing crashed. The

Does ManyChat AI Remember Previous Conversations? What Persists and What You Still Own

published_url: ghost_id: Does ManyChat AI Remember Previous Conversations? What Persists and What You Still Own ManyChat AI remembers the current conversation well and previous conversations barely at all. Inside one chat it keeps context: names, preferences, and recent answers stay available to the AI while the conversation is live. Once the conversation ends, that context is gone. A returning contact starts a fresh conversation, and the AI has no access to what was said last time unless you