Memory: Giving Your Agent Context

Why Agents Forget by Default

Without a memory sub-node, an n8n AI Agent starts completely fresh on every workflow execution. Send a follow-up message — "Can you expand on the third point?" — and the agent has no idea what you mean. For single-query automations this is fine. For chatbots, assistants, or any interaction spanning multiple messages, you need to add a Memory sub-node.

Simple Memory: For Testing Only

Simple Memory requires no credentials and no external services. It stores conversation history inside the workflow execution's in-memory state. The limitation is significant: Simple Memory is volatile. When the execution ends, the memory disappears. It also cannot be used in queue mode — where executions run on separate workers — because there is no shared state between workers.

Use Simple Memory for local testing and development. Switch to a persistent memory node before going to production.

Window Buffer Memory: Persistent Across Executions

Window Buffer Memory persists the last N conversation turns across multiple executions. n8n stores this internally, so conversations survive between workflow runs. The Context Window Length setting controls how many previous turns are kept (default: 5). Users can return to a conversation hours later and the agent still knows the context.

One critical limitation: Window Buffer Memory cannot be used when n8n is running in queue mode. In queue mode, executions run across multiple worker processes that do not share an in-process store. If you run n8n in queue mode, use Postgres or Redis memory instead.

Postgres Chat Memory: Production-Grade

Postgres Chat Memory stores conversation history in a Postgres database. It works in queue mode, survives server restarts, and scales to many concurrent users. You need a Postgres database and a Postgres credential configured in n8n. Each user's conversation is stored under a unique session key so sessions remain isolated from each other.

Redis Chat Memory: Fast Sessions

Redis Chat Memory stores conversation history in Redis — an in-memory data store with optional persistence. It is faster than Postgres for read-heavy workloads and works correctly in queue mode. Use Redis when latency is a priority. Many production deployments combine Redis for active session context with Postgres for long-term conversation archiving.

Chat Memory Manager: Advanced Control

The Chat Memory Manager node gives you explicit read and write access to the conversation store. Use it when you need to modify memory directly — injecting a context summary at session start, removing sensitive data before it is stored, or loading a user's profile from a database at the beginning of each conversation.

Choosing the Right Memory Node

• Testing locally: Simple Memory
• Single n8n worker, not queue mode: Window Buffer Memory
• Queue mode, persistent storage required: Postgres Chat Memory
• Queue mode, speed is the priority: Redis Chat Memory
• Need to programmatically control what is stored: Chat Memory Manager