Make.com AI Agents Have No Memory Between Runs: What Operators Actually Do About It

Make.com AI Agents are genuinely useful. Drop in an agent module, write instructions in plain English, attach a knowledge file, hand it some tools, and it classifies, drafts, and routes like a whole workflow used to.

But a limitation shows up fast: the agent wakes up blind on every scenario run. One tester put it bluntly after three real-world builds: the lack of memory between messages is the biggest limitation for multi-step tasks. If you run AI agents on a schedule in Make, here is exactly what the agent does and does not remember, and what your options are.

What a Make AI agent remembers, precisely

As of the launch material and the hands-on tests people have published:

• Within one run, the agent is sharp. Instructions, attached knowledge files, tools, and the reasoning panel all work inside a single execution.
• Across runs, there is no continuity. The next scheduled run starts from zero. The agent does not know what it flagged yesterday or which correction you made last week. Memory between runs is not a feature you toggle; it does not exist.
• Knowledge files are static context, not memory. Uploading a pricing doc gives the agent durable reference material, which is great for stable facts. But knowledge files never learn. They answer "what is true," never "what happened."

So the mental model is: your Make AI agent is an extremely competent contractor who gets fired at the end of every shift and replaced by an identical twin who never saw a single ticket.

What operators actually do about it

Since the platform does not remember, operators build memory by hand. Here is the playbook in order of how often it shows up in the wild:

1. Data stores as a scratchpad. Make's data stores can hold a running log: what the agent did, decided, or learned last run. At the start of each scenario, you read the store and stuff the relevant rows into the agent's instructions or prompt. This works, and it is the most honest version of DIY memory. But it gets ugly fast: you are hand-designing a memory schema, deciding what counts as worth storing, writing the retrieval filters, and pruning stale records yourself. Every scenario carries its own version, so two scenarios that should share context do not.

2. Feeding the last run's output forward. Many scenario designs pass the previous run's summary as an input to the next. It is simple, but the context window is a cliff: push a long history and you are paying for it in tokens every single run while the agent gets distracted by stale detail. And anything older than your window is gone forever.

3. Overloading the knowledge base. Some operators update their knowledge files with learnings from production: version 47 of the playbook doc with the latest corrections baked in. This technically works, but version control is manual, and there is no record of why a rule changed, which matters the moment someone questions the agent's decision.

4. Keeping the agent dumb and the scenario smart. The most disciplined operators keep the logic in filters and routers, using the agent only for judgment calls. Solid engineering, but it surrenders the whole promise: an agent that gets smarter the longer it runs your operations.

None of these are wrong. All of them are work that a memory layer should be doing for you.

Why "it worked yesterday" is the expensive part

The cost of amnesiac agents is not one big failure. It is a hundred small ones:

• Re-briefing tax. You, or a prompt-assembly module, re-explains the world every run. Tokens, scenario operations, and your attention all burn on context that should already be there.
• Drift. With no memory of yesterday's corrections, the agent makes the same mistakes in a new costume. It learns nothing, so every run is your first run with it.
• Inconsistent answers. Two identical-looking runs can produce different decisions because the agent has no shared record of what it decided last time. For triage, lead scoring, or anything with a human watching for consistency, that is a trust problem.

This is the pitch for shared agent state, not chat history. Chat history is a log of messages. State is a working model: what is running, what was decided, what changed, what failed, what to try next. Scheduled automation does not need its agents to reminisce; it needs them to resume.

What to demand from a memory layer

If you are going to fix this for a fleet of Make scenarios (or n8n workflows, or Zapier steps), the fix has to meet a short, non-negotiable list:

1. Persistence across runs, not just messages. Memory that only lives inside one execution is a nicer name for context. You need recall that survives the schedule trigger firing again tomorrow.
2. Shared across scenarios and tools. Your agent should not re-learn in scenario B what scenario A already figured out. Context that lives inside one scenario's data store is not memory, it is a silo.
3. Full conversation history, not just facts. A summary of "what we concluded" loses the reasoning. When the agent made a weird call, you want the actual conversation back, so the next run can understand the why, not just the what.
4. Zero infrastructure. Nobody running Make scenarios signed up to host a vector database, write pruning jobs, or tune retrieval thresholds. If the memory layer needs a DevOps ritual, it is not a fix, it is a second job.
5. Your data stays yours. Portable export and instant deletion are not nice-to-haves when the memory holds your business's operational record. Anything you can not leave with is a lock-in tax.

That is the shape of the fix, and it is the gap Vilix AI was built for: a cloud-hosted memory layer with zero infrastructure to manage, where the same memory follows your agents over MCP everywhere they run. Your scheduled agent wakes up with its full conversation history intact, not just extracted facts, so it resumes instead of re-learning.

The honest tradeoff

An external memory layer is one more service in your stack, which means one more account and one more dependency to monitor. If your scenario runs once a week and takes ten seconds, the re-briefing tax is small and a hand-rolled data store might be fine forever. The math changes when runs are frequent, agents are many, or consistency between runs matters: then the DIY scratchpad becomes the most complicated part of every scenario, and the cost shows up in debugging sessions and inconsistent outputs.

The real question to ask yourself is not "does my agent have memory?" It is: what did your agent learn this month? If the answer is nothing, the fix is giving it one memory it keeps between runs.

Vilix AI is a cloud-hosted memory layer for AI agents and automations: one shared memory over MCP, full conversation history across runs, free plan forever, 7-day Pro trial with no credit card, and export or delete your data anytime. Learn more at vilix.ai.