Full Pro free for 7 days, no credit card. Start 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.

Try Vilix Pro free for 7 days

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

Start 7-day free trial
Keep reading
How Your Scheduled Agent Finds the Right Memory at Run Time: The Retrieval Playbook

Picture a weekly invoice-processing automation. Every Friday at 9 AM, an AI agent wakes up, reads the invoices that arrived that week, matches them to purchase orders, and flags the exceptions. By week twenty, it has stored hundreds of memories: vendor terms, approval thresholds, the finance manager's preferences, every exception it ever resolved. Week twenty-one, an invoice arrives from a vendor with unusual net-60 terms. The agent has a stored memory that says exactly how to handle net-60 inv

Vilix AI vs Smara: Which Shared Memory Layer Fits Your AI Tools?

Vilix AI vs Smara: Which Shared Memory Layer Fits Your AI Tools? The short answer: Vilix AI and Smara solve the same problem: your AI tools each start from zero. Both give every tool one shared memory instead. Pick Smara to self-host, for transparent per-memory pricing, or for a small team. Pick Vilix AI to cover many tools including headless agents, for full conversation history over extracted facts, with zero infrastructure. The honest tradeoff: Vilix AI is cloud-only; Smara ships a self-host

Persistent Memory for AI Agents: What It Is and How to Add It

Persistent Memory for AI Agents: What It Is and How to Add It Persistent memory for AI agents is a storage layer that keeps what an agent learned, decided, and did across sessions, then surfaces it when it matters. Without it, every run starts from zero. With it, agents stop asking the same questions, stop repeating failed approaches, and build on real history instead of guessing. If you run scheduled agents, coding agents, or multi-tool workflows, this is the difference between an assistant t