Your Make.com AI Agent Forgets Everything Between Runs. Here Is How to Fix It

Picture a Make scenario you run every morning. A watcher catches new leads, the AI agent scores them, drafts a reply, and logs the result. Clean, reliable, hands-off.

Now ask it tomorrow what it did today. Nothing. Ask whether it already replied to the lead from yesterday. No idea. Every run wakes up blank, re-reads the same leads, re-drafts the same replies, and makes the same judgment calls from scratch. The agent is not learning. It is just repeating.

This is not a bug in your scenario. Make's AI agents are stateless by default. Memory between runs is something you have to build yourself, and most builders never realize it until the duplicates start showing up.

What Make's memory actually is (and is not)

A Make AI agent is a module that sits inside your scenario and makes judgment calls: which tools to call, in what order, how many times. It is a reasoning node in a workflow, not a chatbot with a history.

Make gives you two things that sound like memory, and both need a closer look.

Conversation memory. There is a Conversation ID field. Leave it blank and each run creates a brand-new agent identity with no memory of previous interactions. That is straight from Make's own documentation. Set it to a fixed value and runs keep talking in the same thread, which feels like memory until that thread gets long, stale, and expensive to re-read every morning. And it stays trapped inside that one agent: a second scenario with the same agent cannot see it.

Knowledge files. Upload FAQs, brand guidelines, company policies. They live in a RAG vector store and the agent pulls relevant chunks at runtime. Useful, but it is reference material, not memory. Your brand guidelines do not remember what happened in run 47. Nothing in the knowledge upload flow learns.

So the situation: conversation threads that accumulate forever and get dumber, or a knowledge base frozen in time. Neither answers "what did you do yesterday and what should you do differently today."

The workarounds operators build (and their costs)

The usual fix is a Make Data Store. Before the agent runs, you look up yesterday's state: last processed lead ID, open threads, decisions made. After the agent runs, you write the new state back. It works. It is also you becoming a part-time database administrator for your agent's brain.

You design the schema. You decide what gets serialized. You write the lookup logic before the agent module and the save logic after it, and you debug it when a run fails halfway through and leaves half-written state.

The alternative pattern that actually holds up is simpler to describe: the shift handoff.

The shift-handoff pattern

Think of each run as a shift. At the end of every shift, the worker writes a short handoff note: what I did, what I decided, what is still open, what went wrong. At the start of the next shift, the new worker reads the last few notes and carries on.

Applied to a Make scenario, it looks like this:

1. Start of run: the agent loads the last handful of handoff notes. Not the whole history, just enough to know what matters right now.
2. During the run: it does its normal work with tools.
3. End of run: it writes a short note. One or two paragraphs. What happened, what it decided, what the next run should know. Failed attempts go in here too; those are the notes that save the most money.

The agent writes the notes itself, in its own words, at runtime. You never hand-edit them. Over weeks, the note stack becomes a compressed operating history of the automation: the leads it already touched, the edge cases it learned to avoid, the decisions it should not re-litigate.

The only missing piece is where those notes live and how the agent reads and writes them without custom plumbing in every scenario.

This is where MCP changes the picture

Make AI agents can connect to MCP servers directly. The official documentation lists MCP tools as a supported tool type: tools from an MCP server, connected to the agent with authentication. That one sentence is the whole fix, because it means memory can be a service the agent calls, not infrastructure you maintain inside the scenario.

Instead of wiring Data Stores and lookup logic around every agent module, you give the agent a memory tool. The scenario stays clean: the agent reads its handoff notes at the start of the run through the memory tool and writes a new note at the end through the same tool. Same agent, same scenario, zero custom database plumbing.

The setup takes one extra instruction block in the agent's prompt: at the start of each run, load your recent memory. At the end of each run, save a summary of what you did and decided. The agent handles the rest.

This is exactly what Vilix AI is: a hosted memory layer that agents read and write over MCP. It is cloud-hosted, so there is no database to run, no vectors to tune, no infra to maintain. Because it speaks MCP, the same memory follows your agent beyond Make: the n8n workflow that processes the leads, the scheduled task that drafts the weekly report, the chat client you debug from, all of them read and write the same memory. It stores full conversation history, not just extracted facts, so a handoff note can point at the real conversation when the next run needs the full story.

The free plan covers real usage with no time limit, there is a 7-day Pro trial with no credit card, and your data stays portable: export everything or delete it anytime in a portable format. Leave with your data whenever you want.

The ten-minute version

If you run Make agents on a schedule, do this today:

1. Connect a memory MCP server as a tool on your AI agent module.
2. Add two lines to the agent's instructions: load recent memory at run start, save a run summary at run end.
3. Let it run for a week, then check what the notes look like.

Most operators discover the same thing within days: the agent stops re-contacting leads, stops re-asking questions it already answered, and stops repeating failed approaches it tried last Tuesday. It did not get smarter. It just stopped waking up blind.

Memory is the difference between an agent that runs a task and an agent that learns a job. Make gives you the agent. The memory part is yours to add, and it is a ten-minute job now.