Your Scheduled Agent's Memory Keeps Growing. Prune It Before It Slows Every Run Down

Every run adds to the pile. A scheduled agent that checks inboxes, updates a tracker, and sends a summary leaves behind notes, decisions, corrections, and raw logs. Week after week, that pile grows. At first the growth feels harmless, because storage is cheap and retrieval is fast. Then one morning the agent starts a run with a stale price, quotes a policy that changed months ago, or spends half its run sifting through notes that stopped mattering long ago.

The problem is not that the agent remembers too much. The problem is that it remembers everything with the same weight. A decision from last Friday sits next to a debug note from March, and retrieval has no reason to prefer one over the other. Pruning keeps the memory sharp: the important things stay easy to find, and the noise stops competing with them.

Start by sorting memory into three buckets

Pruning goes wrong when it starts with deletion. It goes right when it starts with sorting. Before anything gets removed, every kind of note in the store should land in one of three buckets: keep, compress, or delete.

The keep bucket holds anything a future run still needs to act correctly: standing rules, like how a report should be formatted or which channel gets urgent alerts; open items, like the refund still waiting on a reply; decisions and their reasons, especially decisions that reversed an earlier call; and corrections. When a customer changes a preference or a price changes, the correction is not clutter. It is the single most valuable entry in the store, because it stops the agent from repeating the old answer.

The compress bucket holds finished runs worth remembering in outline. A completed weekly report does not need its full working notes forever. It needs its outcome: what was sent, to whom, and whether anything went wrong. A resolved ticket needs the resolution and the condition attached to it. Compressing turns a long trail into a short record that stays searchable without taking up the same space in every future recall.

The delete bucket holds the rest: superseded facts, one-off debug output, duplicates saying the same thing in different words, and temporary instructions that expired with the campaign or project they belonged to. Temporary overrides are the quietest source of bloat. An instruction written for a two-week promotion keeps steering runs months later unless something removes it on purpose.

Sorting first matters because deletion without sorting always cuts something load-bearing. A note that looks like noise in isolation can be the only record of why a decision changed.

Never prune on the first pass

The most important pruning rule is the simplest: preview before deleting. Run the pruning pass in dry-run mode first, look at exactly what would be removed, and only then approve the deletion. A tool that deletes in the same step it selects is waiting to cause an incident.

Dry runs catch three common mistakes: over-broad rules, like deleting everything older than ninety days, which also deletes standing rules written ninety-one days ago; mislabeled entries, like a correction filed as a routine note; and false duplicates, two entries that look alike but record different customers, dates, or conditions.

A practical rhythm is a short pruning pass once a week, or after a fixed number of runs, whichever comes first: sort new entries, compress finished runs, preview deletions, approve, and move on.

Give every entry a reason to stay

The entries that survive pruning longest carry their own justification. A note that says "use the new supplier" is fragile. A note that adds "switched March 2026 after three late deliveries, old supplier kept only as backup" defends itself. At the next pruning pass, nobody has to guess whether it still matters.

That habit makes corrections stick, because the reason travels with the new fact instead of living in a separate note that might get pruned first. It makes compression safe, because a run summary that keeps the outcome and the reason can replace pages of working notes. And it makes deletion defensible, because an entry with no reason and no recent use is exactly what the delete bucket is for.

Age alone is a poor pruning rule. A standing rule from a year ago can matter more than a note from yesterday. Usefulness beats age: has this entry been used recently, does a current rule or open item depend on it, and would a future run decide worse without it? If all three answers are no, the entry is a deletion candidate. If even one is yes, it stays or gets compressed, never deleted outright.

What a good memory layer does for pruning

Pruning is easier when the memory layer does the heavy lifting instead of leaving it to handwritten scripts. Retrieval that selects relevant context, rather than dumping the whole archive into every run, already limits how much noise a run sees. A store that keeps full conversation history, not just extracted facts, means compression never has to guess at what actually happened: the original exchange is still there to check. And a store where a correction in one place becomes the truth everywhere means pruning a superseded fact is a single action, not a hunt across five tools.

That is the shape Vilix AI is built around. It is a cloud-hosted memory layer, so there is no infrastructure to manage. Tools connect to it over MCP, the open protocol, so the same memory is reachable from Claude, Codex, Cursor, and other MCP-compatible clients. It stores full conversation history alongside derived memories, projects, tasks, and rules, and retrieval pulls the relevant context for the run at hand instead of the entire archive. When a fact changes, saving the correction once updates what every connected tool sees next. Everything can be exported or deleted at any time, so pruning stays under the operator's control.

The free plan is free forever, and the 7-day Pro trial needs no credit card. That means the pruning workflow above can be tested on a real scheduled agent before anything is paid for: connect the tools, let runs accumulate, run a dry-run pruning pass, and watch whether the next runs get sharper.

A pruning checklist for the next pass

When the next pruning pass comes around, work through this list. First, protect the keep bucket: standing rules, open items, decisions with reasons, and corrections. Second, compress finished runs into outcome records and drop the working notes. Third, delete superseded facts, duplicates, expired temporary instructions, and one-off debug output, but only after a dry-run preview. Fourth, resolve contradictions by keeping the newest correct version. Fifth, write the reason onto any survivor that cannot explain itself.

Memory that grows without pruning does not stay neutral. It gets slower, noisier, and more likely to surface the wrong fact at the wrong moment. Memory pruned on a rhythm stays small enough to search well and complete enough to trust. Keep it in a state worth acting on.

Get Started for Free — Free forever, no credit card.