Make.com AI Agents Are Stateless by Default. Here Is the Memory Pattern That Changes That

A support-ticket triage agent on Make wakes up every hour. New tickets arrive, it reads them, creates or updates tickets, posts to Slack. Sixty days of smooth operation. Then someone asks: has this agent ever replied to the same customer twice about the same issue? And nobody can answer, because no one can reconstruct what the agent knew at run 400 versus run 1400. The decisions exist nowhere.

Scheduled agents do not have a continuity problem in the abstract. They have a specific one: nobody designed a memory for them. Make's AI agents are honest about this. The official docs say leaving the Conversation ID blank creates a new agent identity with each run, and that means no memory of previous interactions. That is not a flaw. It is the architecture. The question is what you build on top of it.

The three memory shapes on Make, and the one that is missing

Run enough Make scenarios and you will touch every built-in option.

Conversation threads. Set a fixed Conversation ID and your runs keep chatting in one long thread. Feels like memory. In practice the thread grows without bound, the agent re-reads the whole thing every run, and old instructions from two months ago compete with today's context. Conversation continuity is not memory; it is an ever-longer group chat with yourself.

Knowledge files. Upload your FAQs and policies. They persist. They also never change on their own, and they know nothing about the 3,000 tickets your agent has already handled. Knowledge is what the agent should always know. It says nothing about what the agent learned.

Data Stores. The honest DIY path. Before the agent runs, fetch yesterday's state; after it runs, save today's. This works, and plenty of operators do it. But notice what you have become: the person who designs the schema for an agent's brain, maintains the lookup logic, and debugs the corrupt half-writes after a crashed run. That is fine for one scenario. It does not scale to a fleet.

What is missing is a memory that belongs to the agent rather than the scenario: something the agent updates itself, reads on demand, and carries across runs, across scenarios, across tools.

Memory as a service, not a scenario

The mental shift that fixes this is treating memory as infrastructure, like your database or your auth layer. You would not build a bespoke user database inside each scenario; you would point every scenario at the same one. Agent memory deserves the same treatment.

Make supports this more directly than most people realize. The AI agent module accepts MCP tools: an MCP server connected to the agent, authenticated, offering its tools at runtime. That means an external memory service can sit one level up from your scenarios. The agent's instructions do two things: pull the recent memory at run start, push a summary at run end. The scenario itself barely changes. No Data Store modules, no lookup filters, no save logic to maintain.

Why this beats the DIY path:

• The agent maintains it, not you. It writes summaries in its own words at runtime. You stop designing memory schemas.
• It spans scenarios. Five agents across three scenarios can share one memory, or keep separate ones by identity. A Data Store memory is welded to one scenario.
• It spans tools. Memory over MCP is not Make-specific. The same store can feed an n8n agent, a scheduled task, or a chat client you use for debugging. One memory, every surface.

What the agent should actually remember

Not everything deserves to be remembered, and a shared memory that stores everything becomes a junk drawer. The useful categories for scheduled agents are narrow:

• Outcomes and decisions. Which leads were contacted, which tickets were closed, which items were skipped and why. The "don't repeat" list.
• Failed attempts. The approaches that broke. These are the most valuable memories an agent has, and the ones a fresh Conversation ID deletes every run.
• Open loops. Items the agent started but did not finish, handed to the next run like a shift note.
• Learned context. The customer's preferences, the API quirk, the edge case that took two runs to diagnose.

Everything else is either knowledge (static, upload it once) or input (per-execution, pass it in). The run summary is the vessel: at run end, the agent compresses the run into a few sentences and files it. At run start, it reads the last several. That is the entire protocol.

The practical setup

This is genuinely small. Connect your agent module to a memory MCP server, and add to the agent's instructions something like this:

• At the start of each run, load recent memory relevant to today's task.
• At the end of each run, save a short summary: what was done, what was decided, what failed, what the next run should know.

Then let it run for a week and read what accumulated. Most operators report the same moment within days: a run that checks its memory first, notices it already replied to a ticket yesterday, and moves on. The agent did not become smarter. It stopped starting over.

A service like Vilix AI is built for exactly this pattern. It is cloud-hosted, so there is no database to provision and no vector store to tune; the agent just calls it over MCP. The same memory is readable from every tool your agents run on, so the Make triage agent and the n8n follow-up agent can finally know about each other. It keeps full conversation history rather than just extracted facts, which means a terse summary can link back to the real run when the next agent needs the full story. The free plan has no expiry, the 7-day Pro trial needs no credit card, and your data is portable at all times: export it or wipe it whenever you like.

Stateless is a choice, not a sentence

Make designed its agents to be stateless so each run is predictable and clean. That was a reasonable default. But a scheduled agent that has handled thousands of runs and remembers none of them is an intern with permanent amnesia: cheap to run, expensive in mistakes.

The fix is not more prompt engineering. It is giving the agent somewhere to put what it learns. One memory service, one instruction block, and your fleet of agents starts each run knowing what the last run knew. Everything after that is just compounding.