Your n8n Scheduled Agent Doesn't Need a Database for Memory. It Needs This Instead

Every morning your scheduled n8n agent wakes up, and you hand it the same context it had yesterday. The lead list it already scored. The decisions it already made. The tone it already nailed. You paste it into the prompt because the alternative everyone suggests is standing up Postgres or Redis, and you did not get into automation to become a database administrator.

There is a way to give that agent memory without operating any infrastructure. n8n ships the pieces. But the pieces have limits, and for scheduled agents those limits land in the worst possible place. Here is the honest map.

What n8n gives you for free

The AI Agent node has a Memory input. The sub-node most people reach for is Simple Memory (older versions called it Window Buffer Memory). It asks for two things: a Session Key that identifies whose conversation this is, and a Context Window Length that sets how many recent exchanges the agent can see.

Wire it up and the agent holds a conversation across turns with zero setup. For a quick prototype or a chat bot on a single n8n instance, this is genuinely enough. The agent remembers what was said, keyed per session, and you never provisioned anything.

One setting to get right from the start: the session key. Use a stable value derived from the trigger, a user ID, a conversation ID, a customer email. Chat triggers populate one automatically. If you hardcode a single default key and multiple people use the agent, they all share one conversation. That is a privacy incident wearing a configuration mistake as a costume.

The three ways scheduled runs break it

Simple Memory stores everything inside the n8n process. For a chat demo that is a detail. For an agent on a cron schedule, it is the whole story.

A restart erases the week. n8n updates, container reschedules, and out-of-memory kills all clear in-process memory. Your Monday-to-Friday lead-scoring agent forgets everything after a Tuesday night upgrade. Wednesday's run still completes. It just scores every lead from scratch, re-asks questions it already resolved, and contradicts decisions it made on Monday. The workflow shows green. The output quietly regresses.

Queue mode fragments it. The moment you scale n8n to multiple workers for reliability, each worker keeps its own separate in-memory store. The same session key can hit different workers on different runs. The agent remembers on Thursday and forgets on Friday, with no pattern you can debug from the workflow logs, because the workflow is not where the problem lives.

It is a window, not an archive. Exchanges older than the context window length disappear completely. No summary survives, no compressed version, nothing. If your scheduled agent needs to know what happened last week rather than what happened ten messages ago, the window cannot help. And every exchange you keep inside the window gets re-sent to the model on every call, so widening the window directly widens the token bill.

There is also a Chat Memory Manager sub-node worth knowing about. It still needs no database, and instead of auto-storing every exchange it lets the agent explicitly save and load specific items. Better control over what persists. Same volatility underneath: a restart clears it just the same.

Reframe the question

"Without a database" is usually shorthand for "without me operating infrastructure." Once you see it that way, the options widen. The choice is not between fragile in-process memory and running your own Postgres. There is a third option: memory that lives in a hosted service your workflow calls over an API.

Vilix AI takes that shape. It is cloud-hosted, so there is no server to update and no container that can restart underneath your agent's memory. The same memory is available over MCP to every client you connect: Claude, Codex, Cursor, OpenClaw, Hermes, plus headless agents that authenticate with an API key. An n8n workflow reads and writes that memory through the API instead of holding state inside the run, which means a 3am restart changes nothing, queue mode changes nothing, and a second workflow or a second tool can read the same memory later.

It stores full conversation history rather than just distilled facts, and recall blends semantic search with literal keyword matching, so the agent retrieves what it meant even when the wording differs, while exact strings like order IDs still match precisely. Retrieval favors the newest information, and when two sources disagree, the most recently saved version wins. Correct something once and every connected tool sees the correction.

Getting started does not require a purchasing decision. The free plan does not expire, and the 7-day Pro trial needs no credit card. If you let the trial lapse, the account drops back to Free with history and recall intact. Your data stays portable: export everything in an open format whenever you like, delete single memories, or wipe the account instantly. Memory is isolated per user, never sold, and never fed into third-party model training.

A decision checklist for your scheduled agent

Three questions settle which memory your n8n agent should use.

First, what happens if the memory vanishes overnight? If the answer is "the agent redoes some work and nobody notices," Simple Memory with a deliberate session key and window length is fine. If the answer is "the agent contradicts itself to a customer or re-sends something already sent," you need persistence.

Second, does anything besides this one workflow need the memory? A second agent, a dashboard, a human reviewing history, another tool in the chain. If yes, in-process memory cannot serve them. It was never designed to.

Third, who operates the persistent store? If you are happy running Postgres or Redis and monitoring it, n8n's Postgres and Redis chat memory nodes are solid. If you would rather not, a hosted memory service gives you the persistence without the pager duty.

Most scheduled agents that matter clear the first two questions toward persistence. The third is the only real decision. And "nobody, because it is hosted" is a legitimate answer.