Make.com AI Agents Forget Every Run: The Thread ID Pattern (and Where It Falls Short)

Make.com's AI Agents are genuinely useful for operators: one module that reads, classifies, drafts, and routes, replacing what used to be a router plus three filters plus three separate paths. But there is a catch that bites every scheduled scenario sooner or later. Each agent call is completely stateless by default. Unless you explicitly pass a thread ID, the agent retains no memory between runs. The 9:00 run learns something; the 9:30 run never hears about it.

Make gives you a mechanism for continuity. It is called the thread ID, and it is narrower than most people assume.

What "stateless by default" means in the Run an agent module

The AI Agents > Run an agent module has a field called Thread ID. When it is left blank, Make creates a new thread for that call. The agent sees only the messages you pass in that run plus its static instructions and knowledge files. Nothing from last Tuesday's run carries over.

Make's own documentation is explicit about this tradeoff: when you use the same thread ID across module runs, the entire thread gets passed into the agent each time. When you do not need conversation history, you leave the field blank, which creates a new thread ID and saves costs. Blank is the default posture. Continuity is opt-in, and you pay for it in tokens.

The thread ID pattern: mapping a stable identifier

To give an agent continuity, you map a stable, unique identifier into the Thread ID field. Make's help-center walkthrough phrases it plainly: map a unique identifier to keep the same thread for all communication with the agent, which lets the agent keep the history of previous conversations.

The identifier should correspond to the conversation you want to continue. For a Slack-driven agent, a common choice is the Slack message timestamp — the platform team describes this in the Make community: the thread parameter can be any value, but it is usually related to a concept in the messaging platform. For a per-customer support agent, the customer ID or ticket ID works; for a daily digest agent, the calendar date.

The difficulty is not the setup. It is the scoping decision.

The scoping decision operators get wrong

Thread ID is a single knob with two failure modes, and most scenarios land on one of them.

One global thread. Reusing one thread ID for everything is tempting: the agent "remembers" across all users and all topics. In practice this is a leak. Conversation history from Customer A's ticket flows into Customer B's run, because the whole thread is passed in every time. The agent answers questions nobody in this thread asked, and sensitive details travel sideways. It also burns tokens on history that is irrelevant to the current run.

One thread per run. The opposite extreme is generating a fresh ID per execution. Nothing ever carries over, which is just the default amnesia with extra steps. Fine for purely transactional runs (classify this form, route that ticket) where the input bundle contains everything. Wrong for anything multi-turn: follow-up support, multi-step triage, an agent that drafts and then revises on the next run.

The correct scope is usually one thread per conversation: per user, per ticket, per channel thread. When the conversation closes, stop reusing that thread ID — otherwise the thread keeps growing forever, which leads to the next problem.

The cost trap: the entire thread is replayed every run

Every run resends the entire thread into the model's context, and thread history consumes tokens linearly as the conversation grows. That is why Make recommends leaving Thread ID blank when continuity is not needed: a long-running thread silently inflates every run's token bill.

Practical consequences for scheduled operators:

• Long threads get expensive fast. A daily agent on one thread ID means day 90's run pays for all 89 previous days of transcript. Rotate or reset thread IDs when the history stops being relevant.
• Watch tokenUsageSummary. Make surfaces token usage in the Run an agent output bundle, and you can cross-check against your LLM provider account. If costs climb month over month with no change in volume, a bloated thread is the first suspect.

Where thread history falls short (and why operators add a memory layer)

Even scoped and cost-managed, thread history is transcript replay, not memory. It cannot summarize a month of runs into durable facts, cannot retrieve one relevant memory from three weeks ago without dragging the whole thread along, and it lives entirely inside Make — it does not follow the agent anywhere else.

That last point is the one that breaks the automation-operator model. A typical setup runs agents in several places: Make for inbound triage, n8n for nightly processing, Claude Code for building, Zapier for notifications. Each Make thread ID is a private island. The agent that learned a customer's preferences in Make has no way to tell the agent that handles them in n8n. Every tool re-briefs from scratch, invents missing context, and burns tokens doing it.

The fix is to separate memory from the automation platform. Instead of relying on each tool's built-in transcript mechanism, operators put a shared memory layer behind the agents over MCP: one store that every agent reads from and writes to, regardless of where it runs.

This is the slot Vilix AI fills. It is cloud-hosted, so there is nothing to run or maintain — no database to back up, no vector store to tune. The same memory is available everywhere over MCP, so the context a Make scenario learns is visible to the n8n workflow, the coding agent, and the dashboard. It stores full conversation history, not just extracted facts, so the actual exchange can be revisited. There is a free plan forever and a 7-day Pro trial with no credit card, and the data is portable: export everything or delete it any time.

Concretely, the pattern becomes: keep the thread ID for short, same-tool continuity (it is cheap and built in), and let the memory layer hold the durable state — customer preferences, decisions, what was already done, what was tried and failed — so every agent on every platform starts the run informed instead of blind.

Checklist: thread ID or memory layer?

• Transactional classification or routing: leave Thread ID blank. New thread, lowest cost, nothing lost.
• Multi-turn work inside one scenario (follow-ups, revisions, threaded conversations): map a stable per-conversation identifier to Thread ID. Monitor tokenUsageSummary and rotate threads when history stops paying for itself.
• Sensitive multi-user traffic through one agent: scope threads per user or per ticket. Never one global thread.
• Agents running across Make plus other tools, or state that must survive months of runs: add a shared memory layer over MCP. Thread history cannot cross platform boundaries; a memory layer can.

Thread IDs solve continuity inside one Make scenario. They do not solve the operator's real problem, which is agents waking up blind across an entire stack of tools. Use the built-in mechanism where it fits, and put the durable memory somewhere every agent can reach.