n8n AI Memory: Configure, Test, and Separate Sessions

The memory node in n8n stores what an AI agent workflow exchanges during a conversation, so the next message in the same session can refer to what came before. Without a memory node, every message the agent receives is treated as a fresh start. Tools like fenbs go a step further: they keep the work record, rules and progress notes that should carry across all sessions, not just within one conversation.

n8n's AI agent node requires a memory node to maintain conversation context. The most common choices are the Simple Memory node, which stores messages in the workflow's runtime, and the Postgres Chat Memory or Redis Chat Memory nodes, which persist to an external database. Each approach has different behavior when the workflow restarts or scales.

How to add a memory node to an n8n AI agent workflow

1. Open your AI agent node in n8n. In the node settings, find the Memory field and click the selector. Choose a memory node type: Simple Memory for testing, or a database-backed option for production.
2. Connect the memory node to the agent node using the Memory connector. The agent node reads from and writes to this node on every execution.
3. Set the Session ID. This is the field that separates one conversation from another. Use a unique value per user or per conversation thread. An expression like {{ $json.userId }} works when each incoming webhook carries a user identifier.
4. Set the context window length. This controls how many previous messages the agent receives. A longer window costs more tokens; start with a value of ten messages and adjust based on how far back the agent needs to look.
5. Run a test with two or three messages in the same session and confirm the agent refers to the earlier messages correctly.

Session identifiers: keeping conversations separate

The Session ID field is the most important setting in the memory node. If every workflow execution uses the same session ID, all conversations share one memory store and the agent mixes up different users' histories. If the session ID changes unpredictably, the agent treats every message as the start of a new conversation.

Choose a session ID that is stable for the lifetime of one conversation and unique across conversations. A combination of a user ID and a conversation start timestamp is a common choice. If your workflow is triggered by a webhook that carries a thread or conversation ID from an upstream system, use that directly.

For multi-user workflows, test with two simultaneous simulated users before going to production. Confirm that a message sent by one user does not appear in the other's memory. This is easier to check while the workflow is simple than after it has been running for a week. For the broader question of what kinds of memory different AI tools provide, see AI memory for teams.

Testing that memory is persisting correctly

Testing memory in n8n means checking three things: that messages are stored, that they are retrieved in the right session, and that the agent actually uses them in its response.

• Send a message in session A that includes a specific fact ("my project is called Redwood"). Then send a follow-up in the same session that asks about the project name. The agent should return "Redwood" without you repeating it.
• Send a different message in session B with a different fact. Confirm that a follow-up in session B returns the session B fact, and a follow-up in session A still returns the session A fact.
• Restart the workflow or redeploy the execution, then send a follow-up in the original session. With Simple Memory, the memory is cleared on restart. With a database-backed memory node, it should survive the restart.

If the agent ignores the stored messages, check the context window length. If it is set to zero, no prior messages are passed to the model. Also check the format the memory node uses: some LLM providers expect messages in a specific role order.

The limits of n8n's built-in memory

n8n's memory nodes keep conversation history within a session. They do not keep the broader work context that should inform every session: the decisions made last week, the rules the team has agreed, or where a project currently stands. That kind of context needs a separate, durable record.

Simple Memory is cleared when the workflow execution ends or the n8n instance restarts. A database-backed node persists the conversation but still stores only the raw messages, not structured information like task status or agreed procedures. For portable AI memory that survives model switches and session boundaries, the work record needs to live outside the workflow.

How to do this with fenbs

1. Create a free account and add a project for the work your n8n workflow supports.
2. Write the rules and decisions that should apply to every session as Decisions and rules in that project. These are the standing instructions the agent reads before it starts, separate from the conversation history.
3. Connect a supported AI assistant over MCP from Integrations. At the start of each n8n-triggered session, include a step that reads the project context from fenbs before the agent begins.
4. At the end of a session that makes progress, save Where we left off: the task status, what was completed and what still needs a person's review.
5. Review the fenbs History to see what changed across sessions, alongside the conversation records in your n8n memory node.

fenbs does not replace n8n's memory node. The memory node handles the conversation; fenbs handles the work record that should outlast any one conversation. For background on how AI memory fits into a broader knowledge setup, see what is an AI brain.

For the n8n AI agent node setup more broadly, including tools, credentials and trigger configuration, see the n8n AI agent guide. For the question of how to store and retrieve memory across different AI tools, the AI memory explained guide covers the main approaches.