Your Botpress Agent Remembers the User. Your Scheduled Tasks Still Start Blank.

Your Botpress Agent Remembers the User. Your Scheduled Tasks Still Start Blank.

You run a Botpress support agent, and it is good at its job. A customer comes back for the third time this month about a delivery problem, and the agent greets them with the context of the previous two conversations: the order number, what was promised, what still is not fixed. That is real memory, working exactly as advertised.

Then you add a nightly task. Every evening at 9 PM the same agent is supposed to summarize the day's unresolved tickets for the support team: what is new, what got worse, what the team already handled elsewhere. The first summary is fine. By the second week the summaries start repeating themselves. Tickets the team resolved in Slack yesterday morning show up again. The "getting worse" section lists the same delivery complaints every night, with no sense of whether tonight's list is longer, shorter, or identical to last night's. The agent that remembers every customer perfectly has no idea what it wrote twelve hours ago.

Nothing is misconfigured. Botpress gave the agent user memory. The nightly task needed run memory. Those are different things.

What Botpress memory actually covers

Botpress ships built-in memory with two scopes that matter here. Session memory carries context through a single conversation. Long-term memory carries it across conversations: the agent can recognize a returning user, recall past issues and preferences, and personalize future responses. Developers decide what gets stored, how long it is retained, and how it gets used, without wiring up external storage.

This is memory organized around users. Every fact it holds is attached to someone: the customer, their history, their preferences, their last three conversations. For a support agent whose job is talking to people, that is the right shape. The returning customer is not treated like a stranger, and that alone is worth the feature.

But notice the boundary that shape creates. The memory exists to continue a relationship with a user. It does not exist to continue a job the agent does on its own.

Why scheduled tasks are outside that boundary

A scheduled task is not a conversation. Nobody opened the chat. There is no user whose memory the agent can borrow, and there is no prior turn to continue. When the 9 PM run fires, the agent executes from its instructions and the context the platform hands it. It does not inherit the long-term memories of any customer, because those belong to users, and this run is not talking to a user. And it gets nothing about the previous 9 PM run: not what it summarized, not what it flagged as urgent, not what the team already saw and handled.

So the agent can remember that a specific customer prefers email over chat, from a conversation last Tuesday, and still write a nightly summary that lists the same five tickets for the sixth night in a row. The memory it has is not the memory the task needs.

There is a second boundary, and it matters if you run more than one tool. Botpress memory lives inside Botpress. The n8n workflow that triages the tickets, the Slack channel where the team discusses them, the Claude session where you plan next quarter's support strategy: none of them can read it. Every platform keeps its own memory, and your operation keeps starting over in each one.

What operators actually need from run memory

The nightly summary needs to answer three questions that user memory cannot answer: what is new since last night, what changed about the items already on the list, and what is no longer relevant. Answering those requires a memory of the run itself: the conclusions, the list it produced, the decisions behind the list. Botpress lets you build this with tables or external stores, and teams do, but now you are maintaining a memory system by hand. Someone has to define the schema, write the retrieval step, decide retention, and keep the whole thing consistent across every task that reads it. The first task gets the treatment. The third one gets skipped, and the skipped one starts blank again.

The pattern that holds up

The durable pattern is to split the jobs. Let Botpress keep doing what its memory is built for: remembering users across conversations. Give the agent's own work, across runs and across tools, a separate memory layer that every tool in the stack can read.

Vilix AI is built for exactly that layer. It is cloud-hosted, so there is nothing to deploy and no database to operate. Every agent reaches the same memory over MCP, which means the Botpress agent, the n8n workflow, and Claude all read and write one shared memory instead of each keeping a silo. It keeps full conversation history, not just distilled facts, so the raw material is always there when a future run needs the detail behind a decision. The terms are plain: a free plan that stays free forever, a 7-day Pro trial that never asks for a card, and your data stays yours, export everything or delete it all at any time.

The honest summary

Botpress remembers the user. That is the right memory for a support agent and the wrong memory for a scheduled task. If your agent does work on its own, between conversations, that work needs a memory of its own: what it did last run, what changed since, what to skip this time. Put that in a layer every tool can reach, and the nightly summary finally learns what "already handled" means.

Get Started for Free Free forever, no credit card.