Your Botpress Agent Remembers the User. Your Scheduled Agents Still Wake Up Blank

Picture two agents in the same company. The first is a Botpress support bot on the website. A customer comes back after three weeks, and the bot greets them by name, knows they are on the Team plan, and remembers they prefer email over chat. Continuity, delivered.

The second is a scheduled agent that runs at 6am, scanning yesterday's support tickets for churn signals. It opens every ticket blind. It does not know that the customer in ticket #412 already had a forty-minute pricing conversation with the support bot last week, because the memory lives inside Botpress and the 6am agent runs in n8n.

Same company, same data, two agents with completely different brains. This is the state of agent memory in 2026, and it is worth understanding exactly what Botpress remembers, what it does not, and what the rest of your operation needs.

How Botpress memory actually works

Botpress ships two memory scopes, and the distinction matters:

Session memory covers the active conversation: messages, tool calls, flow state. The agent carries full context while the user is talking. This is automatic and works well.

Long-term memory persists structured facts across sessions, keyed to the user. In Studio you define variables and, per variable, decide whether the value survives when the user returns. Persist plan_tier and contact_preference; let the one-time verification code reset every session. Developers decide what gets stored, how long it is retained, and how it is used. Botpress handles the storage with encryption, which is part of why it appeals to teams with compliance requirements.

Measured against the alternatives, this is ahead of the pack. Dialogflow CX holds context through a conversation but drops it when the session ends, roughly 30 minutes of inactivity, and cross-session memory means building an external database with webhooks. Drift's bots gather data during one interaction and push it to a CRM; the bot itself keeps nothing across sessions. Intercom works the same way: single-session context, CRM lookups for the rest. Botpress remembering users natively, without middleware, is a genuine edge.

The gap: nobody wrote down what was actually said

Here is where support teams get surprised in production. Botpress persists the variables you configured. It does not automatically persist the conversation itself.

Run the pricing scenario again. Your customer had a long, specific conversation: the workaround your bot suggested, the competitor they compared you against, the promise they made to try the new plan next quarter. Two weeks later they return with a follow-up. Botpress serves up their name, their tier, their preferences. The substance of that forty-minute conversation is gone unless someone designed a variable to capture it.

Engineers in the Botpress ecosystem have noticed. A feature proposal on the Botpress GitHub repository spells it out: the LLM-native architecture handles conversations well but has no persistent cross-session episodic memory, so "each conversation starts fresh." The proposal suggests a memory layer hooked into Botpress's incoming and outgoing message hooks, recalling prior-session context and injecting it into the prompt. It is a workaround for something the platform does not do on its own.

So the honest inventory:

1. In-conversation context: yes, automatic.
2. Structured facts you chose to persist: yes, per variable.
3. Automatic recall of what was actually discussed: no. Designed per case or bolted on.

The failure mode is predictable: a customer says "I already explained this to your bot," and they are right. The bot remembers who they are, not what they said.

The bigger gap: Botpress memory never leaves Botpress

Even a perfectly configured Botpress memory is scoped to one identity system (the chat user) in one platform. Automation operators do not live in one platform.

A realistic operation: Botpress handles support chat. An n8n workflow triages leads every morning. A scheduled agent writes the weekly churn summary. A coding agent in Codex or Cursor plans the next sprint. The customer context that Botpress captured so carefully is invisible to every one of those agents. The churn-summary agent re-reads tickets from scratch every week, re-learning facts the company already knew. Each tool remembers its own slice, and the operator pays the tax: re-briefing agents every run with context that already exists somewhere.

This is the real cost center. It is not the Botpress bill. It is the hours spent re-explaining to your own agents what your company already knows.

What the scheduled agents need instead

Scheduled agents need memory with different properties than chat variables:

• Cross-tool by design. One shared store every agent reads and writes, whether it runs in n8n, Claude Code, a phone assistant, or a cron job. Correct a decision once and it propagates everywhere.
• Conversation history, not just fields. The actual exchanges, so an agent can look up what was really said last week, the exact gap Botpress leaves open.
• Semantic plus keyword retrieval. Find memories by meaning, and match exact strings like order IDs and SKUs literally.
• Zero infrastructure. Cloud-hosted, nothing to provision, no vector database to babysit, no retention cron jobs.
• Portable and erasable. Export everything in a portable format anytime. Delete a single memory or wipe the account instantly.

That is what Vilix AI provides: a cloud-hosted memory layer your AI tools share over MCP. Each tool connects to the same Vilix AI account, so the context, decisions, failed attempts, and conversations follow your agents from tool to tool. The free plan is free forever, the 7-day Pro trial needs no credit card, and your data is exportable or deletable whenever you want.

Keep Botpress memory. Just do not stop there

None of this is a reason to skip Botpress's built-in memory. Configure your persisted variables deliberately, because the ones you skip become the support tickets. Plan for the episodic gap, the conversations nobody wrote down, before your customers notice it. And then give your scheduled agents a memory that travels: one layer, every tool, no more re-briefing agents that should already know.

The support bot remembers the customer. Make sure the rest of the operation does too.