---
title: "n8n AI agent memory beyond chat history"
description: "n8n's memory nodes store chat history per session. How to give n8n AI agents durable, temporal memory with two HTTP Request nodes and no custom code."
canonical: https://past.dev/integrations/n8n
last-updated: 2026-08-31
---
# Memory for n8n AI agents

Source: https://past.dev/integrations/n8n

n8n AI agent memory nodes store chat history. Simple Memory keeps recent turns in RAM. The Postgres, Redis and MongoDB variants persist transcripts by session. These nodes do not extract facts, resolve customers across workflows or track fact validity. Two HTTP Request nodes can connect an n8n agent to past.dev for temporal memory with dated evidence and an explicit status.

## What n8n's memory nodes actually store

The [Simple Memory node](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.memorybufferwindow/) keeps a window of recent messages in instance memory, cleared on restart. The database-backed variants persist the same thing durably: message history, keyed by session. That is the right tool for follow-up questions inside one conversation.

- History is scoped to one session. A new session has no access to a previous session's transcript unless the workflow loads it.
- Raw transcripts grow without structure: no facts, no entities, no dates beyond message order.
- Two workflows cannot share what they learned; each keeps its own transcript.

## The two-node integration

1. **Remember.** After the agent node, add an HTTP Request node: POST to `https://api.past.dev/api/v1/ingest` with JSON body `{"content": <the durable fact>, "timestamp": <when it happened>}` and an `Authorization: Bearer` header from your credential.
2. **Recall.** Before the agent node, add an HTTP Request node: POST to `https://api.past.dev/api/v1/recall` with `{"query": <the user's question>}`. Map the response into the agent's prompt as context.

Alternatively, expose recall to the agent through the HTTP Request Tool so the agent decides when to query it. Both designs keep the existing chat-memory node for conversational context and store durable facts through the API.

Applications can route on `status`. `Supported` means the evidence establishes the answer. `Conflicted` returns evidence from credible sources that disagree. `NoKnownSupport` means the stored evidence does not establish an answer. `UnknownBecauseDegraded` means retrieval could not complete and should be treated as an unknown result.

## What this makes possible in n8n

- A support workflow that recognizes a returning customer and recalls every promise ever made to them, with dates.
- Separate workflows, email triage and chat support, reading and writing one shared memory.
- Client-scoped memory for agencies: one project key per client keeps each client's facts isolated.
- Backfills: ingest a year of tickets with their original timestamps to preserve event dates.

## Routing workflows by recall status

An IF node can route on `status`. `Supported` proceeds to answer generation. `Conflicted` can route to a person with evidence from both sides. `NoKnownSupport` can return an insufficient-evidence response. See the [quickstart](/docs/memory-api/quickstart) for setup and [benchmarks](/benchmarks) for recall evaluation.

## Frequently asked questions

### Do I remove the Postgres chat memory node?

Keep it. Chat memory gives the agent conversational flow; past.dev keeps the durable facts. They do different jobs and work well together.

### Can non-developers set this up?

Yes. Both calls are standard HTTP Request nodes with a JSON body and a bearer credential, the same pattern as any API integration in n8n.

## Related

- [Memory for LangChain](https://past.dev/integrations/langchain)
- [Memory for the Claude Agent SDK](https://past.dev/integrations/claude-agent-sdk)
- [Memory for personal assistants](https://past.dev/use-cases/personal-assistants)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)