Your Scheduled Agent Learned the Client's Preferences by Run 50. Run 51 Woke Up Knowing Nothing.

There is a special kind of frustration reserved for people who run scheduled AI agents. The agent gets smarter every day for weeks. It picks up the client's formatting quirks, which sections of the report get read, what "keep it short" actually means for this particular human. Then the cron trigger fires on a Tuesday morning and all of that learned behavior is gone, as if the previous fifty runs were a dream.

The agent did not regress. It never had memory. It had a very long conversation with itself, and conversations end.

The preference treadmill

Consider an invoice-processing agent that runs nightly. Over a month it gets corrected, run after run: one client wants amounts rounded before tax; another wants the PO number in the subject line; a third flags anything over a threshold for review before posting.

In a chat session with a human, every one of those corrections would stick. The model would adapt for the rest of the conversation, and the operator would walk away feeling like the agent "knows" these clients.

Then the scheduler fires. The new run has no conversation. It has a system prompt, a set of tools, and whatever the workflow injects. The learned corrections were never injected, because nobody put them anywhere injectable. So the agent makes the same mistakes it made on day one, the client corrects it again in the review step, and the cycle repeats forever. The operator is training the same intern every morning.

This is the preference treadmill: learning happens, but only inside a single run, so every run starts the training over.

Why scheduled runs are worse than chat sessions

A human chatting with an assistant gets continuity for free. The conversation stays open. The model sees its own past messages, including the corrections.

A scheduled run gets none of that. Each execution is a fresh process with a fresh context window. Whatever happened in the last run exists only if the workflow deliberately carried it forward. Most workflows carry forward outputs (the report, the invoice summary) but not learnings. Outputs answer "what happened." Learnings answer "what should I do differently next time." An agent that only sees outputs is doomed to rediscover the same lessons.

And even when a workflow does carry forward a notes file or a running log, two problems appear. First, the file grows until the relevant preference is buried under weeks of stale entries, with no mechanism to mark which version is current. Second, a correction made on Tuesday sits next to the original rule from March, and the agent has to guess which one wins. Without last-write-wins semantics, "the client changed their mind" becomes "the agent has two conflicting instructions and picks at random."

What survival actually looks like

A preference that survives between runs needs three properties, and it is worth naming them plainly because most setups have at most one:

It is written somewhere that outlives the process. A durable store, not a variable, not a chat thread inside one platform's UI.

It is loaded at the start of every run, by meaning. The run that drafts the client brief needs to find "client prefers bullet points, no buzzwords, before 7am" even if the agent phrases the query differently. Keyword matching on exact strings is not enough; retrieval has to understand intent.

It is correctable, with the newest version winning. Preferences are not constants. A store where old rules linger alongside new ones is a store that teaches the agent to argue with itself. One write of "we're not doing that anymore" should settle it everywhere.

There is a fourth property that matters once the operation grows past one tool: the same preference store should be reachable from every agent that serves the client. The scheduled job, the chat assistant that takes follow-up questions, the code agent that formats the output — all of them should read the same profile. Otherwise you get the odd situation where the chat assistant knows the client hates jargon and the nightly job keeps serving jargon.

What changes when memory survives

The difference is not subtle. An agent that wakes up with its preferences intact stops needing the daily re-brief. The client's corrections accumulate instead of evaporating, so week six is genuinely better than week one. Onboarding a new client stops being a configuration project: the preferences are learned in conversation and persist on their own.

It also changes how operators think about the schedule itself. When runs are stateless, every run has to be self-contained, which means long system prompts stuffed with rules. When memory survives, the system prompt shrinks to the stable instructions, and the learned stuff lives where it belongs: in memory, retrieved when relevant, updated when wrong.

This is what a shared memory layer is for. Vilix AI is cloud-hosted, so there is nothing to deploy or maintain: agents and tools connect over MCP and read the same memory wherever they run. It keeps full conversation history, not just extracted facts, so a preference learned in passing is captured with its context. The free plan is enough to start, there is a 7-day Pro trial with no credit card, and the data stays portable: export everything or delete it anytime.

The takeaway for operators

The question is not whether your agent is smart enough to learn preferences. It is. The question is whether anything in your stack gives those preferences a place to live between runs. If the answer is no, no amount of prompt engineering fixes the Tuesday-morning amnesia. Give the learned behavior a durable, retrievable, correctable home, and the preference treadmill stops. The agent that learned the client by run 50 will still know the client on run 51.