Your Make AI Agent Cannot Remember Yesterday's Run. Here Is What Actually Gives It Memory

Your 6 a.m. Make scenario triages the support queue. It reads every new ticket, decides which ones need a human, and drafts the replies. On Monday it is brilliant. On Tuesday it drafts a reply that contradicts what it told the same customer on Monday, because Tuesday's run has no idea Monday's run happened. It is not confused. It is amnesiac, and that is the factory setting.

Make's AI Agents, which launched inside the scenario builder in 2025, run as steps inside your automations. They are good at reasoning over whatever is in front of them in a single execution. They remember nothing between executions unless you build the remembering yourself.

Why the default is blank

An agent step gets its world from the incoming bundle: the data the trigger and previous modules hand it. When the execution ends, the bundle is gone. There is no built-in ledger of past runs waiting to be consulted.

Three features look like they close the gap, and each one covers only part of it.

Knowledge files are persistent, but they are frozen. Uploaded documents (TXT, PDF, DOCX, CSV, MD, JSON) give the agent stable reference material: the refund policy, the product catalog, the escalation rules. They cannot record what happened in a run, because a run's output is not an uploaded document. Useful, but not memory in any meaningful sense of the word.

Conversation IDs look like the memory switch and behave like one, inside one thread. Give a customer-facing agent a stable ID per contact and it keeps continuity within that conversation. Leave the field blank and every execution creates a fresh agent identity that knows nothing. The burden is on you: generate the IDs, store them, keep them consistent. And the continuity dies at the agent's boundary; a second scenario with its own agent starts from zero again.

Tools let the agent act on Make's integrations during a run. They do not persist anything after it.

Platform roundups that compare agent builders say the quiet part out loud: Make's agents lack memory and context handling across interactions. This is not a secret; it is just not in the marketing.

The workaround everyone lands on

The Make community's answer is the Data Store: at the end of the scenario, save whatever the next run will need; at the start of the next scenario, after the trigger, load it back. Key it on the customer ID, the order number, the ticket ID. It is native, it is free, and for simple carry-over state it is the right tool.

It stops being the right tool the moment the agent needs to understand the past instead of just recalling a value. A Data Store record can tell the agent that ticket 1042 was escalated. It cannot tell the agent what the agent already tried, what the customer pushed back on, or why the escalation happened. Those details are the difference between an agent that learns and one that replays the same failed approach every morning.

So teams do what everyone does: they save more fields. The schema grows. The prompt grows. The token bill grows. The agent still cannot answer "what did we decide about this account last month," because nobody saved last month, and nobody can, because the schema was designed around this week's job. Two agents in two scenarios that need the same context now need their stores synchronized, which is a distributed-systems problem wearing a no-code costume.

What actually gives it a memory

The fix is to stop treating memory as per-scenario plumbing and start treating it as shared state: one place the agent reads from and writes to, reachable from every run, every scenario, and every tool.

In practice that means the agent needs three things, and you can check any memory approach against them:

1. It must survive the execution. Not the bundle, not the prompt. The memory has to live outside the run.
2. It must keep history, not just fields. The agent needs the conversation and the reasoning trail, because "escalated" without "why" is a label, not knowledge.
3. It must be shared. One store that every agent and every scenario reaches, so context does not live and die inside a single scenario's modules.

You can build this yourself: a database, an API, HTTP modules in every scenario, and you maintaining the whole thing. Or you can use a layer that already does it.

Vilix AI is that layer. It is cloud-hosted, so there is no database for you to run and no memory schema to design. Your Make agent gets the same memory everywhere it runs, over MCP, which means the same store is reachable from your other tools too, not just Make. It keeps full conversation history, so the agent can look back at why a decision was made, not only the outcome. The free plan stays free forever, the 7-day Pro trial needs no credit card, and everything is exportable or deletable at any time.

The pattern to break

Watch for the tell: the system prompt keeps getting longer. Every time the agent forgets something important, somebody stuffs it into the instructions. The prompt becomes a graveyard of facts the agent should have remembered on its own, and it still fails, because a prompt is a briefing and a memory is a record.

If your Make agent's job fits in two saved fields, the Data Store is enough and you should use it. The moment the job needs the agent to know what happened, not just what was saved, give it one shared memory and stop re-briefing it every morning.