Your Scheduled Agent Keeps Treating Every Customer Like a Stranger. Its Preference Memory Is Missing.
Your Scheduled Agent Keeps Treating Every Customer Like a Stranger. Its Preference Memory Is Missing. A customer tells your business, clearly and more than once, that they want short messages, no calls before 10 in the morning, and every update sent to one email address, not the general inbox. The next week, your scheduled agent sends a long message at 7:30 in the morning to the general inbox. The week after that, it does the same thing again. Nothing broke. The workflow ran on time, the messa
Your Scheduled Agent Keeps Treating Every Customer Like a Stranger. Its Preference Memory Is Missing.
A customer tells your business, clearly and more than once, that they want short messages, no calls before 10 in the morning, and every update sent to one email address, not the general inbox. The next week, your scheduled agent sends a long message at 7:30 in the morning to the general inbox. The week after that, it does the same thing again.
Nothing broke. The workflow ran on time, the message went out, and the logs look clean. What failed is quieter: the agent never learned the customer's preferences, so every run treats a returning customer like a first-time stranger.
Why preferences vanish between runs
A scheduled run starts with its prompt, its inputs, and whatever workflow state it was handed. It does the work and ends. Preferences stated in between runs usually land somewhere the next run never looks: a reply in an inbox, a note in a CRM, a comment in a support thread, a line in a chat.
Even when a preference is written down somewhere, it is often in the wrong shape: a workflow variable holds one value for one run, a spreadsheet row holds a fact with no date, and a prompt holds a general instruction, not a per-customer record. None of these answer what the next run needs: what does this specific customer want right now?
The result is predictable: the agent asks again, messages the wrong channel, and uses the wrong level of detail. Because the run itself succeeded, nobody flags it as a failure, and the customer quietly concludes the business is not listening.
What a preference memory actually holds
A useful preference memory is not a list of likes and dislikes. It is a working record with four parts.
First, the preference itself: the channel, the timing, the format, and the contact. Short email, not a phone call. Mornings after 10, never on weekends. A summary first, with the full detail attached, not buried in the body. One named contact, not a shared inbox.
Second, the date it was set or last confirmed. A preference from two years ago is not the same as a preference confirmed last week. The date is what lets the next run trust the record instead of guessing whether it is still true.
Third, what it replaced. When a customer switches from phone calls to email, the old preference should not sit beside the new one as an equal option. The run needs to know which one won, and when, or it will pick at random between the two.
Fourth, the exceptions: a customer who wants short messages may still want the full version for one report, and a customer who avoids morning calls may allow one for an urgent delivery. Exceptions keep a preference from becoming a blunt rule.
Stored this way, a preference stops being trivia and becomes something a run can act on without asking again.
Three kinds of preference that break the most runs
Contact preferences break runs first: the agent messages the address the workflow was built with, not the address the customer now uses, and every message there is work the customer has to redirect.
Timing preferences break runs second: a message at the wrong hour trains the customer to ignore the agent, so the next message gets skimmed even when it matters.
Detail preferences break runs third, and most quietly. An agent that sends a long breakdown to a customer who asked for a summary is not being thorough; it is asking for attention the customer already said they will not give. One that sends a one-liner to a customer who needs the detail forces a follow-up the run was supposed to prevent.
All three share one cause. The preference lives in a conversation the run never reads.
How to build preference memory into a scheduled run
The pattern is simple, and it has three steps that repeat every run.
Recall first. Before the run plans anything, it reads the customer's preference record: channel, timing, format, contact, exceptions, and the date each was last confirmed. The run plans from that record, not from defaults.
Work second. The run sends the message the way the customer asked, at the time the customer asked, in the form the customer asked for. If the preference record is missing or out of date, the run asks once, plainly, and records the answer. Asking once is fine. Asking every run is the failure.
Save third. At the end of the run, the agent writes back what changed: a new preference the customer stated, a preference the customer corrected, an exception that applied this time, a preference that should be re-confirmed because it has gone stale. The next run then starts one step further along instead of back at zero.
Two design choices make this work across workflows. Key the record by customer, not by workflow, so the onboarding, billing, and support agents all read the same preferences. And treat the newest confirmed preference as current, with the older one kept as history, so a change of mind updates the record instead of creating a competing truth.
Where Vilix AI fits
This is the gap Vilix AI is built to close. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to set up and nothing to install. A scheduled agent connects to the same Vilix AI account over MCP as the rest of your tools, and every run reads and writes the same memory.
That shared memory is what makes a preference survive: captured once, it is available to the next run, to a different workflow, and to an assistant on another device, all reading from the same account. Vilix AI stores full conversation history, not just extracted facts, so the next run can revisit what the customer actually said, including whether a preference was a firm rule or a one-time exception.
The setup stays simple: a free plan forever, a 7-day Pro trial with no credit card, and data that stays portable, with export or delete anytime.
The test for your next run
Before your scheduled agent sends its next message, ask one question: if this customer stated a preference since the last run, would this run know, and would it act on it?
If the answer is no, the fix is not a friendlier message template. A friendlier template sent to the wrong address at the wrong hour in the wrong format is still the wrong message. The fix is a preference memory: recall it at the start, act on it during the run, and save what changed at the end.
Customers do not expect your agent to guess what they want. They expect it to remember what they already told it.
Free forever, no credit card.