n8n Workflow & Agent Memory
Give n8n long-term memory, no code required. One community package installs two nodes: six workflow operations an AI Agent can also call as a tool, and a Chat Memory sub-node that keeps agent conversations alive across executions, restarts and redeploys.
How it works
- Install
n8n-nodes-memorysyncfrom n8n’s community-nodes panel. - Connect your MemorySync API key once as a credential — it is tested with a real query the moment you save it.
- Drop a MemorySync node into any workflow to add, search, recall, list or delete memories.
- Optionally plug MemorySync Chat Memory into an AI Agent’s memory port, and hand the MemorySync node to the agent as a tool it calls on its own.
| Node | Plugs into | What it does |
|---|---|---|
| MemorySync | Any workflow (and AI Agents as a tool) | Six operations: Add Memory, Add Conversation Turn, Search Memories, Recall Context, Get Many, Delete Memories |
| MemorySync Chat Memory | The AI Agent’s *Memory* port | The agent’s conversation history lives in MemorySync — sessions survive restarts, redeploys, and weeks between chats |
Before you start
- A MemorySync API key. Create one in the dashboard under Settings → API Keys, inside the project whose memories you want to use.
- A self-hosted n8n instance. Installing community nodes from npm is a self-hosted feature; n8n Cloud only lists nodes n8n has verified (our verification is in progress).
- Owner access to that instance — only instance owners can install community nodes.
Install the nodes
In n8n, go to Settings → Community Nodes and select Install.
Enter n8n-nodes-memorysync, tick the risk acknowledgement, and select Install. n8n handles the restart — when it finishes, both nodes appear in the node picker.
Add a MemorySync API credential and paste your API key. The credential test runs a real one-result query, so a wrong or revoked key fails right here — not three steps into a production workflow.
Installing in Docker images (optional)
Running n8n from your own image? Preinstall the package instead of clicking through the panel:
RUN cd /home/node/.n8n/nodes && npm install n8n-nodes-memorysync# Community nodes must stay enabled (default: true)ENV N8N_COMMUNITY_PACKAGES_ENABLED=true
Your first memory workflow
A two-step smoke test: Manual Trigger → MemorySync (Add Memory) → MemorySync (Search Memories).
- 1Add a MemorySync node. Set Operation to *Add Memory*, End User ID to
alice, and Text toAlice is vegetarian and never eats mushrooms. - 2Add a second MemorySync node. Set Operation to *Search Memories*, the same End User ID
alice, and Query towhat does Alice eat? - 3Select Test workflow. The search step returns the stored dietary fact as a regular n8n item you can map into any later node.
Give an AI Agent persistent memory
The MemorySync Chat Memory node plugs into the AI Agent’s *Memory* port. The agent’s conversation history then lives in MemorySync instead of process memory, so sessions survive restarts, redeploys and scale-out — and the same user’s durable memories stay available to every other MemorySync surface. The transcript is kept in the session’s conversation history, apart from the user’s memories: MemorySync extracts durable facts from the user’s turns, and only those facts appear as memories (Search, Recall, Get Many, the dashboard).
- 1Build the agent as usual: Chat Trigger → AI Agent, with your chat model connected.
- 2Under the agent’s Memory port, select MemorySync Chat Memory.
- 3Set Session ID to your conversation key — for the Chat Trigger that is
{{ $json.sessionId }}— and End User ID to the person chatting, such as{{ $json.userId }}or an email address. - 4Leave Context Window Length at
10. That is how many previous turn pairs the agent sees on each run. - 5Optional: under Tools, also attach a MemorySync node set to *Search Memories*. The node is marked usable as a tool, so the agent can look up long-term facts on its own.
| Guarantee | How |
|---|---|
| Sessions survive anything | History lives in MemorySync, not in-process — restarts, redeploys and scale-out don’t lose a turn |
| Retries never duplicate | Every stored turn carries a deterministic idempotency seed derived from role, session and content |
| An outage never breaks the agent | Reading history fails open to “no history this run”; the agent still answers |
| Agents cannot bulk-delete | The sub-node’s clear operation is a deliberate no-op — deleting a customer’s history stays an explicit human action (the workflow node’s Delete operation) |
| Same memory everywhere | Transcript turns are kept under the n8n::<session> history scope — a separate transcript per session, the same shared user memories as every other MemorySync surface |
| Facts, not transcripts, in memory | Transcript turns are never listed, searched, recalled or counted as memories; only the facts extracted from the user’s turns are |
Operations
The MemorySync node groups six operations under the Memory resource. Every one is scoped by End User ID, so one user’s memories can never leak into another user’s workflow run.
| Operation | Use it for | Endpoint |
|---|---|---|
| Add Memory | “Remember this fact” — extraction keeps only durable content | POST /memory/add |
| Add Conversation Turn | Add a turn to a session’s history (read back by the Chat Memory sub-node); durable facts are extracted from user turns; duplicate-proof retries | POST /v1/history/append |
| Search Memories | Semantic lookup — results fan out as n8n items | POST /memory/query |
| Recall Context | One prompt-ready context block for a downstream AI step | POST /v1/memory/recall |
| Get Many | Newest-first listing for an end user | GET /v1/memory/{tenant_id}/{user_id}/list |
| Delete Memories | Explicit deletion by ID | DELETE /memory/forget |
Add Memory
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | Which end user this memory belongs to, e.g. customer-42 |
| Text | Yes | What to remember |
| Source | No | Where it came from (shows in the dashboard); defaults to n8n |
| Metadata (JSON) | No | Optional JSON object attached to the memory |
Add Conversation Turn
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | Which end user this conversation belongs to |
| Role | Yes | Who said it — *User* (default) or *Assistant* |
| Text | Yes | What was said. Kept in the session history; durable facts from user turns become memories |
| Session ID | No | Conversation this turn belongs to; defaults to default |
The turn is kept in the session’s conversation history, apart from the user’s memories. A user turn is also sent to fact extraction, and only the durable facts in it become memories; an assistant turn is kept in the history and nothing is extracted from it. The node outputs accepted, turnId (the history turn), memoryId (the same turn in the m_… form the Delete operation accepts) and alreadyExists (true when a retried execution sent the same turn again).
Search Memories
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | Which end user to search |
| Query | Yes | What to look for, in natural language |
| Limit | No | Max number of results to return; default 50 |
Recall Context
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | Which end user to recall |
| Query | Yes | What the downstream step is about, e.g. drafting a reply to their email |
| Limit | No | Max memories to consider; default 50 |
Recall Context returns one grouped, prompt-ready context block — paste it straight into a downstream AI step’s system prompt instead of assembling search results yourself.
Get Many
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | Which end user to list |
| Limit | No | Max memories to return, newest first; default 50 |
Delete Memories
| Field | Required | Purpose |
|---|---|---|
| End User ID | Yes | The end user the memories belong to |
| Memory IDs | Yes | Comma-separated IDs from Search or Get Many, e.g. m_123, m_456 |
Choosing an End User ID
The End User ID is a stable string you pick to identify whose memories these are: your app’s internal user ID, an email address, or a UUID. Use the same value across Add, Search and Recall or recall returns nothing. It also powers billing attribution and the per-user isolation guarantee.
Quotas and plan limits
Quota behaviour never breaks a workflow. On free and paid plans, hitting the monthly limit makes Add Memory report stored: false, accepted: true and reads return empty results — the workflow keeps running. Evaluation keys instead surface a truthful 429, so you find out during testing, not in production. Bad metadata JSON, and a Memory IDs list without a single valid ID, raise clear node errors before any network call; entries that are not memory IDs are skipped.
Billing counts requests, not results. Add Memory and Add Conversation Turn are one add per execution, whichever role the turn has. The Chat Memory sub-node saves the user’s message and the agent’s reply as two separate turns, so one exchange is two adds. It reads the history once when the agent loads its memory, and n8n reads it once more after the exchange is saved, to show the conversation in the execution log, so one AI Agent run is two adds and two retrievals. Search Memories, Recall Context and Get Many are one retrieval each, whatever they return. Deletes are free.
Troubleshooting
- The nodes don’t appear in the picker — community nodes install on self-hosted n8n only, and only instance owners can install them. On n8n Cloud, watch the community-nodes panel; our verification is in progress.
- The credential test fails — the key is wrong, revoked, or was created outside a project. Regenerate it in the dashboard under Settings → API Keys, inside a project.
- Search returns nothing right after an add — check the add node’s output first: low-value text is skipped (
status: skipped) by design. Also confirm both nodes use the same End User ID. - A retried execution didn’t store a duplicate — that’s intentional. Turns carry deterministic idempotency seeds, so replays report
alreadyExists: trueinstead of double-writing. - Add Conversation Turn text doesn’t show up in Search or Get Many — by design: the turn lives in the session’s conversation history, and only the durable facts extracted from user turns appear as memories. Give extraction a few seconds.
- MemorySync Chat Memory is missing from the Memory port, or says "update n8n" — the sub-node needs n8n 2.16.0 or later (the first release that ships
@n8n/ai-node-sdk). The MemorySync workflow node keeps working on older releases. Update n8n and reopen the picker.
Supported versions
| Surface | Requires | Verified on |
|---|---|---|
n8n-nodes-memorysync 1.1.0 | Self-hosted n8n with community nodes enabled. The Chat Memory sub-node needs n8n 2.16.0 or later (the first release that ships @n8n/ai-node-sdk, which it is built on); on older releases the workflow node still works and the sub-node reports "update n8n" | Built with @n8n/node-cli in strict mode — n8n’s own community-node lint passes with zero findings. 32 CI checks: the registry contract (package keyword, dist wiring, zero runtime deps, aiNodeSdkVersion + peer dependency), credentials applied only by the credential’s own authenticate hook, the package loading on an n8n without the SDK, the fnv1a64 idempotency parity vector, and the memory node driven through the REAL @n8n/ai-node-sdk → LangChain adapter chain — history read from the conversation-history API (never the memory list), windowed history, session isolation, duplicate-proof retries, fail-open outages, no-op clear. Published to npm with SLSA provenance from the public repository, and executed end to end inside a real n8n runtime. |
How it compares
| Mem0 | Supermemory | Zep | MemorySync | |
|---|---|---|---|---|
| Community node ships | △ workflow ops only | ✗ HTTP-request recipes in docs | △ built-in node deprecated; hard-removed in n8n v3 | ✓ n8n-nodes-memorysync |
| AI Agent memory sub-node | ✗ none | ✗ | was the removed node | ✓ maintained, on the official @n8n/ai-node-sdk path |
| Agent can call memory as a tool | ✗ not marked usable | ✗ | ✗ | ✓ usableAsTool |
| Credential test | ✗ none — bad keys fail mid-workflow | — | — | ✓ real query at setup time |
| Retry safety | ✗ re-runs re-store | — | — | ✓ deterministic idempotency seeds |
| Runtime dependencies | several | — | — | ✓ zero (verified-program rule) |