How to Make a Scheduled AI Task Remember What It Did Last Run

A scheduled AI task forgets everything because each run starts clean. Give every run one shared memory: load what the last run saved at the start, save what this run found, decided, and finished at the end. The only real choice is where that memory lives: a file, a database, or a memory service.

Why does a scheduled task redo yesterday's work every morning?

Because the scheduler wakes up a fresh run with no memory of the last one. If yesterday's findings only existed inside yesterday's output, today's run has no way to know the work is done. The task is not confused. It is blind.

This gets worse the longer the task runs. A daily price-check agent re-alerts on the same items. A nightly research agent re-reads the same sources. A weekly reporting agent rebuilds numbers it already computed. The cost is not just wasted tokens. It is wrong actions, duplicate messages, and decisions made on stale assumptions.

What should a scheduled task save at the end of each run?

Save the smallest set that prevents repeat work. A good run ledger has five lines: what was checked, what changed since the last run, what was decided, what failed and why, and what is still open.

Do not save full transcripts. A short ledger the next run can read in seconds beats a long log it has to summarize first. If the ledger grows past a screen or two, you are saving too much.

How do you stop a scheduled agent from repeating failed approaches?

Keep a dead-ends list with the reason each approach failed. "Tried X, broken" is not enough; the next run reads that as a challenge and tries again. The note needs to say "tried X, failed because Y." Reasons are what stop repetition. Facts without reasons are just suggestions.

Put a cap on the list too. Ten dead ends with clear reasons is useful. Two hundred is noise the agent will start ignoring.

What is the run-state file pattern?

The simplest version that works is one state file per scheduled job. The pattern, in order:

1. Give the job a stable name, like daily-competitor-scan.
2. Create one file for it, for example state/daily-competitor-scan.md.
3. At the start of the run, read the file. The run's first instruction is to load last run's state before doing anything else.
4. Do the work. Compare new findings against the state so only changes trigger action.
5. At the end of the run, write the new state: timestamp, what changed, decisions made, failed attempts with reasons, open items.
6. On the next run, the file is the first thing read again.

The critical detail is step 5. The write-back must be part of the task's instructions, not an afterthought. If the prompt does not say "update the state file before finishing," the agent will finish without writing and the memory never forms.

Can ChatGPT scheduled tasks remember between runs?

Not by themselves. Each scheduled run is stateless, so you need an external memory the task can read and write: a file in a synced folder, a database row, a notes document, or a memory service the task can reach. Write the task prompt so it names the memory explicitly: what to load first, what to save last. Vague instructions like "remember what you did" fail. Specific ones like "read state/last-run.md first, then update it before exiting" work.

How do you give an n8n workflow memory between executions?

Use a persistent store that survives the execution: Postgres, a memory node, or an external state record keyed by workflow name and date. Save the last run's summary plus open items at the end of the workflow. On the next execution, load that state before the AI agent node starts and feed it into the agent's context. The pattern is identical to the file version. Only the storage changes.

What about MCP agents like Claude Code or OpenClaw?

Use an MCP memory server that every scheduled run can reach. Each run calls the memory tools first to load context, does its work, then saves the run's results before exiting. If two different tools need the same memory, point them at the same account or store so neither one goes blind. The failure mode to watch for is per-tool memory: each client remembering its own runs while the scheduled job needs the shared picture.

When does a DIY state file stop being enough?

A single markdown or JSON file works until you have many jobs, many tools, or a need to search across old runs. The moment you find yourself grepping through dozens of state files to answer "did we already try this," the file has become a database with extra steps.

At that point a shared memory service pays off. Vilix AI is one option for that part: it is cloud-hosted, so there is no database to babysit, and the same memory can be reached from different MCP clients tied to one account, which fits scheduled work that spans more than one tool. The honest tradeoff is that it is cloud-only and each client still needs its own setup. It makes sense when you do not want to maintain the state store yourself. It does not make sense if you need everything running locally.

What is the simplest way to start today?

Pick your most annoying repeat-offender task. Create one state file for it. Add two lines to its prompt: one that loads the file first, one that updates it last. Run it twice and check that the second run references the first. That single loop, load then save, is the whole technique. Everything else is choosing where the memory lives as you scale.