Give Your Workflow Memory and Data Lookups

Each workflow run starts with no knowledge of past runs. If you want the AI to know who the customer is, or you want to avoid handling the same message twice, you need to store data and look it up. This lesson adds both to the project.

What You'll Learn

• The difference between chat memory, a data lookup and a state table
• How to look up a customer before the AI writes
• How to use n8n Data Tables to stop duplicates
• When chat memory is the right choice

Three Things People Call "Memory"

Our project handles one message at a time, so it does not need chat memory. It needs the other two.

Look Up Data Before the AI Writes

If you ask AI to reply without facts, it may invent them. So fetch the facts first, then give them to the model.

Do it in this order:

1. Add a Google Sheets, Airtable or CRM node that searches by email.
2. In the node's Settings, turn on Always Output Data. Without it, a search with no result can output nothing, and the next nodes do not run.
3. Add an IF node that checks whether a customer ID exists.
4. If no customer is found, tell the AI so in the prompt. Then it will not assume facts.

Send the AI only what it needs. A plan name and the last order date help it write. A home address and payment details do not. Sending less data reduces cost and protects your customers.

Try writing the draft prompt with the facts passed in.

Store State in an n8n Data Table

Data Tables let you store structured data inside n8n, without an outside database. Workflows in the same project can read and write them through the Data Table node. They suit light to moderate use. The default limit is 200 MiB per instance, so they are not a place for large archives.

Create a table called handled_messages with these columns:

Column	Example
message_id	abc123
status	waiting_approval
decision	approved
category	billing
updated_at	Time of the last change

Now add this to the workflow:

1. Right after the trigger, search the table for the message_id.
2. If it exists, stop. This message was already handled.
3. If it does not exist, add a row with the status started.
4. Just before the approval step, update the status to waiting_approval.
5. After the person answers, write approved, rejected or no_answer to the decision column.
6. After the reply is sent, update the status to sent.

This is the unique key check from the errors lesson. The status column also shows you where each message is at any moment.

A run that fails midway leaves its row at started, and step 2 will then stop that message every time. Add a small scheduled check: if a row has been started for more than an hour, alert a person. Do not rerun it automatically, because you cannot be sure how far the run got.

Note the limits. Two runs that start at the same moment could both find no row. For most small teams this is rare. If it matters, keep this table in a database with a unique rule on message_id, so the second run fails when it tries to add its row.

You can use a Google Sheet for the same job, but it is slower and has its own limits on requests.

In Make, use a data store. In Zapier, use Zapier Tables. The steps are the same: search, branch, write.

When You Do Need Chat Memory

If you build a chatbot, it must remember earlier turns. In n8n, connect a memory node to the AI Agent. The Simple Memory node has two main settings:

• Session Key: identifies the conversation, such as the user's ID. If this is wrong, users can see each other's context.
• Context Window Length: how many past interactions to include.

Simple Memory does not work in active production workflows if n8n runs in queue mode. For a chatbot in serious use, use a database-backed option such as Postgres Chat Memory or Redis Chat Memory.

Longer memory means more tokens per run and a higher cost. Keep the window as small as works well.

To understand why agents forget, see How AI Agents Work.

Key Takeaways

• Separate chat memory, data lookups and state. They solve different problems.
• Look up facts before the AI writes, and tell it what to do when facts are missing.
• Turn on Always Output Data so a search with no result can follow its own path.
• Use a Data Table with a unique message ID to stop duplicates and track status.
• Check the Session Key carefully when you use chat memory.