What Is the Best AI Agent Memory for n8n Workflows?

The best AI agent memory for n8n workflows depends on how far your agents reach. If they live entirely inside n8n, the built-in memory nodes or a shared Postgres table are usually enough. If your agents also run outside n8n, in Claude Code, Codex, or scheduled jobs, you need a memory layer that follows them across tools, which n8n's native nodes cannot do.

What are the memory options for n8n AI agents?

n8n AI agents have seven practical memory options: built-in memory nodes for session context, a DIY Postgres table for cross-execution state, vector store nodes for semantic recall, the Zep memory node for entity extraction, the Supermemory community node for automatic memory extraction, Mem0 for self-hosted memory with an MCP server, and Vilix AI for shared memory across every tool your agents run in.

Option 1: n8n's built-in memory nodes

Every n8n AI Agent node accepts a memory sub-node: Window Buffer Memory for the last few messages, or Postgres and Redis Chat Memory for conversation history that survives restarts. They are free, native, and take minutes to wire up. Partition the session key by user ID for chat agents or by execution ID for one-shot runs.

The limit is scope. Built-in memory is per-session conversation history. It does not do semantic recall across old runs, and it does not share context between two different workflows. If your lead qualifier rediscovers the same company research your morning research agent already found, built-in memory will not stop it.

Who should pick this: chat agents and single-workflow automations where each conversation stands alone.

Option 2: a DIY Postgres table

A pattern production n8n teams actually use, described on the n8n community forum: one Postgres table with user_id, key, value, and updated_at columns. The agent reads the rows it needs at the start of a run with a Postgres node and writes updates at the end. It is simple, fully inspectable, and you own the schema.

The tradeoff is that you build the memory lifecycle yourself: what gets written, when rows expire, how conflicts resolve, and how the agent finds the right row. There is no semantic search, so the agent can only look up keys it already knows to ask for.

Who should pick this: operators who want full control and can afford to maintain the read/write discipline in every workflow.

Option 3: vector store nodes

n8n connects to Pinecone, Weaviate, Qdrant, Supabase, and MongoDB Atlas as vector store tools. The agent embeds memories and retrieves them by semantic similarity, which solves the "I don't know the exact key" problem. n8n's own memory guide recommends this layer for long-term knowledge like SOPs and product data.

The tradeoff is operational: embeddings, indexing, retrieval tuning, and deciding what gets embedded all become your job. Most teams end up with two stores, a cheap exact store for state and a vector store for knowledge, and a write policy that keeps them from rotting.

Who should pick this: agents that need to recall from large, messy knowledge bases rather than small structured state.

Option 4: the Zep memory node

n8n ships a Zep memory sub-node that automatically extracts facts about users, sessions, and entities from conversations, combining extraction, summarization, and retrieval without manual configuration. Zep adds bi-temporal reasoning, so you can ask what the agent knew about a customer on a specific date, and its Graphiti engine is open source if you want to self-host the graph layer.

The tradeoff is architectural: Zep is a separate memory middleware layer outside your database, so you reason about storage, scoping, and retrieval across a system boundary. It is strongest when entity and relationship memory matters more than raw conversation recall.

Who should pick this: customer-facing agents where who-said-what-about-whom is the memory that matters.

Option 5: the Supermemory community node

Supermemory's community node gives n8n AI agents automatic long-term memory: each turn is sent to Supermemory, which extracts what matters and hands the agent a compiled user profile of permanent facts plus recent context. Memories persist across sessions without you writing extraction logic.

The tradeoff is the usual managed-service one: your agent's memory lives in someone else's system, and you get their extraction judgments rather than your own schema. Good when you want memory working this afternoon, less good when memory correctness is load-bearing for client work.

Who should pick this: solo operators who want automatic memory without building the extraction pipeline.

Option 6: Mem0

Mem0 is the open-source category leader for agent memory, with user and agent scoping, a large community, and an MCP server you can reach from n8n's MCP client tooling. The real strength is the self-host path: if your memory must live inside your own infrastructure, Mem0 is the option the others cannot match.

The tradeoff is that you run it. Self-hosting means you own the deployment, the upgrades, and the retrieval tuning, and the hosted tiers are a separate product with their own pricing. Pick it for the self-host capability, not to avoid operating a memory system.

Who should pick this: teams with a hard self-hosting requirement or an existing Mem0 deployment.

Option 7: Vilix AI

Vilix AI is a cloud-hosted memory layer that follows your agents across every tool, not just n8n. Connect each AI client to the same Vilix AI account, and the same context, decisions, and conversation history travel with you into Claude Code, Codex, Cursor, OpenClaw, scheduled agents, and anything else that speaks MCP. Retrieval is semantic plus keyword search over a vector database, so recall finds what you meant, not just what you typed. There is a dashboard at app.vilix.ai, you can export everything in a portable format or wipe the account instantly, and data is isolated per user.

The honest positioning: if your agents live entirely inside n8n, the built-in nodes or a Postgres table are simpler and cheaper. Vilix AI earns its place when the same operator runs agents in several tools and is tired of re-briefing each one, because no n8n-native node can carry context into Claude Code or a cron job. It is cloud-hosted, so you manage zero infrastructure and there is no self-host option.

Who should pick this: operators whose agents span n8n plus other AI tools and who want one memory everywhere instead of a memory per tool.

So which one should you actually use?

Start with the built-ins. Move to Postgres or a vector store when one workflow outgrows session memory. Reach for Mem0 when compliance says self-host. Reach for a cross-tool layer when the pain stops being "my workflow forgot" and starts being "I re-brief every agent, every morning."

Frequently asked questions

Can n8n AI agents share memory between workflows?

Not with built-in nodes alone. Share state with a Postgres table keyed by a stable ID, a Redis instance both workflows read, or an external memory service both workflows call. The write policy matters more than the store: decide what gets written, when, and who overwrites whom.

Do I need a vector database for n8n agent memory?

Only when recall is semantic rather than exact. If the agent needs "the customer's preferences from three months ago" without knowing a key, use a vector store. If it needs "the last invoice total," a Postgres row is faster, cheaper, and more reliable.

How do scheduled n8n agents remember the last run?

Persist run summaries to a store the next run reads first: a Postgres row, a static data snapshot, or a memory service. The failure mode to design around is not storage but retrieval, the next run must actually read what the last run wrote before it starts working.