n8n AI Agent Memory: Prove the Session Survived

n8n AI Agent memory is reliable only when four things agree: the workflow uses a memory backend compatible with its deployment mode, the same user reaches the same session key, the expected history can be read back from the store, and a later execution uses that history correctly. A fluent follow up answer proves none of those conditions by itself. The practical default is to test memory as a routing and persistence contract. In a single process experiment, Simple Memory can be adequate. In queue mode, use a shared memory service such as Postgres or Redis, give every conversation a stable opaque session key, and verify isolation with two sessions. Then cross a real execution boundary. Do not call memory healthy because two messages in one execution appear coherent. Start with the deployment boundary The official n8n memory overview separates AI Agent nodes, which can use memory, from AI chains, which cannot. It lists Simple Memory and external memory services, including Redis and Postgres, as different implementation choices. That is a capability map, not a health verdict. The first operational question is where the history lives. n8n explicitly warns in its Simple Memory documentation not to use that node for an active production workflow in queue mode. Calls can land on different workers, so worker local history cannot be assumed to follow the conversation. Classify that case before looking at prompts or models: queue mode unsafe : the workflow runs in queue mode and uses Simple Memory; store unavailable : a shared backend is configured but the workflow cannot reach it; write unverified : the backend accepted a connection, but the expected conversation turn was not observed in durable history. Switching to Postgres or Redis resolves worker locality; it does not resolve identity. A shared store can faithfully preserve the wrong conversation under the wrong key. Availability, durability, and routing are separate properties. For each workflow version, retain a small configuration receipt: The receipt should describe the rule, not expose the user ID, chat ID, credentials, connection string, or message text. If a stable key must be derived from private identifiers, compute an HMAC on the host and export only the opaque result or a local equality check. Prove session identity before testing recall Both Simple Memory and Postgres Chat Memory use a session key. The Postgres node also lets you choose the table and context window length. Its documentation notes that multiple Postgres Chat Memory nodes use the same memory instance by default; separate memory instances require different session IDs. That makes the session key part of the correctness boundary. It must be: 1. stable for the same external conversation; 2. different for conversations that must not share history; 3. independent of a transient execution ID; 4. generated before the memory sub node resolves its parameters; 5. safe to log as an opaque identifier. There is an n8n specific trap here. The memory node documentation says expressions in sub nodes resolve against the first input item, rather than once for every item. If three incoming items represent three conversations and the session key expression is evaluated inside the memory sub node, all three can be routed using the first item’s value. Do not diagnose that as poor model memory. Record the number of session identities expected at the root node boundary and the number observed by the memory adapter. If three were expected and one was observed, return session key collapse . Split the items or calculate and validate one session key per execution before the sub node boundary. Run an isolation probe with two synthetic sessions, not real customer text: Session A stores an opaque marker whose expected decision is ROUTE ALPHA . Session B stores a different marker whose expected decision is ROUTE BETA . A fresh execution for A must return only ROUTE ALPHA . A fresh execution for B must return only ROUTE BETA . Swapping either result is a privacy and correctness failure, even if both answers sound plausible. This negative test matters. A single successful recall can pass while every user is mapped to the same shared history. Read history back, then cross a fresh execution A database row count is weak evidence. It can increase while the wrong session receives the message, while a previous version remains at the top of the context window, or while a destructive memory operation replaces more history than intended. The official Chat Memory Manager documentation exposes get, insert, override, and delete operations. Its simplified read mode returns sender and text. Use that ability inside a protected diagnostic workflow, or query the external store locally, to verify three facts: the expected opaque session key exists; the latest test turn is present in the correct order; the neighboring session does not contain it. Keep raw conversations out of monitoring telemetry. The diagnostic workflow can compare the retrieved test marker locally and emit: Now start another workflow execution through the same production trigger path. Reusing another node in the current execution is not a persistence test; the answer may still be present in the item payload or model context. The later execution should receive only the opaque session identity and a bounded question whose expected answer is a decision code. Pass only when the store read back and the later behavior agree. If the history is correct but the decision is wrong, return continuity failed . If no genuinely new execution was observed, return continuity unverified . Neither state should be collapsed into an empty memory error. Replay ten failure states in a fixed order The accompanying n8n memory health cases.json fixture contains no prompts or message text. It supplies ten synthetic observations to a small classifier: The reproduced run returned: The order is deliberate: 1. confirm that a memory node is attached; 2. reject Simple Memory in queue mode; 3. detect first item session key collapse; 4. compare the current session key with the expected stable key; 5. test store reachability; 6. prove the write; 7. compare read back with the expected history; 8. require a later execution; 9. compare its decision with the expected result. Stopping at the first failed layer gives the operator a useful repair. Rewriting a prompt cannot fix queue mode locality. Rebuilding a table cannot fix session key drift. Changing a model cannot fix two users mapped to the same key. Adapt the fixture with your workflow revision, backend type, queue mode flag, expected and observed distinct session counts, local read back booleans, and fresh execution result. Preserve unknown states when the evidence is absent. A green model response is not a substitute for a missing store probe. Keep conversational memory separate from workflow outcomes Passing this audit proves a bounded claim: the tested conversational history was routed, stored, retrieved, and used across the tested execution boundary. It does not prove the whole workflow completed its job. An agent can remember that an invoice must be sent and still fail to send it. It can recall the correct customer and write to the wrong destination. It can preserve an outdated instruction whose expiry condition was never modeled. Keep a separate outcome receipt for the deliverable, external effect, or approval boundary the workflow is meant to satisfy. The audit also has practical limits. It samples chosen sessions and context windows. A database can fail after the probe. A compromised host can forge both the history and its evidence. A correct decision code does not prove every nuance of a long conversation survived. Reading stored messages can expose sensitive content, so production checks should compare opaque markers locally and export booleans, counts, freshness, and workflow revisions. The operating rule is concise: Mark n8n AI Agent memory verified only when deployment compatibility, session isolation, durable read back, and fresh execution behavior all pass for the same workflow revision. Sidewisp is currently in private preview. It is intended to add a health layer around existing agent runtimes, but production agent health collection, n8n adapters, and automated recovery are not shipped in the current website repository. This is an operator run verification pattern, not a claim that Sidewisp currently monitors n8n. If this distinction between a remembered conversation and a verified outcome matches how you want to operate agents, join the Sidewisp private preview. Until then, keep session identities opaque, test a negative isolation case, and let missing evidence remain non green.