MemorySync
Integrations

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.

n8n workflows call six MemorySync operations, while AI Agents use MemorySync Chat Memory on the Memory port.

How it works

  1. Install n8n-nodes-memorysync from n8n’s community-nodes panel.
  2. Connect your MemorySync API key once as a credential — it is tested with a real query the moment you save it.
  3. Drop a MemorySync node into any workflow to add, search, recall, list or delete memories.
  4. 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.
NodePlugs intoWhat it does
MemorySyncAny workflow (and AI Agents as a tool)Six operations: Add Memory, Add Conversation Turn, Search Memories, Recall Context, Get Many, Delete Memories
MemorySync Chat MemoryThe AI Agent’s *Memory* portThe agent’s conversation history lives in MemorySync — sessions survive restarts, redeploys, and weeks between chats

Before you start

  1. A MemorySync API key. Create one in the dashboard under Settings → API Keys, inside the project whose memories you want to use.
  2. 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).
  3. Owner access to that instance — only instance owners can install community nodes.

Install the nodes

1
Open the community-nodes panel

In n8n, go to Settings → Community Nodes and select Install.

2
Install the package

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.

3
Create the credential

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:

Dockerfile
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).

  1. 1Add a MemorySync node. Set Operation to *Add Memory*, End User ID to alice, and Text to Alice is vegetarian and never eats mushrooms.
  2. 2Add a second MemorySync node. Set Operation to *Search Memories*, the same End User ID alice, and Query to what does Alice eat?
  3. 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).

  1. 1Build the agent as usual: Chat Trigger → AI Agent, with your chat model connected.
  2. 2Under the agent’s Memory port, select MemorySync Chat Memory.
  3. 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.
  4. 4Leave Context Window Length at 10. That is how many previous turn pairs the agent sees on each run.
  5. 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.
GuaranteeHow
Sessions survive anythingHistory lives in MemorySync, not in-process — restarts, redeploys and scale-out don’t lose a turn
Retries never duplicateEvery stored turn carries a deterministic idempotency seed derived from role, session and content
An outage never breaks the agentReading history fails open to “no history this run”; the agent still answers
Agents cannot bulk-deleteThe 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 everywhereTranscript 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 memoryTranscript 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.

OperationUse it forEndpoint
Add Memory“Remember this fact” — extraction keeps only durable contentPOST /memory/add
Add Conversation TurnAdd a turn to a session’s history (read back by the Chat Memory sub-node); durable facts are extracted from user turns; duplicate-proof retriesPOST /v1/history/append
Search MemoriesSemantic lookup — results fan out as n8n itemsPOST /memory/query
Recall ContextOne prompt-ready context block for a downstream AI stepPOST /v1/memory/recall
Get ManyNewest-first listing for an end userGET /v1/memory/{tenant_id}/{user_id}/list
Delete MemoriesExplicit deletion by IDDELETE /memory/forget

Add Memory

FieldRequiredPurpose
End User IDYesWhich end user this memory belongs to, e.g. customer-42
TextYesWhat to remember
SourceNoWhere it came from (shows in the dashboard); defaults to n8n
Metadata (JSON)NoOptional JSON object attached to the memory

Add Conversation Turn

FieldRequiredPurpose
End User IDYesWhich end user this conversation belongs to
RoleYesWho said it — *User* (default) or *Assistant*
TextYesWhat was said. Kept in the session history; durable facts from user turns become memories
Session IDNoConversation 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).

FieldRequiredPurpose
End User IDYesWhich end user to search
QueryYesWhat to look for, in natural language
LimitNoMax number of results to return; default 50

Recall Context

FieldRequiredPurpose
End User IDYesWhich end user to recall
QueryYesWhat the downstream step is about, e.g. drafting a reply to their email
LimitNoMax 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

FieldRequiredPurpose
End User IDYesWhich end user to list
LimitNoMax memories to return, newest first; default 50

Delete Memories

FieldRequiredPurpose
End User IDYesThe end user the memories belong to
Memory IDsYesComma-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: true instead 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

SurfaceRequiresVerified on
n8n-nodes-memorysync 1.1.0Self-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

Mem0SupermemoryZepMemorySync
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 dependenciesseveral——✓ zero (verified-program rule)

Where to go next

Was this page helpful?