Remember or Recompute? What Your Scheduled Agent Should Store Between Runs

Every scheduled AI agent faces the same quiet design decision, and almost nobody makes it on purpose. When the run starts, it needs context: what was decided last week, which alerts were already handled, what the routing rules are. Some of that context can be remembered from a persistent store. The rest has to be recomputed, refetched, or re-derived from scratch. The split between the two is where scheduled agents quietly win or quietly bleed.

Remember too much and stale facts ride along in every prompt, tokens burn on history that no longer matters, and retrieval surfaces March's workaround for an API that changed in June. Recompute everything and the agent refetches data it already had, re-derives decisions a previous run already made, and occasionally reaches a different conclusion than last Tuesday because the model is not deterministic. Both failure modes look like "the agent is unreliable." Both are really a storage decision.

The one-line rule

Remember what is expensive to recompute, slow to refetch, or judgment-shaped. Recompute what is cheap, volatile, or verifiable against an authoritative source.

Applying it consistently is the hard part: every new workflow tempts you to dump everything into memory or fetch everything fresh, and both instincts are wrong about half the time.

What belongs in memory

Start with the things that are painful or impossible to reconstruct from a blank slate:

Standing decisions and rules. The routing rules, the thresholds, the "never page the on-call for this alert type" policies. These are human judgment, compressed. Recomputing them means asking a person again, which is the most expensive recompute of all.

Corrections you already gave. Every time you corrected an agent's output and it went back to the old behavior next run, that was a missing memory write. A correction is pure gold: a human reviewed reality and stamped a verdict on it. Persist it.

The handled-items ledger. Which alerts were triaged, which tickets were answered, which rows were processed. This is the idempotency layer for scheduled work. Recomputing "has this been handled" means re-scanning everything and reasoning about it again, which is slow and invites duplicates. A small ledger of what is done is the cheapest insurance a scheduled agent can carry.

Pointers, not copies. The dashboard URL, the runbook, the tracker where the real state lives. Memory should hold the map, not the territory. When the territory changes, the pointer still works.

Recent run summaries. Not full transcripts, a short note per run: what was decided, what went wrong, what changed. This is what makes the next run feel like a continuation instead of a cold start. A few hundred tokens of summary replaces tens of thousands of tokens of re-derived context.

What should be recomputed

Now the other side, where remembering actively hurts:

Live data. Prices, inventory, ticket statuses, error counts. Anything that changes between runs should be fetched fresh. A remembered error count from yesterday's run is not context, it is a lie with confidence.

Anything with an authoritative source of truth. If the CRM knows the customer's plan tier, the agent should read the CRM, not its memory of the CRM. Memory is a cache, and caches go stale. The authoritative source is the source.

Derived analysis. If the conclusion can be regenerated from current data in seconds, regenerate it. A stored conclusion outlives its justification when the data shifts.

One-off facts that were true once. The incident workaround, the temporary exception, the "ignore this alert until Friday." These are the entries that rot into landmines. If a memory has an expiry, enforce it. If it does not, it probably should not be remembered at all.

The gray zone: summaries versus raw logs

The hardest calls live in the middle. Raw run logs are cheap to store and expensive to load; summaries are cheap to load and lossy to write. The practical answer is both, at different temperatures: keep short run summaries hot for the agent to read at the start of every run, and keep full logs searchable for the rare audit or dispute. Summaries answer "what should I know." Logs answer "prove it." Most runs only need the first one. And freshness has to be part of retrieval ranking, or a six-month-old workaround will keep getting cited as if it were current.

The two failure modes, side by side

A support-triage agent that remembers the old pricing page will confidently quote last quarter's numbers to a customer. That is the remember-too-much failure: stale memory presented as fact. The fix is freshness discipline, remembering decisions and rules, recomputing volatile facts.

A lead-scoring agent that recomputes its scoring rubric from the prompt every run will occasionally drift: same leads, slightly different thresholds, because the model reinterprets the instructions a little differently each time. That is the recompute-too-much failure: non-determinism where a stored decision would have held the line. The fix is persisting the decision once and loading it every run.

The question is never "memory or no memory." It is always "which specific things does this run need to inherit, and which should it discover fresh." Operators who make that list explicitly get agents that behave. Operators who leave it implicit get agents that surprise them.

Making the split durable across tools

The split only works if the memory survives the places the agent runs. A memory file on one runner's disk dies with the runner. A vector index inside one framework stays inside that framework. The scheduled agent in n8n, the triage script on a cron job, and the coding assistant on a laptop all need to read the same standing decisions, or each recomputes the split on its own and you get three different answers.

That is what a hosted memory layer is for. Vilix AI keeps agent memory in the cloud and serves it over MCP, so every tool reads the same context: the same decisions, the same handled-items ledger, the full conversation history rather than just extracted facts. No infrastructure to run, nothing to sync. The memory the 6 AM automation writes is the memory the afternoon debugging session reads. The free plan never expires, the Pro trial runs seven days with no credit card, and everything stored can be exported or deleted at any time.

A practical starting split

If you are retrofitting this onto an agent that already runs, start here: at the end of each run, write three things to memory. One, decisions the run made that the next run should not remake. Two, corrections that should stick. Three, items the run handled, so the next run does not redo them. Recompute everything else from its source. Run that for two weeks and watch which memories get read and which never do. The unread ones are clutter. The things the agent keeps painfully re-deriving are the next candidates for memory.

Remember or recompute is not a philosophy question. It is an operations question, answered one stored fact at a time. Make the list explicit, keep the volatile stuff fresh, and let the agent inherit judgment instead of re-deriving it at 6 AM.