Target query: short term vs long term memory ai agents Slug: scheduled-agent-two-memories-only-one-survives dev.to title: Short-Term vs Long-Term Memory in AI Agents: What Actually Survives Between Runs vilix.ai-blog title: Your Scheduled Agent Has Two Memories. Only One Survives the Night.

Your Scheduled Agent Has Two Memories. Only One Survives the Night.

Your n8n workflow fires at 6 AM. The AI agent inside it wakes up, triages the overnight support tickets, drafts the morning digest, and goes back to sleep. Tomorrow at 6 AM it wakes up again, and it has never seen any of this before. Same workflow, same agent, zero recollection of yesterday.

This is not a bug in your workflow. It is how agent memory is actually built: in two layers, and a scheduled run only ever gets one of them.

Memory one: the scratchpad that dies with the run

The first layer is short-term memory, also called working memory. It holds everything the agent is juggling right now: the messages in the current conversation, the tool results that just came back, the half-finished plan. Under the hood it is the context window plus session state in RAM. It is the reason an agent can follow a multi-step task without asking you to repeat yourself every message.

It is also completely disposable. When the run ends, the process exits, or the container gets recycled, the scratchpad is gone. Nothing in it was ever saved anywhere durable. For a twenty-minute chat session, that is fine. For a scheduled agent whose whole existence is a five-minute run, it means the agent's entire memory of "right now" evaporates before the next run starts.

Short-term memory has a second weakness that bites long runs: it fills up. Every turn appends tokens, older context gets squeezed out, and the bill rises with each message. Operators who try to fix amnesia by stuffing more into the prompt discover this quickly. A fatter prompt is still a scratchpad, just a more expensive one that forgets slightly later.

Memory two: the archive that outlives the run

The second layer is long-term memory: information stored outside the agent, in something durable, retrieved when a future run needs it. It comes in several flavors:

• Conversation history, the full record of past runs, searchable instead of re-read in full
• Episodic memory, summaries of specific events ("on the 14th, the agent escalated the Acme ticket because the SLA was breached")
• Semantic memory, stable facts and preferences ("weekly digest goes out as markdown, no charts, finance CC'd")
• Procedural memory, learned ways of working ("refund approvals need two checks: policy match, then manager sign-off")

Long-term memory is the only thing a scheduled agent carries from Monday's run to Tuesday's. Without it, every run is a first day on the job. With it, the agent can apply preferences you stated once, avoid mistakes you corrected once, and act on facts that changed since last week.

Its failure mode is the mirror image of short-term memory. Instead of forgetting too soon, it remembers wrong. Stale facts linger, retrieval surfaces the irrelevant, and the agent confidently acts on last quarter's truth. Long-term memory needs hygiene: updates when facts change, deletion when they expire, and retrieval you have actually tested against real questions.

What operators build to close the gap

Because scheduled agents get no short-term memory for free between runs, operators build the long-term layer themselves. The usual progression looks like this.

The doc. A Notion page or markdown file holding everything the agent should know, loaded into the prompt each run. It works until the doc grows. Then every run pays for the whole archive in tokens, and the file quietly goes stale because nobody owns curating it.

The database. Structured facts in Postgres, SQLite, or Airtable, fetched with explicit queries. Precise, but the agent only knows what you thought to store and thought to look up in advance. Nothing is recalled on its own; you are the librarian.

The memory layer. A dedicated service the agent queries in its own words, with semantic search over everything it has ever done. This is the shape Vilix AI takes: zero infrastructure to run because it is cloud-hosted, one memory shared across every connected tool over MCP, and full conversation history rather than just extracted facts, so the agent searches what actually happened instead of what someone summarized. Retrieval is semantic plus keyword and recency-aware, so the latest version of a fact is what surfaces. There is a free plan that stays free, the 7-day Pro trial asks for no credit card, and export or full deletion is available any time.

The honest tradeoff, whichever path you choose: long-term memory is only as good as its retrieval and its freshness. A memory store nobody updates becomes a museum. Budget the same care for curation that you budget for wiring it up, and verify with real lookups before a production run depends on it.

The one-line version

Short-term memory runs the current execution. Long-term memory runs the relationship. Scheduled agents only get the first one for free, so if your automation needs to remember anything past tonight, build the second one deliberately, and write to it at the end of every run that learns something worth keeping.