Dust Agents Have Memory Now. Your Scheduled Runs Still Start Blank.

Every Monday at 8 AM, your Dust agent wakes up, scans the pipeline, and writes the weekly brief for the sales team. Dust recently gave its agents a memory feature. So this week's brief should be sharper than last week's, right? It should know which deals slipped, which objections keep recurring, which format the team actually reads.

It does not. Each run starts blank.

This is not a bug in Dust. It is a mismatch between two different kinds of remembering, and it bites anyone running agents on a schedule. Here is the mismatch, and how to fix it.

The memory Dust shipped

Dust's agent memory arrives as a tool you add in the agent's configuration. Three design choices define it:

• Memory is opt-in. It is not on unless you enable it. Dust says this is intentional: persistent memory changes how an agent behaves, and some agents (their example: a code review agent that should judge every pull request by identical standards) work better stateless.
• Memory is per user. What the agent retains comes from one person's interactions: their work patterns, preferences, corrections, ongoing projects. Each user builds their own knowledge graph with the agent.
• Memory is visible. Stored memories can be inspected in the agent details drawer. The data is encrypted at rest, isolated per user, and never used for training models.

Put together, this is memory for collaboration: an assistant that gets to know you across conversations. Correct it about the team's definition of a qualified lead once, and it remembers. Ask it to prep for Acme's renewal and it already knows the contract timeline, the pain points from earlier calls, the expansion angles from the last QBR.

For chat-driven work, this is a genuine improvement over agents that reset every conversation. The design is also more honest than most: opt-in instead of silently-on, inspectable instead of a black box.

Why scheduled runs do not get it

A scheduled run is a fundamentally different event from a conversation, and Dust's memory is keyed to conversations with people. Run the checklist:

The trigger is not a user. Many Dust agents run on schedules through integrations: Dust's own docs describe firing Dust agents from n8n on any trigger, schedule included. That nightly call ("scan the pipeline, write the brief") arrives over an API from an automation. There is no person chatting, no conversation thread for the memory to attach to. The preferences and corrections you built up in your afternoon chats belong to that conversational context. The 8 AM run is a stranger.

Scheduled work needs run state, not user preferences. What would actually make the Monday brief better than last Monday's? Not "the agent remembers your preferences." It is operational state: which deals it already flagged (so it does not flag them again), which data pull failed last week (so it retries that source first), which section of the brief the team kept deleting (so it stops writing it). Conversational memory captures some of this only if a human happened to mention it in chat. In practice, nobody hand-briefs an agent in chat about run-level bookkeeping. Scheduling the agent was supposed to eliminate that chore.

One agent, many stakeholders, no shared ledger. Scheduled agents usually serve a team. But memory is scoped per user, so there is no single place where "what the agent did last run" lives for the next run to read. Friday's run and Monday's run cannot see each other's work through the memory feature, because the feature was never meant to connect runs to each other. It connects a person to an agent.

So the weekly brief goes out, and it reads like it was written by someone who has never seen the pipeline before. Because in the sense that matters, it was.

What actually works

You have three practical options, ordered by how far they take you:

1. Stuff the state into the scheduled message. The trigger message carries yesterday's output, the already-flagged deals, the retry list. This is the fastest fix and the most common one. Its cost is linear pain: the prompt balloons, token spend on re-reading history recurs every run, and the moment the state gets long enough to matter, it gets long enough to break.

2. Make the agent keep a run log it can read. End every run by writing a short log (decisions made, items processed, what to skip, what failed) into a document the agent can access, and start every run by reading it. This genuinely works for simple, single-agent schedules. It degrades when runs overlap and both try to update the log, when the format drifts over months, or when a human edits the log and the agent can no longer parse its own notes.

3. Give the run a real shared memory. The clean fix is a memory layer that exists outside any single conversation: every scheduled run checks it at the start and writes to it at the end. This is the shape Vilix AI is built for. It is cloud-hosted, so there is no database to provision next to your automation. The same memory follows the agent across every tool and every run over MCP. And it keeps full conversation history, not just extracted facts, so the next run can revisit what actually happened instead of trusting a summary. The free plan is free forever, a 7-day Pro trial needs no credit card, and your data can be exported or deleted at any time. The scheduled run stops being an amnesiac; it becomes a continuation.

The takeaway

Dust's agent memory is a good feature solving a real problem: assistants that forget you between chats. The opt-in, per-user, inspectable design is better than most of what the industry ships.

But "my agent has memory" and "my scheduled runs remember" are two different claims, and only the first one is true. If your Dust agents run on timers, treat each run as starting from zero and build accordingly. Keep the run state explicit, or give the agent a memory layer that every run shares. The gap is easy to close once you see it. It is expensive to discover it from a Monday brief that forgot everything.