She Changed Her Name. Why Does Your Scheduled Agent Still Use the Old One?

Your scheduled agent sends a check-in message to a long-time customer. The message is polite, well timed, and addressed to the wrong person, or rather, to the right person by a name she stopped using two years ago. She updated her name wherever she was asked to: the account form, a support conversation, the billing details. The agent still greets her with the old one, and every run repeats the mistake with total confidence.

Nothing in the workflow failed. The run started on time, the message went out, and the log shows success. The failure is quieter: the agent never learned that the customer's identity changed, so every run works from the person she used to be.

The old name never died. It just got copied

A customer name rarely lives in one place. It sits in the CRM record, the email list, the workflow's own contact table, and the summaries of old conversations. When a customer updates her name in one of those places, the other copies do not hear about it. The scheduled agent reads the copy it was built to read, which is usually the oldest and least maintained one.

Worse, many systems handle a name change by adding rather than replacing: the new name lands as a note or a second field while the old name stays primary. The next run now has two names for one person and no rule for choosing between them. It picks the one in the primary field, or the one that appears most often, and that is almost always the old one.

That is why the mistake survives corrections: a support agent can fix a greeting live, but the scheduled agent reads its own copy on its own schedule, and its copy still says the old name.

Frequency beats recency when memory has no dates

An old name has a structural advantage: it appears in years of history. The new name appears in a handful of recent messages. When a run pulls context by similarity or frequency, the old name wins on volume alone, even though it lost on relevance months ago.

A name without a date is a fact without a verdict. The agent cannot tell whether a name from a three-year-old thread is current or retired, because nothing marks it either way, so it treats every mention as equally alive and the majority wins. The customer experiences this as an agent that knows her entire history and still gets the simplest thing about her wrong.

The same problem shows up with preferred names. A customer may have a legal name for billing and a different name she actually uses. An agent that stores one name field and uses it for everything will get at least one of those jobs wrong: it will greet her with the formal name she never uses, or put the name she uses on a document that needs the legal one. A name is not one field. It is a small set of facts with different jobs, and the agent needs to know which job each one does.

What an identity memory actually holds

A useful identity memory is not a longer contact record. It is a short, dated record the next run can act on without guessing. It needs five parts.

First, the current name for greetings: the name the customer wants to be called, as of the latest confirmed update.

Second, the legal name, kept separate and used only where billing or official documents require it.

Third, the former name, explicitly marked as superseded, with the date it stopped being current. A former name kept without that mark is not history. It is a live competitor for every future greeting.

Fourth, the source of the change: the account update, the support conversation, or the form submission that confirmed it. The source lets a human verify the change later instead of wondering which copy to believe.

Fifth, one place every run reads before it writes. If three systems each hold their own version of the name, the agent will eventually read the wrong one. The fix is not to update three systems perfectly every time. It is to give the agent one identity record to read, and to make every name change land there.

The fix: read the identity before you write the greeting

The habit is simple, and it costs almost nothing per run. Before a scheduled run sends anything addressed to a customer, it reads the current identity record for that customer. If the record changed since the last run, the run uses the new name. If two sources disagree about the name, the run holds the message and flags the conflict instead of guessing. A held message is an awkward internal ticket. A wrong-name message is a customer-facing mistake, and the customer cannot tell the difference between an agent that does not know her name and a business that does not care.

After a name change is confirmed, the run should supersede, not append. The old name moves to the superseded slot with its date. It is not deleted, because old records and old conversations still reference it, but it is no longer eligible for greetings. The next run then has one current name, one marked former name, and no contest to resolve.

Test it the way a customer would experience it. Change a test contact's name, let the next scheduled run fire, and read the greeting it sends. If the greeting uses the old name, the identity record is not the thing the run reads, and no amount of updating the CRM will fix that until it is.

Where Vilix AI fits

This is the kind of memory that has to survive between runs and across tools, not just inside one workflow. Vilix AI is a cloud-hosted memory layer, so there is no infrastructure to run: the agent reads and writes memory over MCP, and the same memory follows the customer record across every connected tool instead of living in one workflow's copy.

Because Vilix AI stores full conversation history, not just extracted facts, the name-change conversation itself stays retrievable: what the customer asked to be called and when she asked. The next run reads the current identity, sees the superseded name with its date, and greets her correctly.

Vilix AI is free forever, with a 7-day Pro trial that needs no credit card, and everything stored can be exported or deleted at any time. Start with the identity record: current name, legal name where needed, former name marked superseded, source, and date. Give every scheduled run one place to read it before it writes a greeting, and the old name stops coming back.

Your agent will keep meeting customers it already knows. Check the next greeting it sends to a customer who changed her name: if it uses the old one, the name is not the problem. The memory is.

Learn more about giving scheduled agents a memory that survives between runs: Vilix AI