Your Scheduled Agent's Last 60 Seconds: What to Write to Memory Before the Run Ends

Picture a lead-research agent that runs every night at 2 AM: it scans new signups, scores them, and emails you a shortlist by morning. It works, for a while. Then one Tuesday the shortlist contradicts last week's. Three companies you already rejected are back on it. The scoring criteria you corrected a month ago are gone. Nothing broke. The agent has no idea what it decided last week, because last week's run ended without writing anything down.

Most guides obsess over the read side: how the agent pulls context at the start of a run. The write side is where scheduled agents fail. A run that ends without saving is a run the next one cannot build on, and no retrieval system can find what was never stored.

The fix is a shutdown note: a short, deliberate memory write, the last thing the agent does before the run ends. Not a transcript dump. A note written for a reader who shows up next week with no context at all. Memory systems do not generate continuity; agents do, by writing. Retrieval only finds what some earlier run bothered to store.

What goes in the shutdown note

Six fields cover almost everything a future run needs. Keep each to a sentence or two. The whole note should fit on one screen.

1. What this run did. "Processed 214 new signups, scored 38 as qualified, emailed shortlist at 02:14." Future runs need the outcome, not the intermediate reasoning.

2. Decisions made, with reasons. "Rejected Acme Corp: fewer than 10 employees, below threshold. Threshold moved from 5 to 10 after September's false positives." The reason is what matters. Without it, the next run re-scores from scratch.

3. What changed since the last run. "Client export now includes a 'region' column, added 2026-10-03." This is how the agent stays current without re-deriving everything from raw data.

4. Open threads. "Lead #1187 needs a manual email; the template failed on the custom domain." Without this, unfinished work falls into the gap between runs and gets quietly dropped.

5. What to skip next time. Processed items, dead ends explored, sources exhausted. The cheapest line in the note: it stops the next run paying for work that is already done, which is where the token bill comes from.

6. Mistakes and the lesson. "Tried scoring with the pricing-page keyword list; it misclassified 12 agencies as SaaS. Switched back to the firmographic rules." An agent that writes down its mistakes stops repeating them.

What to leave out

The shutdown note is not a transcript. Dumping the full conversation into memory every run is how you get a slow, expensive, noisy store that future runs cannot search. Keep out:

• Raw logs and transcripts. The note is the summary; logs live wherever your workflow already keeps them.
• "Success" with no details. A note that says the run worked tells the next run nothing. Outcomes without reasons are noise.
• Things true today and false next week. Today's stock price, this morning's error rate, a temporary workaround. If it expires, it goes in the run output, not in memory.
• Anything unverified. Do not write conclusions the run did not confirm. An invented fact in memory is worse than a missing one, because the next run will trust it.

How to wire the write into the run

The note has to be part of the workflow, not a hope. Three patterns cover most setups.

Make it the last step. In n8n, Make, or Zapier, add a final node that calls the memory store's write tool. The workflow is not complete until that node succeeds. If the write fails, the run should flag it, not silently end. Silent failure is how you get weeks of blind runs before anyone notices.

Put it in the system prompt. Where you cannot add a node, add a closing instruction: before finishing, write the shutdown note to memory with the six fields. Less reliable than a dedicated step, but it works across tools that give you no structured last action.

Version the write. If two runs can overlap, a stale write can clobber a newer one. Re-read the current note immediately before writing and merge instead of overwriting. Last write wins is fine as long as the last write is actually the freshest information, which means the write has to see the current state first.

What this looks like in practice

Take a nightly support-triage agent in n8n. Before the shutdown note, its memory was a folder of prompt templates and nothing else. Every night it re-read the same 200 tickets, re-decided the same routing rules, and occasionally re-escalated an already resolved ticket.

After adding the note as the final node, each run reads last night's note first and writes a new one at the end: ticket counts, two routing decisions with reasons, one open escalation, processed ticket IDs to skip, one lesson about a misclassified thread. The read costs a fraction of a cent. The skipped re-processing saves thousands of tokens a night. Within two weeks the agent stopped re-deciding things it had already decided, which was the entire problem.

Where a hosted memory layer fits

You can implement the shutdown note on any store: a file, a database row, a vector collection. The pattern matters more than the plumbing. But the plumbing gets tedious when the agent runs on several tools. A file on one server is invisible to a scenario on another platform, and a database row needs a schema, backups, and someone to run the database.

Vilix AI is a hosted memory layer over MCP built for this shape of problem. The agent reads at the start of a run and writes the shutdown note at the end through the same memory tools, from any connected client: n8n, Make, Claude Code, OpenClaw, whatever wakes the agent up. Cloud-hosted means zero infrastructure: nothing to deploy, no database to back up. Full conversation history is stored, not just extracted facts, so a future run can revisit the reasoning behind a past decision. Everything is exportable in a portable format anytime, and you can delete individual memories or wipe the account instantly.

The free plan is free forever, and the 7-day Pro trial needs no credit card. If the shutdown-note pattern sounds right but you do not want to operate the store it lives on, that is the gap a hosted layer closes. Details are on the pricing page.

The checklist

Before your next scheduled run goes live, make sure the run is not allowed to end without the note:

1. The workflow has a final memory-write step, after all the real work.
2. The note has the six fields: outcome, decisions with reasons, changes, open threads, skips, lessons.
3. The write is verified, not assumed: failures surface instead of ending the run silently.
4. Overlapping runs merge instead of overwrite.

A scheduled agent that writes before it sleeps wakes up with a past. One that does not is a stranger to its own work, every single day, on your token budget.