They Changed Their Email. Your Scheduled Agent Still Writes to the Old One.
They Changed Their Email. Your Scheduled Agent Still Writes to the Old One. A customer updates an email address, and the change is recorded in the right place. The account record is correct. The CRM is correct. Then the scheduled agent sends the next invoice reminder, appointment confirmation, or support follow-up to the old address anyway. The customer says nothing arrived. The agent's log says the message was sent. Both statements are true, and that is exactly why the problem keeps repeating.
They Changed Their Email. Your Scheduled Agent Still Writes to the Old One.
A customer updates an email address, and the change is recorded in the right place. The account record is correct. The CRM is correct. Then the scheduled agent sends the next invoice reminder, appointment confirmation, or support follow-up to the old address anyway. The customer says nothing arrived. The agent's log says the message was sent. Both statements are true, and that is exactly why the problem keeps repeating.
The agent is not ignoring the update out of carelessness. It never saw the update. It is working from a copy frozen when the workflow was built or the customer was first added, and nothing in the run forces it to check for a newer version before sending.
Where the old address hides
An email address rarely lives in just one place. Once a customer is onboarded, the address gets copied into several spots, and each copy can drift apart.
The first hiding place is the prompt or the workflow step itself. A recipient address typed directly into a send step is a snapshot. It has no link back to the account record, no expiry date, and no way to know it changed. Unless someone opens that exact step and edits it by hand, the old address survives every update made elsewhere.
The second hiding place is a spreadsheet or a list the workflow reads. A weekly report, a reminder list, or an export from months ago can carry the address as plain text. When the customer updates an address in the main system, nobody re-exports the list, so the scheduled run keeps reading the stale row.
The third hiding place is a second system. A billing tool, a booking tool, and a support tool can each hold their own copy of the contact. The customer updates one of them. The scheduled agent reads a different one.
The fourth hiding place is the agent's own record of past runs, when that record is just a transcript. A run can see that it emailed a certain address last week and treat that as the address to use this week, even after the customer has moved on.
Any one of these copies is enough to keep the old address alive, which is why fixing one copy rarely fixes the problem.
Why a bounce does not fix it
You might expect a bounce to expose the mistake quickly. Sometimes it does. Often it does not, for reasons that have nothing to do with the agent's logic.
An old address can still accept mail. A former work address may forward to a shared inbox, and a personal address may stay active long after the customer stops checking it. The message is delivered, in the technical sense, and never seen by the person it was meant for.
Even when a message does bounce, the bounce often goes nowhere useful. It lands in a mailbox nobody monitors, or in a log the next run never checks, so the same address gets used again.
A soft failure is worse than a hard one here. A hard bounce at least looks like an error. A message delivered to an inbox nobody checks looks like success in every report the agent produces, and the customer stays uninformed until a deadline passes or a payment is missed.
What the failure costs before anyone notices
The cost of an old address is not one missed email. It is the chain of events that follows a message nobody received.
An invoice reminder sent to an old address turns into a late payment, then a second reminder, then a collections message to a customer who would have paid on time. An appointment confirmation sent to an old address turns into a no-show and a rebooking conversation that starts with an apology. A support follow-up sent to an old address turns into a reopened ticket, because the customer replies through a different channel saying nobody ever followed up.
Each follow-up costs more attention than the original message. Worse, each one trains the customer to distrust the channel, so important notices start getting missed even after the address is finally corrected.
The fix: look the address up at run start
The reliable fix is a change in run order, not a better address list. Before a scheduled run sends anything, it should look up the current contact record, in one place, and use what it finds there.
That means three rules for every recurring recipient.
First, keep one current record per customer, not one copy per workflow. The record holds the current address, the date it changed, and the previous address marked as superseded. Every scheduled run reads that record at run start, so one change reaches every run.
Second, stop storing addresses as text inside prompts, send steps, and spreadsheets. Those places should hold a reference to the customer, not the address itself. A reference can be resolved fresh each run. A typed address cannot.
Third, treat a bounce or a non-response as a signal the next run must check. When a message bounces, mark the address as unverified in the same record the run reads. When a customer does not respond to two consecutive messages on one channel, the next run should pause and check whether the contact details are still current, rather than sending a third message to the same place.
Those three rules turn an address change from a manual cleanup job into a normal event. The customer updates an address once, and every scheduled run after that uses the new one.
The memory that makes the lookup possible
A lookup rule only works if the record it reads survives between runs and is shared by every agent that sends messages. A run's context window is wiped when the run ends, and a prompt describes what to do, not what changed last week. Neither one can hold a current contact record that every run trusts.
That is what Vilix AI is built to be. It is a cloud-hosted memory layer, so there is nothing to install and no infrastructure to manage. Agents connect over MCP, and the same memory follows them across every tool they use. It stores full conversations, not just extracted facts, so a run can see the whole history: when the address changed, what was sent to the old address, and what happened after.
With that shared memory in place, a scheduled run can check the current contact record before it sends and use the new address. The old address stays in the history as a superseded record, not as a live destination.
Getting started costs nothing. The free plan is free forever, and a 7-day Pro trial needs no credit card. Your data stays portable: export everything or delete it anytime.
A scheduled agent that keeps writing to an old address is not failing at sending. It is failing at remembering what changed. Give it a memory that updates when the customer does, and the next message goes to the inbox the customer actually checks.