Your Scheduled Agent Keeps Texting Customers at 2 a.m. It Never Learned Your Business Hours
Your Scheduled Agent Keeps Texting Customers at 2 a.m. It Never Learned Your Business Hours A customer signs up on a Tuesday evening. The follow-up sequence is set to run the next morning. Then, at 2 a.m., the phone buzzes with a check-in message from a business that is closed. The customer does not think, "What a responsive company." The customer thinks, "Who is texting me at 2 a.m.?" Nothing in the run failed. The agent followed its instructions. The problem is that its instructions never in
Your Scheduled Agent Keeps Texting Customers at 2 a.m. It Never Learned Your Business Hours
A customer signs up on a Tuesday evening. The follow-up sequence is set to run the next morning. Then, at 2 a.m., the phone buzzes with a check-in message from a business that is closed. The customer does not think, "What a responsive company." The customer thinks, "Who is texting me at 2 a.m.?"
Nothing in the run failed. The agent followed its instructions. The problem is that its instructions never included the one thing a human employee would know without being told: do not message people in the middle of the night.
That is the signature of a scheduled agent with no contact-window memory. It knows when the workflow runs. It does not know when the customer is willing to be contacted.
The schedule the agent follows is not a contact window
Most scheduled agents are built around a trigger: every hour, every morning, three days after signup, seven days after the last reply. The trigger decides when the run happens, and the run sends the message. The trigger says nothing about whether the resulting message lands at a reasonable hour for the person receiving it.
Time zones make this worse, but they are not the whole story. A run scheduled for 9 a.m. in one time zone is a midnight message in another. A run that fires on a Saturday hits customers who only want weekday contact. A run that fires on a public holiday lands during a day the business itself is closed. Each of these is a different failure, but they share one cause: the agent checks the clock on the workflow, not the clock on the customer.
It is tempting to fix this by moving the schedule. Shift the run to mid-morning, and the worst of the midnight messages disappear. That helps for one audience in one time zone. It does nothing for the customer who works nights and asked to be contacted in the evening, or the customer who asked never to be texted on weekends. A single schedule cannot hold all of those preferences. Only a memory can.
Why "it ran on time" is the problem
When a human sends a message at the wrong hour, the mistake is obvious and it gets corrected. When an agent sends a message at the wrong hour, the run report says success. The message was delivered, the step completed, the sequence advanced. There is no error to investigate, so nobody looks.
The cost shows up elsewhere. Reply rates drop, because a message read at 2 a.m. is often swiped away and forgotten by morning. Complaints rise, because an untimely text feels intrusive in a way an untimely email does not. And in some channels the risk is more than annoyance: text messaging carries quiet-hour expectations, and operators who message outside them invite regulatory trouble they never planned for.
What a contact-window memory actually has to hold
A contact window is not a single setting. It is a small record the agent reads before every send, and it has to cover five things.
First, the business window: the hours and days the business contacts customers at all, including holidays when the business is closed. This is the default every run falls back to.
Second, the customer window: any per-customer preference that overrides the default. One customer wants weekday mornings only. Another wants evenings. A third asked for no weekend contact. These preferences arrive in replies, in signup forms, and in support conversations, and they are useless if they stay in those places instead of moving into the record the agent reads.
Third, the channel rule: not every channel has the same clock. An email at 9 p.m. is ordinary. A text at 9 p.m. can feel intrusive, and a phone call at 9 p.m. is worse. The record needs a window per channel, not one window for everything.
Fourth, the exception and its expiry: a customer who is travelling may ask to be contacted only in the afternoon for two weeks. That exception needs an end date. Without one, a temporary preference becomes permanent, and the agent keeps honouring a window that stopped applying months ago.
Fifth, the queue rule: what happens to a message that is ready outside the window. The right answer is almost never to drop it. The message should wait in a queue and go out at the start of the next allowed window, with its context intact, so the follow-up still makes sense when it arrives.
None of this is complicated. What makes it work is that the check happens before every send, on every run, without exception. A window that the agent consults sometimes is a window it will violate eventually.
The fix is a check, not a new schedule
Operators who solve this do not rebuild their sequences. They add one step to the run, before the send step: read the contact-window record, compare the current time in the customer's time zone against the allowed window for that channel, and either send or queue. Then they add one more habit: every time a customer states a timing preference, it goes into the record the same day, not into a note nobody reads.
That single step changes the failure mode. Instead of a run that succeeds by sending at the wrong hour, the run succeeds by holding the message until the right hour.
The record also needs a home outside any single workflow. A follow-up agent, a renewal-reminder agent, and a support agent all message the same customers. If each workflow keeps its own copy of the window, they will drift apart, and the customer will get a respectful email from one agent and a 2 a.m. text from another.
How Vilix AI fits
Vilix AI is a cloud-hosted memory layer, so there is nothing to install or maintain to give agents a shared record like this. It connects to AI tools over MCP, the open protocol, so the same memory follows you everywhere: scheduled agents, Claude, Codex, Cursor, and phone apps all reading and writing to one store.
That shared store is what a contact window needs. A timing preference a customer states in a support chat can be read by the follow-up agent the next morning, because both agents read the same memory. And Vilix AI stores full conversations, not just extracted facts, so the agent can revisit the actual exchange where the preference was stated, including the exact wording and any conditions attached to it.
The free plan is free forever, and the 7-day Pro trial needs no credit card. Your data stays yours: export everything or delete it anytime.
The check to add before your next run
Before the next sequence goes out, ask one question about it: does the run check a contact window before it sends, or does it send because the schedule said so? If the answer is the schedule, the next 2 a.m. message is already queued. Give the agent a window to read, a queue to hold messages that miss it, and one shared record every agent consults.