Start with the symptom, then trace the session
An assistant forgets a detail between messages. Before rewriting its prompt, check whether the next message reaches the same memory session. A changed identifier, a disconnected memory sub-node or an unsuitable deployment mode can prevent the expected history from reaching the model.
We tested the workflow below locally on 8 November 2026. It used real n8n execution and a real local model, with synthetic conversations. It was not a test on a customer installation, a cloud provider or a production deployment. The test summary and scoped results identify exactly what was checked.
Record your installed version, trigger, memory backend and execution mode before changing anything. Use a disposable workflow and synthetic facts; do not clear existing customer history as a first troubleshooting step.
The configuration we actually tested
| Component | Recorded version or setting |
|---|---|
| n8n / Node.js | 2.46.6 / 24.22.1 |
| Chat Trigger / AI Agent nodes | 1.5 / 3.1 |
| Simple Memory node | 1.4; connected to both Chat Trigger and Agent |
| Ollama server / model | 0.40.15 / qwen3.5:4b, Q4_K_M |
| Execution and memory backend | Single-process regular mode; in-process Simple Memory |
| Session identity | From the incoming sessionId; separate fixed-key control workflow |
| Context Window Length | 2 previous interactions |
| Model settings | 4096-token context, 64-token output cap, temperature 0, thinking disabled |
The workflow was Chat Trigger → AI Agent, with an Ollama Chat Model and a Calculator tool connected. The Calculator was available but was not needed for these memory questions. A local recording proxy forwarded model requests unchanged to Ollama so we could inspect the actual history delivered to the model.
The three numeric limits have different roles: 2 controls past memory interactions, 4096 is the model context capacity in tokens, and 64 caps generated tokens for this test. They are sample settings, not universal recommendations. SQLite stored n8n execution records; it was not the chat-memory backend.
Check session IDs and shared memory connections
Inspect the trigger output and resolved session key for two consecutive messages. They must refer to the same conversation. For a new conversation, use a different key. The n8n session-ID troubleshooting guide explains the missing-session case and warns against using a static test key for real session management.
When loading previous chat messages, Chat Trigger documentation recommends connecting the trigger and agent to the same memory sub-node. Our workflow used that connection. Its loadPreviousSession request returned the stored conversation without invoking the model.
In a custom application, derive session access from authenticated server-side identity. Our test demonstrates separation of chosen keys; it does not establish protection against a client guessing or supplying another person’s sessionId. Treat authentication and conversation authorization as separate requirements.
Observed recall and isolation results
| Case | Observed model result | History inspection |
|---|---|---|
| A stores CEDAR-EFCEC11E | ACK | The user fact entered session A |
| A asks for its codename | CEDAR-EFCEC11E | A’s stored fact was in the model request |
| Fresh B asks the same question | UNKNOWN | A’s fact was absent from B’s model request |
| B stores and recalls MAPLE-EFCEC11E | MAPLE-EFCEC11E | B received its own fact, without A’s history |
| Return to A after B’s messages | CEDAR-EFCEC11E | A received its own fact, without B’s fact |
The model was not given a codename in the recall question or system instructions. The stored facts appeared in the earlier conversation messages recorded at the model boundary. This matters because a correct-looking answer alone would be weaker evidence of memory.
The complete run involved 14 local HTTP requests and 12 local model-inference requests. The final review confirmed 17 checks; this is a count of assertions in one controlled run, not an accuracy percentage across users or models.
Verify the context window and failure controls
| Case | Observed behavior |
|---|---|
| Three filler exchanges, then ask A again | The old codename was absent from the model input; answer UNKNOWN |
| Two-interaction window | Four historical user/assistant messages plus the current user message reached the model |
| Missing sessionId | HTTP 500 with a redacted public error; no model invocation |
| Stored missing-session execution | NodeOperationError: No session ID found in Shared Simple Memory |
| Fixed-key control with two distinct sessionIds | The second session received and answered with the first session’s BIRCH-EFCEC11E fact |
The fixed-key workflow was a deliberate negative control in a separate test workflow. It demonstrates why one shared key can mix conversations. It was not a failure of the dynamic-key workflow.
The missing-session test initially expected the detailed error in the public response. We corrected that test assumption after reading the same execution record: the public response hid the cause, while the stored error identified the missing session. No model result was changed or rerun to obtain that conclusion.
Context-window eviction here means exclusion from the model’s input. It does not prove physical deletion of older messages from the underlying history store.
Limits and a reproducible troubleshooting sequence
Start with one session and a unique synthetic fact. Ask for the fact again with the same key. Then open a fresh session, verify that its model request excludes the first session’s fact, and store a different fact there. Return to the first session before testing window eviction with filler exchanges. Save both expected and observed results.
Our local run did not test restart persistence, time-based cleanup, concurrent users, batching, Redis/Postgres backends, queue mode or multi-main operation. Simple Memory documentation warns against using that node in active queue-mode workflows. A successful single-process test does not remove that limitation.
A separate initial model-readiness request exceeded a 60-second timeout; it was not counted as a successful memory test. The actual first workflow request later completed in about 28.4 seconds, and subsequent model-backed requests in this run completed in under 3 seconds. These are observations from this machine, not a latency guarantee.
No paid model API was used. Memory recall also does not authorize an action: use an approval boundary before publishing, and review the agent-versus-workflow decision if the fixed process already meets your task.
Sources & verification
Documentation reviewed and scoped tests completed on 8 November 2026. Results and limitations above apply only to the recorded environments. No paid API requests were made.